+18Hi Everyone,
I have 2 tenants for the same instance and they want to merge into one tenant. same inventory items in both tenants, however due to it being separate locations, they use different base UOM’s. Does anyone have thoughts or ideas on how to handle this? My thought is that the one location will have to conform or do UOM conversions.
Best answer by Samvel Petrosov
Are those different UOM labels or actual different UOMs? Also what is the plan for data migration?
I think the path of the least resistance is to import the UOMs from the second location into the first one as Item’s additions UOMs with Conversion factors and then import the quantities.
That will allow them using both UOMs as needed, but still one of the UOMs must be decided as the default sales/purchases UOM. The base UOM most likely will stay the value in the tenant where the data is being imported.
+9Are those different UOM labels or actual different UOMs? Also what is the plan for data migration?
I think the path of the least resistance is to import the UOMs from the second location into the first one as Item’s additions UOMs with Conversion factors and then import the quantities.
That will allow them using both UOMs as needed, but still one of the UOMs must be decided as the default sales/purchases UOM. The base UOM most likely will stay the value in the tenant where the data is being imported.
+1Samvel's approach is the right shape. I'd add one thing about which tenant you make the target, because that choice locks in the base unit and it's painful to walk back.
The items in your target tenant already have a base unit, and base is what every quantity and unit cost is stored in. So decide the merge direction around which base unit you want to live with, not just which tenant holds more data. Acumatica's own guidance is to make the base unit the smallest one you'd ever track, buy or sell, specifically to avoid rounding problems. If you land on CASE as base and the other site sells singles, every transaction they enter from then on is a fraction of a case.
The thing worth checking before you commit to a direction is Divisible Unit, on the General tab of Stock Items (IN202500). Clearing it forces integer quantities, and that gate drives validations across IN, SO and PO documents. A large base unit plus a cleared Divisible Unit will stop the incoming location's daily transactions cold.
Two more that ride on base units and are easy to miss in a migration. Unit cost is stored per base unit, so if you convert incoming quantities without applying the reciprocal to cost, your valuation lands wrong. Default Price on the item is base currency and base units too. Whatever factor you use on quantity, cost and price need the inverse.
On the conversions themselves, they're stored per item, so an import scenario into the conversions grid on Stock Items (IN202500) will load them in bulk while you're already moving data.
No account yet? Create an account
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.
