Address Book Best Practices

AllanFW

Member
We are currently on A7.3 with multiple instances around the world and are migrating to E1 9.0 in a single instance. We are starting our migration to E1 in the US, and once completed we will migrate the next office/country location until we are complete.
The question I have is once we are all in one instance how should we manage the address book? Without specific guidelines/proceedures the address book can easily get out control.
Does anyone have suggestions for "address book best practices" or know where I can find some.
Thank you in advance for your help.
 
Allan,

How is each instance 'managing' their Address Book, today?

Remember, all organizations fight change (even if they are embracing the upgrade, they will still 'not' like the aspect that they might have to change the way they are doing things 'today').

One suggestion would be to consolidate all the 'rules' that each instance is using, then get the senior players in a room, together, and let them fight until a consolidate set of rules is compromised.

Since most organization have an adhoc set of policies, it might be a good practice to see if the players can agree on a 'new one', for all - during the migration and ever after.

Enjoy merging the AB from all the instances - I've felt your pain...

(db)
 
Daniel,

Thanks for the advise. Some instances are using next numbers others are using a 'smart' numbering scheme from their legacy systems.

My question is a little more fundamental, for example;
You have a vendor that changes it's name, do you create a new AB record or change the name on the existing record? Same for a remittance address change.

Thank you
 
Your players are used to running their own rig - and that's going to have to change for 'someone'... As for best practices - a number is just a number.

If they organize their reporting based on an Address Book Number, they need to find a new process. Conceptually, that's what all those Category Codes should be used for. Instead of saying that AB#10000 - AB#25000 are a specific Customer Type, they need to address that customer type by using a specific Category Code.

Going forward - the best practice is going to advise that all the instances adopt policies that are synonymous to each other (preferably, One Agreed Upon Policy).

The agreement will need be considerably more wide-spread than just the AB. The GL side, Job Costing and ... pretty-much most of the consolidated instances - will need to be aligned and controlled.

As you are consolidating instances - remind your teams that AB# and other areas my need some adjustments. Duplicate AB# will have to be addressed, and who-ever is first in line is most likely to see their data 'best honored'.

Management is going to have fun with this - I'm sure!

Holler if you need further help - until then, I would suggest a much heavier reliance on Category Codes within each module, than I would creating 'smart' numbers.

(db)
 
Back
Top