ERP (Enterprise Resource Planning)
An ERP is the system of record for a company's transactional operations: purchasing, inventory, pricing, order management, and finance. In product data terms, the ERP holds the item master, the record that has to exist before a part can be bought, stocked, priced, or shipped. It is authoritative for commercial and logistics fields, but it was never built to store the descriptive attributes, images, or copy a buyer reads.
What an ERP actually holds
ERP systems — SAP, Oracle, Infor, Epicor, NetSuite, Microsoft Dynamics — run the transactional side of the business. Product data enters the ERP because a transaction needs it. You can't buy, stock, price, or ship a part that doesn't exist in the item master.
That makes the ERP authoritative for a narrow, high-stakes set of fields:
- Item number / SKU — the internal key everything else joins to
- Cost, list price, price book assignments
- Unit of measure and pack hierarchy — each, box of 50, case of 10 boxes
- Supplier, MPN, lead time, minimum order quantity
- Weight, dimensions, hazmat flags, HS code
- On-hand quantity, warehouse, bin, lot/serial control
For a 3/8-16 x 2" Grade 8 hex cap screw, the ERP knows what it costs, that it sells in boxes of 50, that it weighs a fraction of a pound, who supplies it, and how many sit in DC-2.
What the ERP does not know: that it's Grade 8 and not Grade 5, that the thread pitch is 16 TPI, that the finish is yellow zinc chromate, or what it looks like. None of that is needed to move the part, so none of it is there.
ERP vs PIM: the field-level boundary
The clean way to draw the line: if a field affects money or movement, it belongs in the ERP. If it affects a buying decision, it belongs in the PIM.
| Field | Home system | Example value |
|---|---|---|
| Item number | ERP | 84-3821-G8 |
| Standard cost | ERP | 0.41 |
| Unit of measure / pack | ERP | EA; BX/50; CS/10 BX |
| Ship weight and dims | ERP | 0.06 lb; 2.4 x 0.6 x 0.6 in |
| Supplier | ERP | (vendor account) |
| Manufacturer part number | ERP | HXC-38162-G8YZ |
| HS code | ERP | 7318.15 |
| GTIN | Either (issued once, published from PIM) | 00812345678901 |
| Category / taxonomy node | PIM | Fasteners > Bolts > Hex Cap Screws |
| Thread size and pitch | PIM | 3/8-16 |
| Material grade | PIM | SAE Grade 8 medium carbon alloy |
| Finish | PIM | Yellow zinc chromate |
| Tensile strength | PIM | 150,000 psi |
| Marketing description | PIM | long-form copy |
| Images, CAD, spec sheets | Digital asset manager / PIM | .jpg, .stp, .pdf |
| Channel-specific titles | PIM | Amazon, punchout, print |
The GTIN row is where most arguments happen. Assign it in the ERP if barcodes drive receiving and picking. Assign it in the PIM if it gets issued during new item setup for syndication. Either is defensible. Two owners is not defensible, because two owners means two truths and a support ticket.
Why the ERP seeds the catalog and then stops
Almost every product-data project starts with an ERP extract, because that extract is the only complete list of what you actually sell, and it becomes the spine of the catalog.
Then the problem shows up. An ERP item master carries the fields a transaction needs. A buyer filtering for a hex cap screw needs the ones it doesn't: thread size, thread pitch, length, drive type, grade, material, finish, tensile strength, head style, compliance marks.
So the ERP hands the PIM a spine with a thin fill rate and a description field like BOLT HEX 3/8-16X2 G8 YZ, a 23-character string written by a purchasing clerk for a green-screen terminal.
That string is not a product title. It isn't a description either. It's a receiving label. It won't rank, it won't filter, and it won't survive a marketplace listing template.
The gap between the ERP extract and a complete PIM record is where the real product-data work sits. No ERP is going to close it, and a PIM will not close it either, because a PIM is where completed records get stored rather than where they get built.
Where Anglera fits
The boundary holds for a reason that has nothing to do with tooling. ERP fields are governed by finance and operations, and they change through those teams' processes, on their calendar, with an audit trail behind them. Descriptive attributes are governed by merchandising and change constantly as new categories and channel requirements land.
Directionality is the part teams get wrong. A bidirectional sync sounds accommodating and reads as low-risk on an architecture diagram, but it means a merchandiser editing a title in the PIM can reach a field that finance closes the books against. The narrow exceptions, a GTIN or a category code assigned during new item setup, belong in a named integration with a defined field list rather than an open channel.
Keeping the two systems separate with one direction of flow, ERP to PIM and never the reverse, is what stops them from corrupting each other. Get that arrow on the whiteboard before anyone talks about tooling.
That boundary is also what leaves a gap, and the gap is where Anglera works. The ERP stays authoritative for cost, UOM, weight, and supplier, and nobody should touch those from a catalog tool. The PIM stays the store of record for descriptive attributes. Anglera does the work of filling the PIM's empty columns:
- Take the ERP item master extract as the SKU spine, then read supplier PDFs, spec sheets, and manufacturer sites for real attribute values, parsing
BOLT HEX 3/8-16X2 G8 YZinto structured fields: thread_size = 3/8-16, length = 2 in, grade = SAE Grade 8, finish = yellow zinc - Write completed records back to Akeneo, Salsify, Syndigo, inriver, or Pimberly, never back to the ERP
Frequently asked questions
Can I just use my ERP as a PIM?
Not once the catalog needs to describe things rather than move them. ERP item masters are built around a fixed field structure shared by every item, so adding thread pitch, tensile strength, and finish means custom fields that also apply to items where they are meaningless. PIMs handle per-category attribute sets natively. An item master is also not built for channel-specific content, locale variants, or digital assets.
Which system should own the GTIN?
Whichever one issues it first. If barcodes drive receiving, picking, and shipping, the ERP owns the GTIN and the PIM receives it. If GTINs get assigned during new item setup for syndication, the PIM can own it and push to the ERP. What matters is that exactly one system is allowed to change the value.
Does product data flow from ERP to PIM or both ways?
One direction for almost everything: ERP to PIM. The ERP pushes item number, cost, pack hierarchy, lead time, and ship weight. The PIM never writes those back. The rare exception is a GTIN or category code assigned in the PIM during new item setup, and that should be an explicit, audited integration with a named field list rather than a general bidirectional sync.
How much of my PIM can the ERP populate?
Enough to identify the item and move it, and no further. The ERP gives you identity and logistics. It gives you nothing on material, grade, dimensions in a buyer's terms, compliance marks, or copy. Expect an ERP extract to land well short of a real category schema, and plan the attribute work as its own workstream rather than a cleanup pass after go-live.
Do I need a PIM at all if I have an ERP and a webstore?
If you sell through one channel and the catalog is small enough for one merchandiser to hold in their head, an ERP plus your ecommerce platform's product fields can work. The break points are multiple channels wanting different titles and taxonomies, category-specific attributes, and asset management. Once you're maintaining the same attribute in more than one system, a PIM starts paying for itself.