recode the product supplier code (SUPPLIER_PID)
In Italy for the Electrotechnical sector sometimes companies need to recode the supplier number “SUPPLIER_PID” in their catalog. This change can occur for the following reason: 1 - change of coding (*) 2 - Type of packaging 3 - Technological characteristics of the product 4 - Replacement 5 - change of brand (*) when a company has been acquired and the parent company wants to standardize the codes with its own. The natural elements to manage this type of data would be the “PRODUCT_REFERENCE” segment In the table the only match with our values is PRODUCT_REFERENCE type="followup” = Technological characteristics of the product And the use of UDX.EDXF.PREDECESSOR_PID We could not find another method to manage these cases, besides the Country specific regulations NL - THE NETHERLANDS PRODUCT_REFERENCE type="others" PROD_ID_TO 654321 PROD_ID_TO REFERENCE_DESCR predecessor REFERENCE_DESCR Do you have any suggestions on how to manage these other 4 cases? Our idea was, as above, to use type="others" and propose a description value for 4 remaining cases, if correct this would become an extension of ITALIAN-specific regulations for electrotechnical.
Of the 5 scenarios you have listed, a change in the technological characteristics of the product cannot be considered as recoding! It is a similar but different product, so in that case as you mention ‘followup’ is the correct reference. We discussed this internally and believe that for the other 4 examples no PRODUCT_REFERENCE is needed, you can just use UDX.EDXF.PREDECESSOR_PID to identify the product ID that is replaced by the new (recoded) one. Your example from the Dutch country specific regulations is not valid/relevant anymore, they added ‘predecessor’ but forgot to remove that when with version 5.0 we introduced the new field UDX.EDXF.PREDECESSOR_PID. So we think that no additional reference description is needed, but if you would really consider that necessary, you might add something like ‘recoded product id’ to the Italian country specific regulations (there is no plan to update these country specific regulations any more by the way in the official documentation).
I've had some experience with a recoding issue in my past career as head of PIM at a manufacturer. All articles of a specific factory were preceeded with a couple of extra characters and a hyphen (like "AA-#######"). This because we were merging two companies that had overlapping article codings. The important thing to consider is that you have no control over the databases of all companies down the business verticle. Your article no. is used in MDM data, eCommerce data but also in ERP systems that have purchasing items, selling items, stock items etc etc. You can overwrite the article records in your PIM, and try to do the same in the datapool you publish your data to. But further down the verticle is where the chaos starts. So whatever you do, first thing to do as a manufacturer, if possible supported by the data pool, is to set up a good communication strategy to reach all responsible data managers in the business chain. Then secondly you have two options: 1) copy the product/article records that are recoded, supply them with a new code and put the old code in as PREDECESSOR. Mark the old set of product/article records as obsolete and put the new code in as SUCCESSOR. (exact field definition of SUCCESSOR/PREDECESSOR fields differ per exchange standard). Then publish both sets in the datapool and hope for the best. 2) Overwrite the product/article records, communicate through the business chain and hope for the best. Considering nr 2 you could add a new field for "PREVIOUS ID" Some side notes: - You cannot apply the same set of GTINs to both old and new dataset - You have no guarantees that everybody will do their homework - Printed catalogues still show old article nrs. - If you declare products as obsolete, cuasing the wholesaler to sell out stock, there is no guarantee that new product codes will retain the stock position at the wholesaler. So overall conclusion is to avoid recoding at all cost.
Join the conversation
|Topic started||17 July 2023 at 10:21|
Share topic via: