Find the operation
The log records the identifier, time, source, result and error reason. You can see which data is waiting for transfer and which has already been accepted.
01 / 1C INTEGRATIONBIG FISH / SYSTEMS THAT WORK
1C integration with websites and CRM
Prices, stock, orders and payments follow clear exchange rules. Accounting stays in 1C. Your team spends less time transferring data by hand.
Explore an example ↘1C ↔ WEBSITE ↔ CRM / CONTROLLED DATA EXCHANGESCROLL TO EXPLORE ↓
No manual transfers. No guesswork.
The manager sees a payment in CRM, the customer sees available stock on the website, and the accountant sees the order in 1C. For each object, we define the source, exchange direction and acceptable delay. If the connection fails, the operation can be found, checked and completed.
THE DATA WE CONNECTEvery object has
Every object has
its own source.
This is a typical arrangement, not a universal rule. We define ownership of each field for your project.
| Object | Typical direction | What we agree |
|---|---|---|
| Catalogue and prices | 1C → website / CRM | Identifiers, price types, attributes and publishing rules |
| Stock and reservations | 1C / ERP → website | Available stock, warehouse and update timing |
| Order and customer | Website / CRM → 1C | Order contents, legal entity, customer and duplicate checks |
| Payments and documents | 1C → CRM / portal | Confirmation, partial payments, cancellation and refunds |
| Dispatch and status | Accounting → customer services | Transition rules, documents and viewing permissions |
INTERACTIVE / TRY IT YOURSELFMore than an arrow.
More than an arrow.
Exchange you can verify.
A learning model running in your browser. It creates no real documents or payments. Simulate a failure, then retry: the result should not be duplicated.
SOURCE
RESULT
Waiting for transfer
Run a scenario.
Operation log
EXCHANGE IN EVERYDAY WORKThe connection fails.
The connection fails.
The history stays.
A retry is not a duplicate
The same external identifier links a retry to an existing document. We separately test the case where the document was created but the response was lost.
Different errors need different actions
A temporary failure can be retried after a delay. An unknown SKU, incorrect legal entity or missing permission needs a correction, not endless resending.
Reconcile the result
We compare checksums, object counts and selected documents. A successful HTTP response alone does not confirm that the entire accounting workflow is correct.
EXCHANGE INTERFACESThe method depends
The method depends
on your 1C setup.
HTTP services
For operations with custom rules and data formats. We agree the request contract, response, authentication and retry controls.
CommerceML
For supported catalogue and order exchange scenarios. We check module compatibility, format versions and configuration specifics.
OData
For access to published objects through the platform's standard interface. Available data and permissions are limited to what the task requires.
Existing interfaces
We account for SOAP, existing modules and scheduled exchange. We retain a working contract when it meets the requirements and remains supported.
FROM DATA MAPPING TO LAUNCH
Start with one complete route.
- 01
Discovery
We identify the 1C configuration and customisations, available interfaces, data volumes, system owners and acceptable delays.
- 02
Exchange contract
We document fields, directions, identifiers, required validation and error correction rules.
- 03
Pilot and reconciliation
We test the catalogue, orders and payments on a database copy. We simulate retries, downtime and invalid data.
- 04
Production switchover
We plan the initial data load and transfer of new changes. We assign responsibility for monitoring the log and handling exceptions.
FOR AN ESTIMATEWhat we need to know
What we need to know
before development.
The estimate depends on the configuration, exchange rules and data volume. Work inside 1C, licences and support are explicitly identified in the scope.
Your environment
Configuration name, platform version, customisations, hosting arrangement and the contact for your 1C specialist.
Your data
Objects, directions, a sample document, record counts and change frequency. Do not include credentials or passwords in your enquiry.
Your expected result
Which manual actions should disappear, how successful exchange will be verified and who will accept the result.
BEFORE WE START
Good questions.
Will the exchange be instant?
We agree a frequency for each object. Orders can be sent on an event; the full catalogue can run in scheduled batches. System availability, queues and interface limits affect delays.
Can you connect a customised configuration?
Yes, after reviewing the available mechanisms. We need to check existing customisations, permissions, published services and the involvement of the specialist maintaining 1C.
What happens with partial payments?
We retain the amount, document reference and actual payment status. The rule for starting delivery depends on the contract: a partial payment must not automatically count as full payment.
Does the website need direct access to the 1C database?
We design exchange through an agreed interface. The web system receives only the necessary operations and data, not arbitrary access to modify accounting database tables.
IN DETAIL / 10 TOPICS
What sits behind the interface.
Data models, exchange rules, permissions and operations. Open a topic or search by keyword.
Overview
The website does not connect directly to 1C database tables. Data is exchanged through an agreed interface: HTTP API, CommerceML, OData, web services or another mechanism suited to the configuration.
For each integration, we define which system owns each type of data. Prices and available stock may come from 1C, while a new order is created on the website and sent back to 1C.
1C → website
In the first scenario, 1C is the source of truth. This is typical for an online store or catalogue whose product records are maintained in 1C.
- A product, price, stock level or another object changes in 1C.
- The exchange module prepares the data for the website.
- A request is sent through the API or exported in CommerceML/XML format.
- The website validates the data and finds the object by its identifier or SKU.
- Changes are saved in the website database.
- The exchange log records success or the error details.
The first demo tab illustrates this route: values change in 1C, a data package is transferred, and the website price and stock become current.
Website → 1C
The reverse route is used for orders, enquiries, customers, payments and other data originating on the website or in CRM.
- A customer places an order on the website.
- The website validates the order contents, customer and required fields.
- A request to 1C includes a unique external order identifier.
- 1C searches for an existing customer record.
- A new customer record is created if necessary.
- An order document is created with its line items.
- 1C returns the document number and operation result.
- The website stores the relationship between its order and the 1C document.
The second demo tab shows a simulated receiving-side result, including a document reference and order details, rather than only a generic success message.
ERP scenario
ERP integration involves more business rules than a simple order transfer. Sending a product name and amount is not enough: the operation must fit the existing accounting workflow.
- Identify the legal entity.
- Select the warehouse or supply source.
- Create the customer order.
- Check product availability.
- Create a reservation.
- Check the payment status.
- Control dispatch.
- Return the current status to the website or CRM.
The demonstration models reservation and payment confirmation as separate steps. It illustrates how conditions control the route to dispatch.
What data can be exchanged
The scope can include the catalogue, prices, stock, reservations, customers, orders, payments, documents, shipments and statuses. The exact objects depend on the 1C configuration and your business processes.
For every object, we define its source of truth, identifiers, exchange direction, update frequency and validation rules. We also agree how cancellations, refunds, partial payments and conflicting updates are handled.
JSON, XML, CommerceML and OData
The format is selected for the existing infrastructure and task, not because one format is universally better.
JSON and HTTP API
Useful for custom integrations and event-driven exchange. We define the request and response structure, authentication rules and error handling.
XML and CommerceML
Commonly used between 1C and online stores to exchange catalogues, prices, stock and orders in a standard XML structure.
OData
Provides access to published 1C objects through a standard data interface.
Existing web services
SOAP and other supported services may be retained where they are already part of the corporate architecture.
How synchronisation is triggered
Exchange does not have to start with a button. A production project can combine several triggers:
- immediately after an event;
- on a schedule;
- through background queues;
- in synchronisation batches;
- manually through an administration interface.
An order may need to reach 1C immediately after checkout, while a full catalogue containing tens of thousands of products can be updated in batches.
Errors and retries
A reliable integration should not lose data when 1C is temporarily unavailable or a request fails.
A production system uses unique operation identifiers, an exchange log, processing statuses and retries. The same order must not accidentally create two documents in 1C.
For example, the website sends an order but the response is lost. On a retry, 1C checks the external order ID and returns the document already created instead of creating another one.
Security
The integration API must require authorised access. Depending on the project, controls include HTTPS, access tokens, dedicated service accounts, IP restrictions, request signatures and operation logs.
Only the operations needed for the integration are exposed. The website does not need unrestricted access to the entire 1C database.
What this demonstration shows
The interface illustrates three integration routes: receiving data from 1C, sending data to 1C and a multi-stage ERP process.
These scenarios run locally in the browser. They do not connect to 1C, create real orders or make payments. Connecting a real backend requires a separate implementation, a test environment and verification of requests and responses.
In a commercial project, the objects and business rules are determined by the actual 1C or ERP configuration and the customer's workflows.
Nothing found. Try another word.
Start with
what slows your work down.
Tell us about your task and existing systems.
We will define the first stage and scope of work.