Integrating 1C with a website means automatic data exchange between your accounting system and the site. The catalogue, prices and stock levels go from 1C to the site; orders and customer data go from the site to 1C. That way the site always shows current prices and availability, and sales managers don't have to transfer orders by hand.
How much work the integration takes depends above all on the form in which the data is available on the 1C side. Below: what is usually exchanged, in which direction and how often, how standard exchange differs from an API, and what to prepare in advance.
Why integrate 1C with your website
Without integration, the website and 1C live separate lives, and someone has to reconcile them by hand. It usually shows in a few ways:
-
Prices on the site lag behind. The price list was updated in 1C, but someone forgot about the site. A buyer sends a request based on the old price, and the sales manager has to open the conversation with awkward explanations.
-
Availability doesn't match. The site says "in stock", but the warehouse is empty. Or the other way round: the product is there, but the site doesn't show it.
-
Orders are re-keyed by hand. A sales manager copies an order from the site into 1C, gets an item code or a quantity wrong, and the error surfaces at shipment.
-
Customers get duplicated. A sales manager couldn't find a wholesale customer in 1C by name and created them again, so their order history is now split across two records.
Integration removes manual transfer: the site shows what is in your records, and orders get into your records on their own. Sales managers deal with customers instead of copying lines from one program to another. For wholesale buyers it's also a matter of trust: if the data on the site has ever failed to match reality, the buyer will double-check everything by phone from then on.
What to exchange, in which direction and how often
The direction and frequency of the exchange are set separately for each type of data. The principle is simple: the faster the data changes and the more an error costs, the more often you sync.
-
Catalogue — from 1C to the site, when it changes or once a day. Products, product groups, item codes, attributes. Photos and detailed descriptions are often easier to manage on the site, with only the accounting data coming from 1C. Names in 1C are usually in Russian, so translations for the Uzbek version of the site are also easier to manage on the site.
-
Prices — from 1C to the site, after every price list change. Retail, wholesale, dealer: only the price types you need go to the site, and each buyer sees their own. The currency matches the one used for prices in 1C: soum or dollars.
-
Stock levels — from 1C to the site, more often than anything else. Especially if a product sells quickly or stock is low.
-
Orders and customers — from the site to 1C, immediately. An order arrives with all its lines and the buyer's details and is matched to the right customer record. For wholesale, the link also works in the other direction: the site needs to know the buyer's terms from 1C to show them their prices.
-
Order statuses — from 1C to the site. These are needed if your buyers have a client portal, for example on a B2B website with a dealer portal. We cover what else such a site needs in our article on a manufacturer's B2B website.
Standard exchange or API integration
Data exchange between 1C and a website is usually set up in one of two ways:
-
Standard exchange. Many standard 1C configurations have a built-in website exchange: on a schedule, it exports the catalogue, prices and stock levels and picks up orders. It suits you if your 1C is close to the standard configuration and the site needs a standard set of data. There's one limitation: the exchange transfers only what it was designed for, and non-standard fields and rules require customisation.
-
API integration between 1C and the website. The site and 1C exchange data through a programming interface: one side requests what it needs, and the other responds. This lets you transfer exactly the fields you need and, for example, check stock at the moment an order is placed. But work is usually needed on both sides, including in 1C itself.
Which route is right for you depends on the form in which the data is available on the 1C side: whether there's a ready-made exchange, how heavily the database has been customised and where the fields you need are stored. That's why it's more honest to estimate the scope of work after looking at your 1C, not just from a description of the site.
What to prepare on the 1C side
The tidier the data in 1C, the fewer surprises at launch:
-
A clean catalogue. No duplicates, and a unique item code for every product. Anything duplicated in 1C will be duplicated on the site too.
-
A list of what to show. Which product groups go on the site and which don't: shop-floor materials, archived products, internal items.
-
Attributes for the site. If the site needs filters by size or material, those attributes must be filled in the same way in 1C for every product in the group.
-
Price types and warehouses. Which prices go to whom, and stock from which warehouses.
-
Someone who knows your 1C. An in-house developer or a contractor who maintains the database and can give access.
-
A copy of the database for testing. The exchange is set up and tested away from live data.
This preparation largely determines the scope of work. If 1C is in good order and has a standard exchange, it all comes down to configuration and testing. If the catalogue is full of duplicates and the data you need is kept in comments or separate files, you'll first have to tidy up 1C itself.
What usually breaks and how to plan for it
-
Duplicate products. On a repeat export, a product is created again, and two identical product pages appear on the site. The fix is to agree in advance on the permanent key that links a product on the site to the product in 1C.
-
Mismatched item codes. If products used to be added to the site by hand, their item codes may not match 1C. They are mapped once, before the first exchange.
-
Different units of measure. In 1C a product is counted in individual units, but on the site it's sold by the pack. The conversion has to be built into the exchange in advance, or stock levels and orders will stop matching.
-
The exchange fails silently. An error occurred, nobody noticed, and the site shows old prices for several days. You need an exchange log and a notification to the person responsible, in Telegram for example, if an exchange fails.
-
An order doesn't reach 1C. For example, it contains a product without an item code. Such orders must not disappear: a sales manager gets an alert and handles them manually.
-
Changes in 1C. After customisation or a database update, it's worth checking the exchange: what worked yesterday may have stopped working today.
The same risks apply to any integration, not just with 1C. We went through them in detail in our article on connecting a website to a CRM.
Checklist
-
Catalogue. There are no duplicates in 1C, and every product has a unique item code.
-
Prices and warehouses. You know which price types and which warehouses should feed into the site.
-
Descriptions. You've decided where photos and descriptions are managed: in 1C or on the site.
-
Frequency. You've defined how often to update the catalogue, prices and stock levels.
-
Orders. An order from the site gets into 1C without manual entry.
-
Monitoring. If the exchange stops, a specific person finds out the same day.
-
Testing. There's a copy of the 1C database for testing the exchange.
If you want to connect your website to 1C, or sort out an exchange that's hit and miss, we'll look at the form in which the data is available in your 1C and suggest the right approach. There's more on our integrations with external services page and on the "Website for a manufacturing company" page. One example of our work is the website of BOFPCB, a printed circuit board manufacturer.