DataPerCompany

lloydsmods

Okay, I know this has been chewed over a million times already, so don't yell at me yet...

I have a client who wants to share customers, vendors, resources, and g/l accounts across 12 companies. Sound familiar? #-o

They have their reasons, so please don't ask why.

I already told them that using DataPerCompany was a MAJOR NO NO. =D> So, the alternative they have adopted is to have a "master company" into which changes can be made and then code to sync the data to the other companies.

There are, however, subsidiary tables that I'd rather not manage which, I assume, it would be safe to use the DataPerCompany=no flag for. Post Codes, currency, languages, countries/regions. Any drawbacks to doing this? What about Number Series?

Others, like territories, payment terms, payment methods, tax area codes, 1099 codes, finance charge terms, etc., I also assume I will need to write code to keep in sync. :-k

Any tips or pitfalls that you can think of that I can avoid would be very appreciated.

ara3n

if you write your modification using recref and fieldref, it wouldn't matter how many tables you want to sync, you would call the same functions.
the code would be triggered from onglobal triggers in CU 1

marcoau18

I have the same thing in my company too for years. Having a master company for master data like
GL Account, Customer, Vendor, Fixed Asset etc
Having a btn "Assign to all company" to transfer selected fields to companies.

David_Singleton

Keep in mind that the reason for separating the data into multiple tables is to reduce locking. Once you "go crazy" with the data per company option, you start bringing locking issues back. Even synchronization of certain tables is going to start causing locking. If this is a small system its probably OK, but if you plan any decent transaction volume in the future, be very careful.

if you want synchronization to this extent, maybe you need to closer look at the business model and why there is this need. Is this in fact just one big company? Would you be better off using a new global company field to handle this?

rhpnt

Also to be considered that maybe not all companies users can/should view all the shared data (customers, vendors, prices,...). This is often realized too late - when all the work has been done. Then the s..t hits the fan...

David_Singleton

rhpnt wrote:

Also to be considered that maybe not all companies users can/should view all the shared data (customers, vendors, prices,...). This is often realized too late - when all the work has been done. Then the s..t hits the fan...

Exactly. The devil is in the detail. This is not something that should be designed by a programmer. It requires carefull analysis of the business requirement. Otherwise at go live time there will be one tiny little thing forgotten that makes the whole thing fall apart.