Problems sharing data between companies

MikeVanDyke

Hello!

I have read many posts but still have not found an adequate answere to my question. I hope anybody could help.

One of our customers want to share items,customers,vendors and some other data between companys within one navision database. There are many hints in this forum to not just set the property "DataPerCompany" to "No" because some people made bad experiences, but they didn't tell which problems occured exactly.

I would like to know which problems there are in specific to have a basis for our decision.

Thanks to all in advance!

PS: The customer is using NAV4SP3.

kriki

I did it for contacts and encountered some problems. But if you take care of them everything works:
-It is not only the contacts table, but also other tables that are closely related. This takes a lot of thinking. For example : The contact is intercompany, but are also the interactions on them? When I create a customer/vendor from the contact, I need that in each company, it has the same No.
-items, vendors, customers have some posting setup, so it is important to be sure that the posting setup IS THE SAME in each company!
If a customer in 1 company is local customer and in another company a foreign customer, you already have a problem.
-Also : changing something in those tables must be done by someone that knows ALL companies. Because changing something on a card can be ok for most companies, but not for the last company, so you can't do it. And the person that changes it should know that BEFORE he changes it.

A good idea is also the log all changes on those tables. This makes the DB more heavy, but it can help a lot in case of problems.

David_Singleton

MikeVanDyke wrote:

There are many hints in this forum to not just set the property "DataPerCompany" to "No" because some people made bad experiences, but they didn't tell which problems occured exactly.

I am opposed to doing this. I have done many multi company implementations in the beigning I also tried the data common path, but would never do it again. What you need to think is "Why would you set the Data Common flag". There are two reasons most people think at the start, the first is a misnomer the second is simply wrong.

Reason 1, is that it will save database size. Yes it will, but how much? The database size in NAV comes form Entries and posted documents history, NOT for base tables, so yes on your laptop system with 10,000 customers and 4 invoices it will look like a huge saving, but int he live system, with 2,500 customers and 2,000,000 Posted invoices you will see that the difference is nothing. On top of that, there will always be exceptions, requiring either more fields or a new table that will eat all that saved space.

Reason 2, is that it will be less programming. That is soooo far from true that it does not even warrant discussion. You will easily spend 10 time the amount of work than if you just wrote code to sync each company.

So in my book the best solution is one that does the job for the client, is reliable, easy to upgrade, and most importantly cost effective. Sharing tables is the most expensive solution, it takes the most support, its the hardest to upgrade.

DenSter

MikeVanDyke wrote:

I would like to know which problems there are in specific to have a basis for our decision.

If you search hard enough you will find similar articles all over the place. I know this because I've written quite a few myself. I'll take another stab at it. None of us are saying it's impossible, but it is a LOT more work than you can imagine

This are just a few of the issues, there are many more:
Let's take the Item table. The most common reason for sharing this table is "so that all companies in my database use the same Item numbers". So by setting the Item table's DataPerCompany property to No (which I refer to as a 'global table'), the thought is that now every company can use the same Item number, and you only have to set it up once. A two second change, with huge benefits right. If you ever find a consultant that tells you this is an easy change, go find another one.

Problem number one: Which company is the boss? You can now go into the Item table, and modify every Item from every company. You don't like the description? Just change it and it will change in all companies. What happens when there is a difference of opinion about certain fields? It might be trivial such as description, but there might be fields that are not as easy to get consensus on. You will have to develop some sort of logic to limit the system as to what changes can be made from what companies. What about things such as Unit Cost. This fields is updated by some core processes, and will simply not work properly anymore. For instance, when your costing method is average, this gets set by a system process in one company, which might be a completely wrong one in another company. You can see that problem number one may SOUND easy, but it is much more complicated.

Problem number two: Data integrity in subsidiary tables. The Item table has lots of fields with table relationships to other tables, and you will have to make sure that the data in those tables are either also shared across companies, or that you develop a mechanism that synchronizes the data in these tables. Let's for instance take the "Item Unit of Measure". So you're in company A, you create Item number 123, and you give it a Base Unit of Measure of EACH, by creating an Item Unit of Measure record that is related to Item 123 and the Unit of Measure EACH. In company A, you can use Item 123 on a sales order, and it will pull the unit EACH right in. Now go into company B and try the same thing. You will get an error saying 'Item Unit of Measure does not exist'. Not only do you have to make sure that the records exist in every company (either by sharing the Item Unit of Measure table, or by developing some synchronization routine), but you also have to put in place controls about the values in the subsidiary table. What if in company A a BOX is 10 EACH, and in company B a BOX is 15 EACH? Which one is going to win? You can't have both values, because now inventory is meaningless across companies. What if in Company A there is a transaction in EACH, but in compane B there isn't? Company A will not let you change the Base UOM, but company B will allow you to do that. So you could enter a transaction in EACH in company A, go to company B, change the Base unit to BOX and create a transaction there. Now your inventory is REALLY screwed up, and don't even start about pricing logic.

These are just two of the issues of making a master table a shared table, and believe me there are many more. In my opinion, the best way to do this is to create new tables for every 'shared' or 'global' table, and create logic to copy it down into the local tables. For instance, make a copy of the Item table, call it 'global item' and develop logic that copies the global item into the regular item table. You can decide which sunsidiary tables to include. You can for instance decide to also make a global copy of the Item Unit of Measure table, clamp down the base, sales, purchase units, and allow local companies to add local units.

This way every company has the ability to set it up to their wishes and still maintain consistency across companies by making certian fields non editable. Now all you have to do is put in place synchronization logic from the global master table.

MikeVanDyke

Thanks to all for your quick response!