V-ZUG is a Swiss manufacturer of premium household appliances. In Australia, its spare parts and service operation runs on a Core dna portal connected to SAP, used by internal technicians, independent service agents and V-ZUG's own service team. Every order posts into SAP (see the main V-ZUG story).
This story covers a master data management problem behind the portal: keeping SAP's material master data complete as new parts and new service locations are added. It also covers how an SAP integration, built as a scheduled job in Core dna's Orchestration module, took that work off the team.
The challenge
Master data management in SAP means keeping the core records the system runs on, such as materials, customers and vendors, complete and consistent. For a material, that goes beyond the product record itself.
In SAP, a product isn't ready to sell just because it exists. Before a spare part can go on a sales order or move between locations, SAP needs several sections of master data completed for that part at each location: logistics, planning, valuation and availability confirmation.
V-ZUG runs a network of service locations in Australia. Each time a new part was added to SAP, its records had to be created for every location. Each time a new location was set up, records had to be created for every part, plus a transportation lane. If one record was missing, an order or a stock transfer for that part at that location couldn't go through, often while a technician was waiting for the part.
The work grows with the number of parts multiplied by the number of locations, and doing it by hand meant a person had to remember every combination.
What V-ZUG needed
- Every spare part ready to order and transfer at every service location.
- No manual checking each time a part or a location is added.
- The records created in SAP, through SAP's own APIs, so SAP stays the system of record.
- A clear exception for anything SAP's APIs can't do.
How the SAP integration runs
A daily check across every part. A scheduled job in Core dna's Orchestration module runs once a day. It fetches every material in SAP's spare parts category through SAP's OData API.
The list of locations lives in Core dna. V-ZUG's service locations are kept as a list in Core dna. For each part, the job checks whether SAP has the master data for every location on the list.
Missing records created through SAP's APIs. Where a part is missing records at a location, the job runs a second routine for that part and location. It creates the planning, availability confirmation and logistics records through the OData API, and the valuation record through SAP's SOAP web service.
One step stays manual. A new location also needs a transportation lane in SAP, and SAP's APIs don't allow it to be created. It's one record per new location, so the team adds it by hand when a location opens.
The result: a new part is ready at every location within a day, and a new location is ready for every part after one change to the list.
Want to see how it works?
Book a call with Core dna. We'll show you how scheduled jobs keep your ERP data complete, and how that would work for your products and locations.
Questions to answer before automating SAP master data management
Any business selling or moving stock across several locations runs into the same problem. These questions help you scope it:
- Which records does your ERP need before a product can be sold or moved? List them per location, warehouse or sales channel.
- What creates the work? A new product, a new location, or both.
- Can every record be created through the ERP's API? Check each one. Some can't, as V-ZUG found with transportation lanes, and those need an owner.
- Where does the list of locations live? Keeping it next to the job makes adding a location a one-line change.
- How often should it run? A daily check suited V-ZUG's spare parts. A faster-moving catalog may need the job to run when a product is created.
For the wider picture, see B2B eCommerce ERP integration: what syncs, what it costs and how to plan it.
