Importing a supplier price file into a CMS: how to check changes before publication

A CMS price-file import should be designed as a verifiable batch of changes, not a button that immediately overwrites the catalogue. First, match supplier rows to the correct products, define what prices and empty fields mean, and show what will change. Invalid or ambiguous rows must be stopped. Only the specific reviewed change set should proceed to publication, with its origin traceable and a safe way to correct an error.

For a catalogue manager, the main question is not whether the system can open CSV or XLSX. They need to know whether a price in the new file refers to the same product, packaging and currency currently shown on the website. Technically reading a table successfully does not yet mean the business result is correct.

CMS price-file imports start with field meanings

Before development, prepare an anonymised supplier-file sample alongside a list of CMS fields. Define the destination, format and error handling for each input field. An unexplained price might mean a purchase price, a recommended selling price or a price for a particular pack. The importer must not guess this distinction from the column heading.

Agree on the supplier file's role too. Is it a complete current product range or only a list of changes? That answer determines what a missing row means. If the file contains only changes, an omitted product cannot automatically become unavailable. A complete list may be handled differently, but that behaviour must also be defined and tested before publication.

Version the field mapping. A supplier may change a heading or add a column, and the importer needs to recognise when a received file no longer matches the agreed format. The same column acquiring a new meaning is an even worse situation. Development requirements should therefore include reviewing both the technical format and the material business assumptions.

Match a product by its identifier, not a similar name

A name helps people, but can change, differ between languages or be shared by several variants. Match records using an agreed stable identifier. If a supplier's code is unique only within their catalogue, include the supplier in the match. A product family and a specific saleable variant are not automatically the same record.

If the supplier code is not yet known to the CMS, the outcome must be explicit: a candidate new product, an unresolved match or an error. Do not let name-similarity searches silently select an existing product and change its price. A person can approve a match, but the system must retain that decision so it does not have to guess again next time.

Odoo 18's import documentation describes external identifiers for matching data in that particular system. The practical implication for a custom CMS is to require an unambiguous key and a verifiable match. It does not mean every CMS automatically uses the same import mechanism.

Include two rows with the same supplier code but different prices in the demonstration. The import should not silently accept the last row. A duplicate is a conflict that must be visible in the preview. Also test a product whose name has changed while its identifier remains the same: correcting the name must not by itself create a second item.

An empty price, zero and a missing row are different states

An empty price field may mean “do not change”, “no price supplied” or “delete the value”. Zero is a specific numeric value. A row absent from the file altogether is another case. Collapsing these states can cause an incorrect import to delete prices or publish a product as free.

Record how each state is handled in the field map. For example, an empty price in a price-change file could be blocked as incomplete input, while a price column omitted entirely from a product-description update could mean that field is left untouched. These are examples of selectable import policies, not universal properties of CSV.

The cited Odoo documentation distinguishes omitting a field from importing an empty value. This is a good reason to check the distinction in your own system too. A development brief should not simply say “ignore empty fields” without explaining how incorrect information will later be deliberately removed.

Define the zero-price rule separately. If zero is not permitted in the catalogue, the row must be stopped. A justified exception cannot be applied to every product. The manager needs to see both the value and the reason for the decision. This prevents a mistakenly empty field from becoming an accepted zero during technical conversion.

A field map for the demonstration file

This is an illustrative field map. Agree the actual names with the supplier and the CMS model. The demonstration price of 12.50 EUR is neither market data nor an offer.

Check decimal commas and delimiters together. If a CSV uses commas to separate columns, the price notation must be correctly represented for that format. The importer must follow the agreed file format rather than arbitrarily removing commas until the value becomes a number. Also check spaces and textual currency markers if the supplier uses them.

Do not treat a currency change as a formatting correction. If the CMS expects EUR but the file contains another currency, an explicit conversion policy or a block is required. The same applies to pack prices versus unit prices. Without agreed rules, a mathematically valid number can become a commercially incorrect price.

Make the change preview understandable

Show the old and proposed values beside the product in the preview. The total processed-row count is useful, but does not replace a list of differences. The catalogue manager must be able to distinguish a new product, a price change, a status change, an unchanged record and an unresolved match.

Large price changes may require additional review, but the threshold must suit the company's range. There is no universal acceptable percentage price change. Even a small change can be wrong if the currency or unit has changed. Base checks on the meaning of the data first, not just the size of the numeric difference.

Put invalid rows in a separate, clearly labelled list with reasons. If the system permits the remaining rows to be published, that must be an explicit batch decision. Establish whether the rows are independent. For a set whose component-pricing rules must change together, partial publication may produce inconsistent results.

The approved preview must match the change set to be published. If a different file is uploaded or the field mapping changes after review, the earlier decision does not cover it. The system must require a fresh check instead of applying old approval to new content.

Test this binding in the demonstration rather than relying on an “approved” checkbox. Prepare a preview, then change one product's price in another administration window. When the old batch is applied, the system must establish whether its assumptions still hold. If the old value shown in the preview is no longer current, the user must see a conflict and make a new decision. Otherwise, they approve one situation while the system acts in another.

Another test is uploading a different file with the same name. A matching filename must not inherit the previous batch's approval. The manager must see a new comparison and be able to open the exact original used for it. This applies even to a small correction in one row: if the content to be published has changed, it must be clear which version was checked. Silent replacement destroys the ability to explain the decision later.

Give prepared, rejected, approved and applied batches distinct names in the workflow. These labels help staff understand whether a price has already changed or is still awaiting a decision. Every transition needs an owner and an outcome. If application is interrupted, the status must show unfinished work rather than returning to the beginning as though nothing happened.

This check can use an anonymised catalogue without putting public prices at risk. Keep the expected behaviour and actual observation in the acceptance record. If a supplier promises conflict controls but the demonstration shows only a generic error message, clarify how staff will identify the affected product and continue safely. Resolve this before enabling automatic publication.

What to block and what to send for review

Errors that make the result ambiguous must block import: an unrecognised price format, unclear currency, conflicting identifier or unauthorised field change. A generic “continue anyway” button cannot resolve them. A corrected file or an explicit separate data decision is needed.

A structurally valid but commercially unusual change can be sent for review. A supplier may legitimately change its range, for example, but the manager needs to establish whether that also applies to products published on the website. What matters is the reason and the decision owner, not a requirement to always accept or always reject every exception.

File upload is also a security boundary. OWASP describes CSV injection, where spreadsheet software interprets untrusted values as formulas. Do not make executing supplier formulas the default way to obtain prices. When exporting an error report, also check how its untrusted content will be opened and displayed.

Do not reduce security requirements to a file extension. Define size and format limits, access to originals and their storage. If a file does not match the expected contract, processing must stop with a clear reason. The catalogue manager must not have to run a macro to discover which prices were received.

Acceptance tests with invalid rows

Deliberately include valid and invalid rows in the demonstration file. The expected outcomes below are example requirements that must be agreed in the company's import policy.

The demonstration also needs a failure during publication. It must be possible to identify which changes took effect and which did not. A vague “import failed” message is inadequate if some prices have already changed. Specify whether the batch is applied as a whole or in clearly traceable parts, and how the system resumes after an interruption.

During acceptance, compare the public catalogue with the administration view too. A price saved in the CMS does not necessarily mean the customer already sees the same version. Where caching or a separate publishing queue is involved, it must be clear where to check the final result. Ask for a demonstration of the specific path, not a general promise of instant updates.

Rollback must not overwrite later corrections

Retain the batch's original file, field-map version, preview and list of applied changes. Each changed field needs its previous value and enough information to identify the change. A filename alone is not a reliable batch identity because different content can arrive under the same name.

Rollback cannot always be performed by simply loading yesterday's table. Another employee may since have approved a new price or corrected an individual error. Before restoring values, the system must compare the current state with the result of the batch being reversed. Show conflicts so that rolling back an old batch does not erase later valid corrections.

Demonstrate that exact situation: publish a test batch, change one record separately, then request rollback. Check whether the system distinguishes the original batch's changes from the later edit. Backups matter for recovery, but do not by themselves provide selective batch rollback without side effects.

What to prepare before CMS development

Collect anonymised supplier files in the different formats actually used and explain the meaning of each column. Include examples that currently require a manual decision. You do not need to specify the entire technical implementation, but the team must agree which data may change automatically and who approves exceptions.

The CMS content model helps define fields and relationships, while choosing an authoritative data source helps establish who may change them. Import requirements need to turn these decisions into verifiable batch acceptance.

If you need custom CMS development for your company, send an anonymised supplier file and a sample of the CMS fields for an import assessment. Start with the change preview and a demonstration of invalid rows. A safe import has a result that can be explained before publication and traced afterwards.