Product Identification Codes in ERP, PIM, and B2B Marketplaces

Composite codes, regional formats, and how item identity shapes supply chains worldwide.

Effective product identifiers are crucial for linking data across ERP systems, PIM platforms, and B2B marketplaces. This article explores how various systems (SAP, Oracle, Microsoft Dynamics, 1C, Kingdee, Inspur, etc.) structure and manage product identification codes. We focus on how identifiers are constructed, maintained, and used for referencing and matching products – excluding classification/category codes. Real-world examples and regional differences are highlighted, along with challenges in interoperability.

Composite Identifiers in ERP Systems

ERP systems use item codes (material numbers, part numbers, SKUs) as the primary keys for products. These may be simple sequential numbers or composite codes encoding meaningful information (e.g. a family-type-variant scheme). The choice of intelligent (meaningful) vs. non-intelligent (non-significant) codes varies by company and system:

• Intelligent (Composite) Codes: Combine segments representing attributes like product family, type, size, variant, etc., in a single code (e.g. ABC-100-LG for family ABC, model 100, color Large). This makes codes human-readable – users can decipher product traits from the code. For example, one Russian 1C ERP scheme encodes country, manufacturer, date, type, model, size, color as segments (CT-PR-0119-TP-4312-F-C) (Что такое артикул товара? Использование артикула в 1с). Such codes often include letters, numbers, and separators like hyphens for clarity (Что такое артикул товара? Использование артикула в 1с).
• Non-Intelligent Codes: Use sequential or random numbers with no built-in meaning (e.g. a purely numeric SKU). These are easier for systems to manage at scale but require users to rely on descriptions or lookups to know the product.

Most modern ERPs allow either approach. SAP ERP explicitly supports both “mnemonic” (meaningful) and “non-mnemonic” (numeric) material numbers (Material Master (LO-MD-MM)) (Material Master (LO-MD-MM)). If a company uses meaningful codes, SAP can be configured for external number assignment – users manually enter a chosen alphanumeric code when creating a material. If using non-meaningful codes, SAP uses internal number assignment, auto-generating the next sequential number from a defined range (Material Master (LO-MD-MM)). In SAP S/4HANA, material numbers can be up to 40 characters (expanded from 18 in older versions), allowing longer composite codes if needed (Material Number Field Length Extension – SAP Community). By default, SAP treats the material number as an opaque string, but companies often establish coding standards (like specific prefixes for categories or models) outside the system logic.

Oracle ERP (Oracle E-Business Suite and Oracle Cloud) provides flexible segmentation through Key Flexfields. A flexfield allows defining an item code as multiple segments with meaning. For example, Oracle’s item flexfield could define a part number like 10-PEN-BLA-450 to mean “Division 10 – Product PEN (pen) – Color BLA (black) – Supplier 450.” Internally, Oracle would store a unique item ID (e.g. 13452) while users see the composite code (Overview of Key Flexfields). This approach lets Oracle enforce structure (each segment has a predefined length and value set) while still associating a surrogate ID behind the scenes (Overview of Key Flexfields) (Overview of Key Flexfields). Oracle’s JD Edwards ERP (now Oracle) even uses three item number fields by default: an 8-digit short ID (internal), plus two 25-character alphanumeric fields for alternate item numbers (often one for a meaningful code, one for legacy or secondary code) (Item Number) (Item Number). Additionally, JDE and Oracle provide cross-reference tables to map any number of alternative part numbers (substitutes, old codes, barcodes, supplier codes, etc.) to the internal item (Item Number).

Microsoft Dynamics 365 (and former AX/NAV) typically uses a single item number field (often called Item ID or Item number) which can be user-defined or system-assigned via a number sequence. It supports alphanumeric codes and is often limited to a certain length (e.g. 20-30 characters). Dynamics allows both manual coding (companies can implement a meaningful SKU format) or auto-generated sequences for simplicity. For variant-rich products, Dynamics 365 has a product variant framework: one defines a “product master” with dimensions (size, color, style, etc.) and the system generates variant codes or suffixes. For example, a shirt might have item SHIRT100 and variants SHIRT100-RED-M, SHIRT100-BLU-L, etc., using a nomenclature template for variants. The base item number itself remains the key. Dynamics also provides a product name template for variants (to ensure names are consistent), but the item number for a product cannot be changed once transactions exist, enforcing stability (Product identifiers – Supply Chain Management | Dynamics 365 | Microsoft Learn) (Product identifiers – Supply Chain Management | Dynamics 365 | Microsoft Learn).

Regional ERP Systems: Local ERPs like 1C:Enterprise (Russia), Kingdee and Inspur (China) also manage item codes similarly, with some localization. In 1C, the item reference (typically called “Артикул” – article number) is an alphanumeric code that uniquely identifies a product in the catalog (Заполнение артикула номенклатуры в 1С). 1C by default allows manual entry of the Артикул; companies often devise their own coding schemes. As shown earlier, Russian practice might include using letter codes for manufacturers or categories (often using Latin letters even for Cyrillic-named entities) to keep codes concise and readable (Что такое артикул товара? Использование артикула в 1с) (Что такое артикул товара? Использование артикула в 1с). 1C can be extended to auto-generate article numbers based on product type prefixes and number ranges (e.g. a prefix per category and a sequential number) (Заполнение артикула номенклатуры в 1С) (Заполнение артикула номенклатуры в 1С), but this requires customization. Chinese ERPs like Kingdee and Inspur similarly allow user-defined item codes. Many Chinese companies use numeric or alphanumeric codes, sometimes embedding meaning such as supplier or category codes, but usually using English letters and numbers (for universal readability) rather than Chinese characters in the code. The length and format can vary; codes of 8–12 characters are common for internal use, though some companies use longer formats if encoding multiple attributes.

Pros & Cons: Intelligent composite codes can help staff quickly recognize a product’s key traits (useful in manual contexts or where systems are not easily accessible). However, they can become complex and inflexible as product lines grow. Modern best practices often favor non-significant codes with all attributes managed in separate fields. Studies note that overly “smart” part numbers are fragile – as new attributes or exceptions arise, the scheme either breaks or requires frequent rework ( Intelligent part numbers: The cost of being too smart ) ( Intelligent part numbers: The cost of being too smart ). A non-intelligent SKU (just a simple number) coupled with robust descriptions and category fields is more scalable ( Intelligent part numbers: The cost of being too smart ) ( Intelligent part numbers: The cost of being too smart ). In practice, many organizations take a middle path: e.g. use a short prefix for product family and a numeric sequence for uniqueness. Each ERP implementation typically defines number range rules (to enforce length or format) and whether the code is system-assigned or manually entered. For instance, SAP ties number range settings to material types (you can allow external entry for certain types where meaningful codes are desired, and internal for others) (Material Master (LO-MD-MM)) (Material Master (LO-MD-MM)). Oracle’s flexfields require configuring the segments and value sets before users can create items (Overview of Key Flexfields) (Overview of Key Flexfields). The key is that ERPs are flexible – the structure of product IDs is ultimately a policy decision by the business, which the ERP can accommodate through configuration or extensions.

Internal Part Numbers vs External Identifiers

Companies often maintain multiple identifiers for the same product: an internal part number and various external reference codes. Common code types include:

• Internal Part Number (SKU): The primary identifier in the company’s ERP/PIM for the item. This is unique within the organization and used in all internal transactions (inventory, BOMs, orders). It can be called material number, item code, stock code, etc. (often synonymous with SKU). Format is company-specific (as discussed above). For example, one company might use 45001234 as a pure numeric SKU, another uses HW-PLA-0001 (with embedded meaning).
• Manufacturer Part Number (MPN): If the company didn’t manufacture the item, it likely has a manufacturer’s part number – a code assigned by the original manufacturer. This is crucial in B2B contexts to ensure you’re referring to the exact same product as your supplier or customer. MPNs are usually alphanumeric and can vary widely in format (each manufacturer has its own coding). For instance, a specific bearing might have MPN 6205-ZZ-C3 from SKF. Companies usually capture the MPN in their item master data for reference. Distributors and suppliers often use the MPN as the primary key in product catalogs, since that’s what links to the original product design.
• Global Trade Item Number (GTIN): A standardized global identifier (part of the GS1 system) used for trade products, commonly seen as UPC, EAN, or ISBN codes. GTINs are numeric codes (typically 12 digits for UPC in North America, 13 for EAN in Europe, or 14-digit GTIN-14 for cases, etc.). Many ERPs/PIMs have dedicated fields for GTIN or barcode numbers. For example, SAP material master has fields for EAN/UPC codes per unit of measure. Microsoft Dynamics 365 allows maintaining multiple barcodes (and recommends using them to store GTIN/EAN codes) (Product identifiers – Supply Chain Management | Dynamics 365 | Microsoft Learn) (Product identifiers – Supply Chain Management | Dynamics 365 | Microsoft Learn). GTINs are crucial for retail and consumer products – marketplaces like Amazon require a GTIN to list a product unless you get an exemption (How to create a new ASIN on Amazon). In B2B, many industrial products might not have a GTIN (if not sold at retail), so MPN becomes the key external identifier instead.
• Supplier or Customer Codes: In procurement and sales, it’s common to map the internal item to a supplier’s item number or a customer’s item number. ERPs facilitate this mapping. For instance, SAP allows linking a vendor’s part number in the Purchase Info Record, so that purchase orders can reference the supplier’s code in addition to the internal material number (cross reference – SAP Community). Similarly, SAP Sales module has a customer-material info record where you store a client’s preferred item code for your product. Microsoft Dynamics 365 has an “External item description” feature to maintain each customer’s or vendor’s item number for a given product (Product identifiers – Supply Chain Management | Dynamics 365 | Microsoft Learn) (Product identifiers – Supply Chain Management | Dynamics 365 | Microsoft Learn). These mappings ensure that when documents like POs or invoices are generated, the external party’s code is shown for clarity (Product identifiers – Supply Chain Management | Dynamics 365 | Microsoft Learn) (Product identifiers – Supply Chain Management | Dynamics 365 | Microsoft Learn). The internal and external codes thus coexist: internal codes drive internal processes, while external references are used on printed or electronic documents exchanged with partners.
• Other IDs: There are other identifier types like serial numbers (unique per instance of a product), batch/lot numbers, or project-specific codes, but those are beyond the scope of static product identifiers.

PIM Platforms (Product Information Management systems) act as a central hub for product data and often manage all these identifiers. A PIM will usually have a primary SKU field for each product (often mirroring the ERP’s internal number) and can have attributes for MPN, GTIN/UPC, brand, etc. PIMs support storing multiple identifiers because they feed data to various channels. For example, a PIM might store that Product X has internal SKU 12345, manufacturer code ABC-99, UPC 00812345678905 and maybe channel-specific IDs (like an Amazon ASIN). Leading PIM systems like Akeneo, Salsify, or Pimcore treat the SKU as the core record key, but they also make it easy to enrich products with standard identifiers (GTIN, etc.) (7 Types of Data You Can Store in a PIM Tool – Plytix) (System Attributes – Help Center – Plytix). This ensures consistency – e.g., if the GTIN changes, it’s updated in one place and pushed out to all marketplaces.

Below is a summary of key identifier types and their typical usage:

Identifier Code	Description	Usage	Example
Internal Part Number (SKU)	Company’s own item code for internal use (may be numeric or alphanumeric; format varies).	Internal ERP/PIM references, inventory, BOMs, internal search. Not usually shared outside (except perhaps on packing slips alongside description).	SKU 10004562 (numeric) ELE-PLUG-015 (letters+nums)
Manufacturer Part Number (MPN)	Code assigned by the manufacturer of the product. Identifies a specific product design across the industry.	Used in procurement and catalog searches to match supplier parts. Often shown on RFQs, purchase orders, and in PIM for reference.	ATX-550-PSU (power supply model) 6205-ZZ-C3 (bearing)
Global Trade Item Number (GTIN)	Global identifier from GS1 (UPC/EAN/JAN/ISBN). Numeric, standard lengths (8, 12, 13 or 14 digits). Enables universal product lookup (e.g. via barcode scan).	Used in retail, logistics, and marketplaces. Essential for scanning, and required by many B2C/B2B e-commerce platforms for product listings (unless exempt).	00850012345012 (14-digit GTIN for a product, corresponds to UPC/EAN)
Customer/Supplier Item Code	A code that a specific customer or supplier uses to refer to the product (might be their SKU or internal number for it).	Used in B2B transactions so each party sees their familiar code on documents. Maintained via cross-reference in ERP/PIM.	Customer X calls the item ABC-1000, Supplier Y calls it XYZ123. Mapped to your internal SKU.

Table: Common product identifier types and their usage in B2B. Internal SKUs are primary within a company, while MPN and GTIN enable external alignment. Cross-references tie them together.

Regional Terminology: It’s worth noting that different regions sometimes use different terms for the internal code. In Europe and the US, SKU (stock-keeping unit) or simply part number is common. In Russia, the term “Артикул” is used for the product code (Заполнение артикула номенклатуры в 1С). In China, terms like “物料编码” (material code) or “产品编码” (product code) are used similarly. Despite language differences, the concept of an internal identifier vs external identifiers is universal.

Regional Variations in Coding Practices

While the fundamental principles of product identification are similar globally, there are some regional tendencies and standards:

• North America & Europe: Companies often follow the best-practice advice of short, non-significant part numbers (e.g. 5–8 digit numeric codes) for internal use (Intelligent part numbers: The cost of being too smart). However, many still include partial meaning (like a 2-3 letter prefix for category). ASCII letters and digits are universally used; one rarely sees accent marks or special symbols in SKUs. Example: A UK electronics distributor might use RES-01000 for a resistor product code (prefix RES for resistors, and a numeric sequence). European and US companies heavily use EAN/UPC codes for externally traded goods – the barcode culture and GS1 standards are well-established. Thus, a manufacturer in Germany will assign EAN-13 codes to each sellable product and share those with partners for listing and scanning. European industries also use standards like MPN and sometimes UNSPSC for classification (though classification codes are outside our scope, they sometimes influence internal code decisions too).
• Russia: Internal product codes (Артикулы) commonly incorporate Russian/European practices. Many Russian firms historically embed meaning in the code (like abbreviations of product type, manufacturer, etc.) (Что такое артикул товара? Использование артикула в 1с) (Что такое артикул товара? Использование артикула в 1с). As illustrated, a complex code might include segments for country, supplier, date, model, etc. These segments are usually in Latin letters and numbers – using Cyrillic letters in codes is rare, because Latin alphanumeric is standard for part numbers even in Russian systems for compatibility. Russia has also introduced a national product marking system (“Честный Знак”) for certain goods, which uses DataMatrix codes encoding a GTIN plus serial number for traceability. That system, however, is more about traceability codes on each unit rather than changing the SKU itself. Russian ERPs like 1C integrate with such systems by storing the GTIN and managing serials, but the internal Артикул remains the primary key. Russian companies dealing internationally will map their Артикул to GTINs and MPNs when sharing data with partners.
• China: Chinese manufacturers and distributors often use numeric codes as internal SKUs. It’s common to see 6-8 digit numbers as product codes in factories. However, many also prefix with letters (often derived from pinyin abbreviations of product categories or the company name). For instance, a Chinese company named “Shenzhen Fasten” might code a fastener product as SF-10001. Chinese ERPs (Kingdee, Inspur) allow Chinese text in descriptions but typically not in the code field – codes stick to alphanumeric to avoid any encoding issues. China has its equivalent of EAN (often called JAN in Asia or simply EAN-13) for retail products, and larger firms will assign these for consumer goods. In B2B, if targeting export or e-commerce, Chinese suppliers know to provide UPC/EAN or at least their MPN for identification. Platforms like Alibaba encourage sellers to list a “Model Number” for each product – effectively the supplier’s part number that buyers can reference.
• Global vs Local Companies: Multinational companies tend to enforce a global item coding standard. For example, a US-based company with branches worldwide might use one unified SKU system so that the same product has one code globally (or at least a structured code that includes a plant/location segment). In contrast, local companies that grew independently may have inconsistent coding schemes (e.g. a legacy code format in one country branch and a different one in another). During ERP harmonization or PIM integration projects, such companies often have to renumber or alias items for consistency. Regional differences also appear in allowed characters: older systems in some countries were numeric-only, whereas others allowed alphanumeric. This sometimes causes issues merging data – e.g., a Japanese system that only used numeric item IDs versus a European one that had letters – requiring conversion or mapping when consolidating.

Identifiers in B2B Marketplaces and Procurement Platforms

B2B marketplaces and procurement platforms serve as intermediaries between different companies’ systems, so they must handle a variety of product identifiers. Key considerations include how they accept product data from sellers (which may include the seller’s internal SKU, MPN, GTIN, etc.), how they validate identifiers, and how they map or expose identifiers to buyers.

• Amazon Business (and Amazon Marketplace): Amazon uses its own internal product ID called the ASIN (Amazon Standard Identification Number), a unique 10-character alphanumeric code assigned to each product in Amazon’s catalog (What is Amazon ASIN number & how to get it?). When a seller wants to list a product on Amazon, if that product already exists in the catalog, they use the existing ASIN (so multiple sellers’ offers link to one ASIN page). If it’s a new product, Amazon requires the seller to provide a GTIN (UPC, EAN, or ISBN) to create the listing (How to create a new ASIN on Amazon). Amazon then generates a new ASIN tied to that GTIN. In essence, Amazon relies on GTINs as a global key to avoid duplicates, and ASIN is Amazon’s surrogate key. Sellers can also assign a Seller SKU for their own inventory tracking – this is an internal reference that only the seller sees (in reports and integration), used to map Amazon orders back to their ERP. Buyers on Amazon Business usually see only the product details and maybe manufacturer identifiers if provided (e.g. Manufacturer Part Number is often displayed on tech product pages). The ASIN is mostly internal, though it’s visible in the product URL and in Amazon’s data feeds. For integration, Amazon provides APIs where one can query by identifiers – e.g. search by UPC or MPN to find matching ASINs (Catalog Items API v2022-04-01 Reference) (Amazon Seller API Integration For All Your Data Needs – SellerApp). Amazon Business also supports punchout integrations to corporate procurement systems: a buyer’s system may pass keywords or known identifiers to Amazon’s search. For better match, Amazon suggests including manufacturer names, part numbers, SKU, etc., in the query (Quick start: Amazon Business integration). Once an order is placed, Amazon’s confirmation can include ASINs and the buyer might maintain a mapping table to their internal codes.
• Alibaba, Made-in-China, Global Sources: These global B2B marketplaces connect buyers with suppliers. Product listings on such platforms typically display a “Model Number” or “Product Code” field provided by the supplier. This corresponds to the supplier’s part number or model ID for the item. Unlike Amazon, Alibaba doesn’t enforce a unified catalog – each supplier’s listing for a similar item is separate. Therefore, there isn’t a single canonical ID for “the same product” across suppliers. Instead, the supplier’s identifier is used within that listing. For example, a PCB component listed on Alibaba might show “Model Number: 2.7v7f” (Model Number-12V1000WH – Alibaba.com) – that is meaningful only in context of that supplier (likely their internal code). Alibaba does not require GTINs or any global code, since it focuses more on industrial and bulk products which may not have barcodes. However, Alibaba’s search engine will match queries on whatever data is provided – including model numbers. A buyer searching for a known MPN may find listings if suppliers included that MPN in the title or description. In summary, marketplaces like Alibaba serve more as listings directories and rely on free-form text plus supplier-provided fields. There’s typically no validation of model numbers globally (two suppliers could use the same model number for very different items). It’s up to the buyer to verify they’re referencing the correct item (often by exchanging specifications or manufacturer info).
• Industry-Specific B2B Platforms: Marketplaces such as Thomasnet (industrial directory), GlobalSpec/IEEE Global Marketplace, or regional ones like Ozon (Russia) or Tmall B2B (China) have varying approaches. Thomasnet historically is a directory of suppliers/products – it will list manufacturer part numbers if provided because it often aggregates catalogs. Tmall’s B2B platform (related to Alibaba) likely follows similar practices to Alibaba for Chinese domestic trade. Ozon, a major e-commerce platform in Russia, functions somewhat like Amazon (with a catalog concept). Ozon might require barcodes for certain categories; they assign their own SKU or ID to listings as well. Sellers on Ozon provide a “Vendor Code” (their SKU) for internal reference, but Ozon will have an internal product ID that buyers see on the site. Many marketplaces encourage or require including GTINs or MPNs for products to improve searchability and trust. For example, a B2B electrical marketplace might require that each listed product include the manufacturer’s part number and the manufacturer name, so that buyers can easily compare the same MPN across distributors.
• Procurement Networks (Ariba, Coupa, etc.): In B2B procurement platforms and EDI systems, the mapping of item IDs is critical. Standards like cXML or EDI (e.g., EDIFACT, ANSI X12) for purchase orders have specific fields for buyer’s item ID, seller’s item ID, and standard item identifiers. For instance, an EDI 850 Purchase Order in X12 format can carry a buyer’s part number and also a vendor part number with qualifiers indicating whose code it is. This ensures that when a buyer sends an electronic PO, it can reference “Item ABC (Buyer’s SKU) – corresponds to Vendor’s SKU 1234”. Platforms like SAP Ariba allow buyers to upload their internal catalog or map to supplier catalogs so that during a punchout (when the buyer is redirected to the supplier’s catalog site), the supplier’s site knows the mapping of IDs. In many cases, buyers maintain an internal cross-reference: e.g. their ERP knows that Supplier X’s item 660-1001 = Internal Item 12345. Modern B2B integrations try to automate this via global standards (like using GTIN if available, since that would be the same on both sides). However, in industrial procurement, GTINs may not exist, so MPN serves as the common denominator – the buyer and seller can agree that the MPN (plus maybe the manufacturer name for disambiguation) is the reference.
• Validation and Duplicate Handling: Marketplaces have to prevent duplicate entries of the same product. Amazon does this via GTIN enforcement (two sellers with the same UPC should list under one ASIN). Other B2B platforms might not have as strict control, leading to duplicate entries. Some B2B platforms employ data normalization: for example, a catalog aggregator might normalize all supplier entries by MPN, so a buyer searching MPN XYZ sees one entry with multiple supplier offers. This is essentially what systems like Actualog aim to do – gather data from different ERPs and catalogs and match items that are actually the same, via common identifiers or attributes. Actualog teams or similar data integrators must compare fields like MPN, descriptions, and specifications to link entries, because internal SKUs will differ for each source. Understanding how each source structures its codes (and which external IDs are present) is vital to automate the matching.

Interoperability and Mapping Challenges

Connecting ERP/PIM systems with external platforms is challenging primarily because identifiers don’t automatically align across organizational boundaries:

• One Product, Many Codes: A single physical product might be known by a dozen codes: multiple distributors each give it a new SKU in their system; the manufacturer has an MPN and maybe a GTIN; various customers each label it with their own SKU internally. This complicates search and integration – without a common key, matching relies on translating one code to another. For example, if a buyer’s ERP only knows its internal code for a spare part, and they attempt to find it on a marketplace, they must know the corresponding MPN or GTIN to search. If they send a purchase order with only their internal number, the supplier might not recognize it unless a prior mapping was established (via a contract catalog or manual communication).
• Data Exchange Standards: To mitigate this, EDI standards include fields for multiple identifiers. A purchase order line in ANSI X12 850 can include a buyer’s item number, a vendor item number, and even a UPC or ISBN if applicable. Similarly, cXML (used in many procurement systems for punchout and order transmission) has <ItemID> elements where you can provide both the supplier’s ID and the buyer’s ID for the item. These standards rely on companies populating those correctly. In practice, initial vendor onboarding involves populating a catalog for the buyer that maps vendor SKUs to buyer SKUs. Maintenance of these mappings is an ongoing effort.
• Length and Character Set Differences: When integrating across systems, limitations of one system can pose problems. For instance, if one ERP allows 40-char alphanumeric codes and another only 30-char or only numeric, some codes might get truncated or need a temporary mapping code when transferring data. Certain symbols might be disallowed in one system. A trivial example: one system might use a slash or dash in codes, while another treats those as special characters. These differences require either cleaning the data or having a translation layer. Global companies often choose a conservative format (e.g. only uppercase letters A-Z and digits) for part numbers to avoid issues when interfacing with older or external systems.
• Human Error and Convention Differences: If a marketplace or external partner mistypes or uses a different variant of an identifier, matches can fail. E.g., a supplier might list an MPN with a dash (ABC-1000), while the buyer records it without the dash (ABC1000). Automated matching needs to normalize these (removing punctuation, etc.). Also, different manufacturers might coincidentally have identical part codes for different items – usually MPNs are only unique in combination with a manufacturer name. So mappings often need the context (Manufacturer X + MPN Y). Without careful data management, a system might erroneously match two items with the same part number that are actually from different makers (leading to incorrect procurement).
• Solutions and Best Practices: To improve interoperability, companies and platforms increasingly rely on global identifiers as the bridge. GTIN is ideal for retail and consumer products – scanning a barcode will universally identify the item. For industrial and MRO (Maintenance/Repair/Operations) products, standards like ISO/IEC part number systems or industry catalogs (like an automotive parts database) are used, but coverage is incomplete. Thus, using the Manufacturer + MPN as a composite key is a de facto standard for matching in B2B. Organizations like GS1 are also expanding standards like GS1 Part Identification (GMN – Global Model Number) for medical devices, etc., to have more universal keys.

Data integrators should establish reference mappings: a master catalog where each real-world product is an entry linked to all known identifiers (all internal SKUs, all known GTINs, MPNs, etc.). PIM systems help achieve this by serving as the central repository where these mappings live. When pushing data to marketplaces, the PIM/ERP can provide the appropriate identifier required (e.g. GTIN for Amazon, or “model number” for Alibaba). Conversely, when pulling orders from a marketplace, the system can translate the received identifier (ASIN or supplier SKU) back to the internal code via the mapping.

Example: A company uses Actualog to integrate data from suppliers. Supplier A’s catalog lists a pump as SKU PMP-200 (MPN XYZ123, GTIN not available). Supplier B sells the same pump under SKU HG-4500. Actualog’s system can recognize both have MPN XYZ123 and thus map them to the same canonical product. The company’s ERP, however, uses its own code 55000098 for that pump. Through integration, Actualog (or the PIM) supplies the ERP with the link that 55000098 ↔ MPN XYZ123. Later, if a buyer searches Actualog or the integrated system for XYZ123 or either supplier code, they can find that it matches their internal item 55000098. This showcases why understanding each source’s identifier structure (length, format, presence of global IDs) is crucial in building these bridges.

(Что такое артикул товара? Использование артикула в 1с) Example: A composite product code in a 1C ERP system (Russian). The “Артикул” field shows CT-PR-0119-TP-4312-F-C, encoding multiple attributes (country, producer, date, type, model, size, color) in one identifier. Such structured codes must be mapped to external identifiers (e.g. GTIN or MPN) for interoperability.

Conclusion

Product identification codes are the lingua franca of B2B data exchange. ERP systems provide the flexibility to use simple or composite codes internally, while PIM platforms centralize multiple identifiers for each product. In practice, a combination of internal SKUs, manufacturer part numbers, and standardized codes (GTIN) are used in tandem to ensure that the same physical item can be recognized across different companies and systems. Regional preferences may shape how codes are structured (with more mnemonic codes in some locales), but the need to map between internal and external references is universal.

For B2B data managers and integrators, key takeaways are:

• Establish a clear internal coding strategy (intelligent vs non-intelligent) that suits your operations, and document it for all users. Balance human-readability with scalability.
• Capture external identifiers (MPNs, GTINs, customer/supplier codes) in your ERP/PIM. Leverage your system’s features (like SAP info records or Dynamics external item descriptions) to store these links (Product identifiers – Supply Chain Management | Dynamics 365 | Microsoft Learn) (Product identifiers – Supply Chain Management | Dynamics 365 | Microsoft Learn).
• Use global standards where possible: GTINs for commercial products, industry-specific standard codes, and include manufacturer info. This greatly eases matching on marketplaces and with partners (Product identifiers – Supply Chain Management | Dynamics 365 | Microsoft Learn).
• Build mapping tables or a master data repository for cross-referencing codes. This could be in a PIM or a middleware like Actualog. Keep it updated as new codes or aliases appear.
• Work with partners to exchange identifiers: when starting business with a new B2B partner, share a list mapping your SKU to their SKU or to common MPNs, to prevent confusion.
• Leverage technology: Utilize search tools that can handle multiple identifiers (e.g. a search that tries the query as an internal SKU, then as an MPN, etc.). Also consider barcode scanning and standards like QR codes if applicable, encoding a globally unique key.

By understanding how different systems structure product IDs – from SAP’s flexible 40-char material numbers to Oracle’s segmented flexfields and regional nuances – data integrators can design processes to translate and synchronize product information across platforms and borders. Ultimately, robust product identification management ensures that when two businesses talk about “Product X”, they are indeed referring to the exact same item, even if each calls it by a different code. This clarity is foundational for efficient B2B commerce in an increasingly interconnected supply chain (Product identifiers – Supply Chain Management | Dynamics 365 | Microsoft Learn).

Sources:

1. SAP R/3 Material Master documentation – number range and assignment (internal vs external) (Material Master (LO-MD-MM)) (Material Master (LO-MD-MM))
2. Oracle Cloud Applications – Key Flexfields example of composite part number (Overview of Key Flexfields)
3. Oracle JD Edwards EnterpriseOne – item numbering fields and cross-references (Item Number) (Item Number)
4. Koderline (1C ERP expert) – guidelines on forming readable article numbers (Артикул) in 1C (Что такое артикул товара? Использование артикула в 1с) (Что такое артикул товара? Использование артикула в 1с)
5. Microsoft Dynamics 365 documentation – maintaining customer/vendor item codes and barcodes/GTIN (Product identifiers – Supply Chain Management | Dynamics 365 | Microsoft Learn) (Product identifiers – Supply Chain Management | Dynamics 365 | Microsoft Learn)
6. BuyPLM Whitepaper – analysis of intelligent (significant) vs non-significant part numbering schemes ( Intelligent part numbers: The cost of being too smart ) ( Intelligent part numbers: The cost of being too smart )
7. Amazon ASIN and product identifier requirements – DataFeedWatch/GS1 summary (What is Amazon ASIN number & how to get it?) (How to create a new ASIN on Amazon)
8. SAP Community – vendor part number in purchase info record (cross-reference)