Häufig gestellte Fragen
What distinguishes an ERP for technical wholesale (PVH) from a classic wholesale ERP?
An ERP for technical wholesale must above all handle very broad and deep assortments, which often range from 50,000 to well over a million items and are classified according to standards such as eCl@ss or ETIM. Added to this are a sophisticated conditions system with framework agreements, scaled prices and customer-specific price lists, plus an EDI connection to industrial customers that is generally mandatory. Also particularly characteristic are C-parts models such as Kanban, RFID warehouses or vendor-managed inventory, and drop shipping with direct dispatch ex works. How deeply these functions are actually needed depends on the assortment, customer structure and sales channels of the individual dealer.
Which classification standards are mandatory in technical wholesale — eCl@ss or ETIM?
In technical wholesale (Produktionsverbindungshandel), eCl@ss (ECLASS) is the de-facto standard; in the current version 16.0, it comprises around 50,000 product classes and over 23,000 properties and describes products via an eight-digit, four-level class code. In electrical engineering as well as in plumbing, heating and air conditioning, however, ETIM dominates, a licence-free standard that is now developed on a two-year release cycle. Since many technical dealers serve both worlds, an ERP should maintain eCl@ss and ETIM in parallel and be able to map between the standards. Depending on the retail chain or marketplace, GS1 GTIN and — in the SAP environment — UNSPSC frequently come on top.
Do I need a dedicated PIM system alongside the ERP for technical wholesale?
With very large assortments of often more than 100,000 items and multiple sales channels such as web shop, marketplaces and print catalogue, a dedicated PIM (Product Information Management) system usually makes sense, because it keeps marketing and classification data consistent across channels. With smaller or more homogeneous assortments, the ERP's master data module combined with solid master data management is often sufficient. Decisive is less the item count alone than the question of how many channels and classification standards must be served in parallel. In practice, many dealers work with a combination of the ERP as the leading system for stock and prices and a PIM for enriching the product data.
Which EDI and e-procurement interfaces must a PVH ERP support?
Anyone supplying industrial customers can hardly avoid EDI based on EDIFACT; the most important message types are ORDERS (purchase order), ORDRSP (order confirmation), DESADV (dispatch advice) and INVOIC (invoice), often supplemented by REMADV for payment advice. For embedding your own assortment into customers' procurement systems, e-procurement or PunchOut standards are also relevant: OCI (Open Catalog Interface) was originally developed by SAP and is widespread in the SAP environment, while cXML, originating from Ariba, shapes many cloud procurement platforms. Via such interfaces, the web shop can be integrated directly into systems such as SAP Ariba, Coupa, Jaggaer or Oracle. Which standard is required is generally dictated by the respective customer's procurement system.
How does an ERP support C-parts management and what benefit does it bring?
C-parts such as screws, fasteners or consumables account for only a small share of purchasing volume by value, but cause the bulk of the administrative procurement effort, which is why a key differentiation lever in technical wholesale lies here. A suitable ERP maps automated supply models such as Kanban boxes, RFID or scale-based warehouses and vendor-managed inventory, and takes over replenishment planning as well as consumption billing. The goal is to replace manual individual orders with consumption-driven resupply, thereby cutting process costs and inventories. Which model makes sense depends on assortment, consumption frequency and customer size; several models are frequently used in parallel.
What does an ERP for technical wholesale cost and how long does implementation take?
Binding flat prices cannot be given, as costs and project duration depend heavily on assortment size, interface requirements, customisation depth and user count. Cloud solutions are usually billed as a monthly fee per user and include updates and maintenance, while on-premise models entail higher upfront investment and separate implementation costs. In the mid-market, the typical implementation duration is roughly between six and eighteen months, with a pilot able to start within a few weeks while the full rollout takes considerably longer. The critical success factors are considered to be less the technology than clean master data, well-designed interface integration, plus training and user acceptance.