Supplier XML Product and Stock Integration

Reading a supplier’s XML feed does not by itself establish that products will update correctly. The supplier’s identifiers must map to your catalogue, price fields need a defined meaning and a missing record needs an agreed response. I build that controlled import with a visible run history and a review queue for uncertain products.

XML is a structured file format, not a universal product catalogue specification. Suppliers can use different fields and conventions. I first inspect an authorised sample, its delivery schedule and its intended use. Finding a feed address is not enough to assume unrestricted access.

Example: ABC-10 updates while ABC-11 needs review

The illustrated data is fictional. Product ABC-10 arrives with stock 24 and price €100. Its mapping points to the corresponding application record. The 09:10 import validates and updates those values, retaining the source time on the product screen.

Product ABC-11 is missing from the received feed. That is not automatically treated as zero stock. The download could be incomplete, the item temporarily omitted, or the supplier’s catalogue scope changed. Without an agreed rule, the record goes to review. An absent product and an explicit zero quantity remain different conditions.

Establish what each field means

Supplier stock and your own warehouse stock are separate concepts. If the source provides an available-to-order quantity, it can have its own clearly named field. Currency, tax treatment and whether a price is a purchase or selling price are mapped explicitly. The illustrative €100 does not automatically become the price shown to your customers.

For variants, I distinguish the parent item from the colour or size identifier. When two suppliers provide an item, we decide which source controls each field. If older values remain available during an outage, their age stays visible. A failed download should not silently reset every stock quantity to zero.

When simple imports are enough

Sheets import functions can retrieve suitable data; Google documents their refresh behaviour and limits. If a basic list meets the need, I can retain that method. A custom application is useful when product mapping, exception review and publication rules must work together. Source access and usage conditions still apply.

Making the scope testable

I start with a de-identified example of your current file or screen and the roles of the people using it. The written scope defines where each field comes from, who can change it and where the result goes. I test an absent ABC-11, an explicit zero-stock row and an incomplete XML download. Those three conditions should produce distinct, explainable outcomes in the application.

The scope also covers exports, the backup approach and who handles failures. We review the first version against one real workflow before planning further connections.

Frequently Asked Questions

Can missing products be removed from sale?

That behaviour can be defined, but only with checks that establish whether the feed is complete. A genuinely withdrawn product needs to be distinguished from one missing because an import failed.

What happens if the XML structure changes?

Required-field checks should identify the change. Unknown data should go to review rather than being written into existing stock or price fields based on a guess.

Can several suppliers be connected?

Yes, with separate mappings and field ownership in scope. Identical-looking codes from different suppliers are not automatically treated as the same product.

Discuss your workflow

For a related workflow, see Automatically Combine Excel Files into One App. Explore custom web applications for your team or contact me with an example of the process you want to improve.