We put off multi-company in 10.0 but will be coming back to it soon. I’ve noticed there are a lot of tables that have the Global fields (Global< table name > and GlobalLock.) and some have the associated Glb< table name > as well (not all), but I don’t see any reference in the Multi-Company Technical Reference.
Are these just there for future functionality or are users using them. In particular, I’d like to have UDCodes publish out to other companies (there is a GlbUDCodes table) and some UD.
Also, while Product Configurator is multi-site/company enabled, it does not appear that a configurator created in one company can “transferred” to another. In our case, we use the same configurators (and Data Lookup Tables) in five different companies.
I can put some tooling together to export/import Configurators and Lookup tables and DMT for the UD tables but I don’t want to invest in that if it can be done automagically.
Yes, alot of them really don’t do anything. for Example UDCodes, in the List they can be marked as global, but you don’t have a choice to select them in the Transfer Settings, hence making its Global Settings obsolete.
OK, good to know. I’m going to try some PowerShell (with Invoke-REST calls) to do the updates.
I’m not sure @hasokeric is completely correct - but he so knowledgeable otherwise :-), I’ll need to test this.
We use multi-company and the configurator. We have not started inter-company trading yet.
Some things, like code tables is various locations are not selected in the Multi-Company config, but when you mark them global, they do appear in the other companies. I think product group and part class may be examples. I don’t have any global UD Codes, so I can’t speak to that directly. Oh - and there is a whole thing regarding global COA too…
GLB Tables - a super nice support person explained them to me once. The multicompany process pulls and pushes data between companies using the GLB tables and IM Tables - depending on the process. Some transactions create M/C transactions immediately - like I/C GL entries - while others are ‘found’ by the M/C process - like Part description updates for Parts marked global. And that it can take 3 full passes of the M/C process to move everything around properly. So most of us run the task on 15 minute increments once the initial big ‘synch’ is finished. the GLB/IM tables are the staging ground for all of this - and effectively should be empty unless there are unprocessed transactions. Also the tables IntQueIn and IntQueOut are the M/C process queues and need to be monitored.
Configurator - There is the basic concept of Manufacturing versus Sales companies if you are going to use the enterprise configurator, and it uses ‘global’ and M/C processing to keep everything in synch. BUt if that’s not the case, then you have to export/import configurators - and all the rules, methods, lookup/UD data to go along with them. We’ve not found a ‘global’ for the configurator yet. And this is where a central code repository inside ERP would be most helpful. Once you have a dozen companies using copies of the same PCfg UD method, and want to change it - you’ve got to manage each copy independently.
Thanks Mike. So, we’re seeing the same thing as you. Import/Export is the way to move things. We’re not really in the “Enterprise” configurator situation. Each company takes its own orders but we will use I/C to buy parts from each other.
We put the version in the heading but I might put a check in the initial load to check a flag in PCConData for the most recent version, just to ensure we’re using the same configurators. A BAQ can check to make sure the UD Tables, User Codes, and Lookup tables are in sync across the five companies.
Sounds about right. But here is some more food for thought…
- Don’t have the same part (marked global) in more than 1 company with separate configurators - this doesn’t work.
- PCLookup values are supposed to M/C synch, but ours does not - we’re looking into that when we get a chance. So we have to manually maintain those lists.
- UD Table data can be cross-company referenced - so we have one set of data to maintain that can be used in other companies. (Odd how this works on the UD table).
Interesting… Because when we have 14+ Companies and I mark a Product Group as Global, I haven’t seen it pass into the Glb Tables, but that aside, I haven’t even seen a way to link it in a lower company or configure MC Process to limit the companies to push it too.
Haso - like I said, I could be totally wrong . I’ll see what I can find in my setup. We’ve got 5 operating companies but we haven’t made a change to any of those setup/code tables in years so my memory isn’t as clear as yours is.
We are going multi-site to multi-company during Q1 2019. I am working off of the Multi Company Course book, but I am wondering if there is a better document to go by that I am missing? At any rate, I will take copious notes of the entire project and share those.
We have a couple of years worth of sales, manufacturing/assembly and financial history for the two current sites. I am sure the lessons learned will be an interesting read.
I think the hardest challenge is deciding on your Company Process. For example, are you going to allow Part’s to be created in the Child-Companies? or are you going to force Engineers to keep a Part Master in your MAIN Company and push it down. Same for Suppliers, Customers etc…
You might need some Service Connect flows or some slick BPMs. For example, we do allow a Customer being created in the Child-Company, it is then pushed up to the Main Company and Linked.
We do not allow Parts being created in Child-Companies, you have to create it in the MAIN Part Master and we have some SC/BPMs that push it down + Link it… Same with BOMs etc…
Are you going to have User’s with access to both companies, if so, do you need special Menu Securities to prevent them from seeing what they can see in a Child-Company in the MAIN Company etc… (Sometimes you have 1 employee thats a hybrid, between 2 companies etc…)
Are you going to do Inter-Company POs etc… Again defining the company process.
@hasokeric Do you consolidate all the data into parent company?
If yes, then is it necessary to have same GL account and account segment values in all the companies?
If not then how do you manage to consolidate it?
Would you please help. Because we are stuck on multi-company since days…
On the child company you would have two books, the source and the intermediate. The intermediate book should have the same GL Structure as the Parent Company’s.
In order to transform from the source book to the intermediate book you would need to setup mapping.
After consolidation you can review the GLs in the intermediate book before sending them to the parent company through multicompany.