Deutsch
Españolusing APPS
GLOBAL
BUSINESS
Business Central expert
This is #6 of 8 articles about how to cover your entire business with BUSINESS CENTRAL
– without customer extensions
– only using APPS
Fulfill all your needs for managing GLOBAL BUSINESS in BUSINESS CENTRAL.
In this article, we explain what you should require, how you avoid customizations, and which APPS to use.
When we manage several companies with Business Central, some additional needs arise. This is often due to having companies in several countries, but it can also simply be several companies in the same country.
The companies typically have different roles in the supply chain, for example, logistics companies, production companies and sales companies with a number of processes between them.
Intercompany
We have a sales company that has sales orders because they receive orders from end customers. The sales company provides forecasts to the head office, which plans the product requirement, and they draw on the warehouse/logistics company to deliver, or from a 3rd party logistics company, and some orders the logistics company may deliver directly to the end customer.
The head office also purchases goods from the production company, which uses a number of external suppliers, produces the items and delivers them in a container to the logistics/warehouse company.
It is just an example. No matter what our company structure is, we must be able to handle it in Business Central, and the processes must be supported so that we do not have to handle all data and accounting manually.
By default, Business Central can handle intercompany transactions well, especially with the October 2023 release, but we quickly need more structure and automation so that we can post automatically in several companies at once.
When the sales company creates a purchase order, a sales order must automatically be created in the company that is to deliver – and so on through the company structure. We also want to be able to see the stock levels in other companies, so that, already when we take the order from the customer, we can see if the item is in stock in another company.
» Intercompany transactions
We also need to manage pricing between companies. It is also a challenge if we have different exchange rates in different companies.
We need to use the same source for prices and exchange rates so that eliminations are easier and so that we get the same values on the same items in the consolidation accounts.
Global Master Data Management
Master Data Management is an important subject in a corporation with many companies (legal entities). We must have a global structure for master data and be able to synchronize master data between companies, and we must include master data on the documents used on sales, purchase and transfer orders between all the companies. We go in depth with Master Data in a separate chapter.
Perhaps we have five different companies that will in practice have the same customers, items, master data etc. When we create a new item at the headquarters, we want it to be replicated to the other companies so that we do not need to create it multiple times – and maintain it in multiple companies. We need master data organized in a master and subscriber hierarchy.
Containers
Containers are an important topic if we ship goods over long distances, both if we send or receive goods in containers.
As a buyer, it may be that we have a container standing at the supplier, which we gradually fill with purchase orders, and when it is full enough, we have it shipped to us. Then we would like to manage all purchase orders in the container together. If the container is delayed by 4 days along the way, then we would like to update all purchase lines at once and find the conflicts it creates.
In the same way, if we are the seller, then we are the ones who ship the container, and we want to plan the capacity of the container as best as possible before we send it off.
Assortments
There is often a difference in which goods and variants may be bought and sold in different companies.
In the warehouse company, we have 8 colors of an item, and one sales company must buy all 8, while another can only buy 2 of the colors because they only market the 2 colors.
On the web shop there must also be all 8 colors for customers in the first country, but only 2 for customers in the second country. And the head office has decided that one of the colors must be discontinued, and therefore only 7 of the colors must be reordered from the supplier.
The international structure must be able to manage all of that in Business Central.
Packages and Labels
When you offer goods to many countries, packaging and labels become a special challenge. An ingredient label may contain 3 languages: English, Spanish and Portuguese, and this determines in which countries the product can be sold.
We have the same item in stock with other language combinations, e.g. English, Italian and Greek. It may be that we have 1000 of the item in stock and we can deliver all 1000 to English-speaking countries, but we can only deliver 80 to Italy because the other 920 do not have Italian language on the ingredient label.
Many variants of packages and labels are an additional challenge in Business Central.
Reporting and follow-up
Reporting is about Business Intelligence. In a global setup, we would like to be able to report across the entire company structure. What do we sell in which parts of the world? How long are our delivery times?
If Business Intelligence shows that the lead time for an item is in reality 3 months, but the master data on the item in ERP says 2 months, then we should correct the master data so that we do not promise the customers something we cannot fulfill.
Consolidation
Financial consolidation is another topic that is often handled with a reporting tool.
We would like to be able to analyze the units in the company structure in a comparable way. There is no point in having to map data from scratch each time to get comparable numbers. We must be able to manage the structure centrally for the entire group.
Typically, we prepare a group account, where we consolidate all data from underlying companies up to the group account and eliminate the transaction. Unless all companies use Business Central, it is smart to carry out the consolidation with a Business Intelligence solution, but this requires that we have harmonized charts of accounts and dimension codes in all companies.
INTERCOMPANY TRANSACTIONS
If our company operates internationally – or if we have many companies in our ERP system that need to be integrated – ‘intercompany’ is an important topic.
In a sales company, we create a sales order for a customer; when we release it, a purchase order must be created to buy the item from another company in the group, and a sales order must be (automatically) created in our group’s production or inventory company.
Now we have three order documents linked together across two companies, and we must be able to manage them together, and change them as one.
Change management
Management of changes is the difficult part. In the production company, we must be able to change quantities or prices, and have the change propagate to both the purchase order and the sales order in the sales company.
We must be able to make a change to any of the three records, and the change should be reflected in the others. It is no good if our solution is too hardwired to support the world we live in.
There are several areas where we need flexibility in the day-to-day.
One sales order
Our sales company needs the ability to create a sales order containing lines from several companies, e.g. two items from the local sales company itself, four items from the inventory company in Germany and three items to be produced by the company in Poland.
Direct shipment
We must be able to indicate whether it is a direct shipment – i.e. whether all companies are to send the items direct to the end customer – or whether the German and Polish companies are to send the items to our local sales company, which will then ship to the customer.
This is in fact one of the most difficult aspects of intercompany transactions. If the German and Polish companies ship directly to the customer, they must be able to enclose a shipping note or invoice printed using the logic of the original local sales company, who are after all the ones the customer has dealt with. This gets complicated when different companies and accounting entities are involved.
When the local company sells to a local customer at local prices and local discounts, the documents must be able to come off the printer in Germany and Poland.
Item tracking
We also want to be able to track items across companies.
When the warehouse worker in Germany picks items with serial numbers, he must scan the serial number, and then it must flow all the way to our local sales company so that we locally can see which serial numbers have been picked for the order.
Configuration
With item configuration, data must flow the other way. We register the specifications of the configured item, and perhaps the fact that a company logo needs to be printed on the lid, on the local sales order. These details must then flow to the Polish production company, which will produce the items and print the logo on the lid.
Error handling
Finally, how does the intercompany solution handle errors? If something goes wrong between companies (e.g. if the item number does not exist in the other company), does the order then go into an error log that somebody must follow up before the order can proceed?
We definitely recommend that the solution be online and that errors be returned to the user in real time. This means that, if in our local sales company we enter an order that will withdraw items from the German and Polish companies, we will see any errors on screen straight away as we type, so we cannot get any further in the process until the error has been handled.
We notice a distinct rise in demand for intercompany solutions. It is certainly becoming more and more normal for transactions to cross borders and companies.
The fundamentals are reasonably simple, but flexibility in day-to-day challenges is the true mark of a good intercompany solution.
GLOBAL SYNCHRONIZATION
We may have five different companies (legal entities) that will in practice have the same customers, items, master data etc. When we create a new item at the headquarters, we want it to be replicated to the other companies so that we do not need to set it up multiple times.
We may also have a different ERP system in one of the subsidiaries. We need master data to be synchronized across all platforms, Business Central as well as other ERP system within the corporation. This also goes for Master Data that we have created ourselves, i.e., Color, Size, Material or many other kinds of Master Data on Items, Customers and Vendors
The challenge is to get the different ERP systems, with different data structures, talking to each other. We must think carefully when developing a data structure to make sure that the keys match in all the companies – across the various ERP systems.
Data synchronization strategies
There are various strategies we can choose.
A centralized strategy means that we have a main company in which we set up all master data in a consolidated form, bringing together all debtors, all items and everything else we want to be managed by the central team. The system ‘pushes’ data out from the main company to the peripheral companies.
Central management has certain advantages, but the disadvantage is that data is harder to maintain when fewer staff have access.
Perhaps there is a local user in France who notices that a particular piece of information on an item is wrong, but he does not get it corrected because it is a lot of trouble to report it to headquarters. If he corrects his local data, it will just be overwritten by the main company’s data when the next synchronization job runs.
We therefore incline towards a hybrid strategy in which data can be synchronized both ways.
It is fine for data to be collected in a central main company, but we see it as crucial that local users can update the data, so that the Frenchman can update the local item data, and the amendment will be synchronized back to the central company, and the next synchronization job will replicate his amendment to all companies.
We naturally need to keep tabs on the editing rights he needs, i.e. which fields he can update and which he is not allowed to meddle with.
He also needs access to input data in French without it overwriting other language variants.
He also needs the ability to create an item that is only relevant in France and is not to be disseminated to other companies.
The bigger the corporation, and the fewer items we have or the less dynamic an item structure we have, the more relevant we believe a centralized strategy with a main company is.
This also applies if we have strict quality controls on our items and our development or quality department secures and cleanses the data very rigorously. In these cases, it makes sense to do without devolved updating and innovation.
Subscribing to data
We must be able to build a master data structure with an owner of data and subscribers of data. In each subsidiary we choose the data we want to subscribe to.
For example, if there is a French subsidiary in a German group, the French subsidiary can subscribe to shared items, customers and other master data – but it can also create local items that are only relevant in France.
If the French subsidiary purchases an item that exists only in France, it makes no sense to replicate that item number to 20 other subsidiaries around the world.
