Business ·
A website and 1C must agree on ownership, not just file formats
“Connect the website to 1C” sounds like a single setting. It is actually an agreement between two systems about products, prices, stock and orders. Without an owner for every field and a plan for failures, the exchange may run technically while customers still see unavailable goods or orders disappear.
Start with the journey of one order
Trace a particular product. Where is its record created? Who changes its price? When is stock considered available? At what point does the order appear in 1C, and when may the website call it confirmed? Those questions turn a vague integration into a set of testable events.
In a simple setup, the accounting system sends catalogue data, prices and stock to the site, while the site sends orders back. A company may instead have a separate product information system, several warehouses, negotiated prices or reservations at checkout. The design must follow the team's actual work rather than a product label.
A stable identifier matters more than a familiar name
Product names change for the storefront, codes may be reused, and a size or colour may become a separate variant. Matching records by name alone can create duplicates or update the wrong stock item. Products and variants need stable keys and a mapping between the two systems.
Before moving a large catalogue, test a small sample: an ordinary item, a variant, a discontinued item and one with no stock. Check edits, removal from sale and repeated imports without duplication, not only the first creation.
Price and stock follow different rules
Price may depend on customer type, region, currency or promotion. Stock depends on warehouse, reservations and update frequency. A single “available” field can hide several states: ready to purchase, available on request, sold out or temporarily unknown.
Agree on the delay the business can tolerate and what the site shows when its data is old. Asking a manager to confirm availability is better than confidently accepting an order that cannot be fulfilled. Give each state an action and an owner instead of leaving ambiguity to the interface.
Repeat messages without repeating the sale
The connection may fail after 1C has accepted an order but before the website receives confirmation. Sending it again without a stable operation ID can create two sales. The site should send an identifier and the receiving system should recognise a retry and return the result of the existing order.
Statuses need translation too. “Paid” on the site, “ready to dispatch” in accounting and “cancelled” after a refund belong to different stages of a lifecycle. Define the permitted transitions, the authority for the final status and what happens when someone edits an order manually in one system.
Choose the mechanism after checking the configuration
1C publishes a website exchange protocol based on CommerceML 2 that covers catalogue and order exchange. That does not mean any two specific 1C configurations and any website support precisely the same fields without adaptation. A standard exchange may fit, or the project may need an intermediary or another interface.
Before development, identify the 1C version and configuration, the CMS capabilities, catalogue size, acceptable delay and the owner of changes on each side. The chosen design should retain an exchange log and a safe way to retry failed operations.
Acceptance begins with reconciliation
Test a new item, a price change, insufficient stock, a new order, a retry, a cancellation and temporary 1C unavailability. Compare the records in both systems after each test. Check separately whether the responsible person can see a stuck exchange and recover it without manually creating a duplicate order.
A successful integration is not a green connection indicator. It is an order that the customer and the team see consistently. When designing a website or business automation, I start with the data map and test scenarios; they determine the exchange mechanism and the actual development scope.
Start with the website's purpose
If you are planning a website or rethinking one, we can begin with its role in your business, its structure and the visitor's path to an enquiry.