|
Customer is using the ITK scripts to import the Supplier files and during one of the load the SupplierOrganization.csv file didn’t run which resulted in creation of BuyerXXX IDs.
There are few causes why the system creates a Common supplier with Ariba Unique ID, Buyer_xxx.
1. If partition supplier data is loaded before the common supplier data on the realm.
2. If Common supplier data is not replicated to the child realm and before that you load partition supplier data on the child.
3. If the SystemId value is blank in the SupplierConsolidated.csv file (as it contains the data for both partitioned and common supplier)
In the above cases the Partition supplier does not find the correct Common supplier with which to associate themselves, so the system generates a new common supplier with incorrect ID, Buyer_xxx.
We can fix this issue by avoiding the above mistake or if it is incorrectly loaded we can correct it by following these steps :
From the SupplierIDs.csv, remove all of the domains (sap, networked, duns, etc.) and values other than buyersystemid for suppliers where buyer systemid values are buyer_xxxx.
Reload the resulting file (and the exported SupplierOrganizations.csv) back into the realm. The outcome of this action is:
a. The buyer_xxx suppliers will not have any other domain or value other than buyersystemid.
b. This operation will break connection with the Partitioned Supplier and Supplier Locations.
After step 4 is verified, reload the correct SupplierOganization.csv and SupplierIDs.csv with the correct domains and values.
After Step 5, reload Supplier.csv and SupplierLocation.csv exactly as loaded before, so the connection to the top object can be re-established.
IMPORTANT: This operation, most likely, will affect the catalogs of the system, if these are related to suppliers with the buyer_xxxx value. Once the corrected (new) supplier is loaded, the catalog needs to be reloaded/relinked to the correct supplier entity.
Purchasing