What “we use 1C” actually means
Start with the configuration name, its version, details of customisations, and the contact of the specialist who maintains the database. Trade Management, Manage Our Company, and a configuration modified in-house present different starting conditions. It also matters where the database runs and which connections are permitted.
1C publishes a website exchange protocol based on CommerceML. It separates catalogue transfers from order exchange. This is a useful starting point for discussing compatibility, but the protocol documentation does not establish that a particular store and customised database already exchange every required field. Their actual connection needs checking. See the website exchange protocol.
Before agreeing the full estimate, we recommend requesting a sample export. It reveals how attributes, variants, prices and warehouses are represented. Such a file is more useful than the assurance that “the format is standard”: it shows the data that will actually be used.
Every value needs an authoritative source
Suppose product descriptions are edited on the website, prices are set in 1C, and a content manager uploads photographs. The next exchange should update the price while preserving the description and photographs. Without defined rules, a new export could overwrite editorial work or create a second product.
For each dataset, record its source, transfer direction and update rule. For products, this means a persistent identifier, name, variants and attributes. For trading data, it means price type, warehouse, quantity and availability. For orders, it means items, customer, delivery, amount and statuses. Everything need not be transferred immediately: prioritise the data that supports the agreed sales scenario.
Discuss identification separately. Product names can change, and different suppliers sometimes use the same article numbers. Matching must survive a rename. We recommend producing a field mapping with examples and an explanation of which values may be edited on each side.
Warehouse stock and availability to buy
The number of units in a warehouse is not always the quantity that can be sold through the website. Some may be reserved, some may belong to another warehouse, and some may await inspection. The store needs a definition of the available quantity and the point at which it changes.
Consider a hypothetical example. One unit remains in stock, a customer starts payment, and a manager enters an offline order for the same item. The outcome depends on the reservation rule: when a reservation arises, who confirms it, and when it is released. The exchange interval alone does not resolve this conflict.
The contract should describe acceptable behaviour during delays: temporarily stop purchases of the disputed item, accept an order subject to confirmation, or continue selling at an agreed risk. The business must make this choice. The developer is responsible for making the implemented scenario follow that decision and showing staff the exceptions.
An order must survive a repeated transfer
The customer pays, the website sends the order to the accounting system, but the response never arrives; restoring the exchange requires sending the data again. A recommended acceptance criterion is that the system recognises the existing order, preserves its agreed links to accounting documents, and does not create a duplicate sale.
The meaning of statuses also needs agreement. Paid, assembled and dispatched describe different events. If the website confirms payment and the warehouse in 1C confirms dispatch, two-way exchange must prevent an old state from overriding a new one. Returns and partial cancellations require a separate discussion: which documents are created, and who is authorised to confirm the financial operation.
What to test before handover
We recommend accepting the exchange on a copy of the database or in another agreed test environment. The product set should include a regular item, a variant with an attribute, an out-of-stock item, and an item whose price has changed. Record the expected result for each example and compare it with the actual state in both systems.
Next, send an order through to the accounting system, repeat the transfer, cancel the purchase, and check that the reservation is released. A separate scenario is temporary 1C downtime: can staff see which orders are waiting for transfer, who receives a notification, and how service is restored? A screenshot of a green exchange button does not replace this reconciliation.
To discuss online store development with pommeDeTerre, you can send a description of the configuration, a sample catalogue, and an outline of staff workflows. These materials help distinguish existing capabilities from necessary modifications. Treat 1C exchange as a separate part of the store project with a clear deliverable; the overall launch scope is explained in our guide to complete online store development.