Connect 1C to Your Online Store: Orders and Stock

An online store loses trust when it accepts payment for stock that does not exist or shows yesterday’s price. To connect 1C to online store operations reliably, define ownership for products, quantities, prices and order status before writing an API call.

The integration is an operational contract between systems, with retries and exceptions—not a one-time export.

---

Decide what 1C owns

In many Uzbek businesses, 1C owns product codes, accounting stock and confirmed sales. The store owns catalogue presentation, carts and customer sessions. Agree how promotions, branch availability, returns and reservations cross the boundary.

Data	Typical owner	Direction
SKU/product code	1C	To store
Rich content/images	Store/PIM	Internal
Price/tax	1C or pricing service	To store
Available stock	Inventory service/1C	To store
New order	Store	To 1C
Accounting status	1C	To store/CRM

Use stable IDs and reservations

Names are not identifiers. Map SKUs, variants, warehouses, customers and orders with stable keys. When checkout begins, define whether stock is reserved, for how long and what releases it. Payment confirmation should be idempotent.

Integration checklist:

• 1C version and integration capability are confirmed.
• Product and warehouse mappings are clean.
• Stock availability formula is documented.
• Order and payment IDs are stable.
• Retries do not duplicate documents.
• Refund and cancellation paths are tested.
• Sync age is visible to staff.
• Exceptions have owners.

Pick sync frequency by risk

Catalogue text may update nightly; popular-item stock may need near-real-time events. Use webhooks or incremental polling where supported. Full catalogue exports on every change create unnecessary load.

Payme, Click and Uzum status should enter through trusted callbacks and connect to the same order model. See accepting online payments in Uzbekistan for provider architecture.

Related integration patterns include Telegram with amoCRM, website with Bitrix24, Google Sheets and CRM sync, and the Telegram bot business guide.

Frequently Asked Questions

Plan the integration contract

Definition of done

Ask warehouse and accounting staff to sign off. Engineering can prove delivery, but operational users confirm that reservations, documents, corrections and reports match how goods and money are handled. Record any accepted manual exception explicitly.

Agree acceptance thresholds before release: no duplicate 1C orders in retry tests, correct stock for sampled SKUs, visible sync freshness, complete refund/cancellation paths and an owned exception queue. Include a paid-order scenario during 1C downtime and prove later reconciliation.

Documentation should list field ownership, mappings, schedules, credentials, alerts and manual recovery. A new qualified engineer and accountant should be able to trace one order without asking the original developer. That handover test is a practical measure of maintainability.

Migration and support responsibilities

Before switching live traffic, take a catalogue snapshot and reconcile product, price and warehouse counts. Freeze structural changes during the cutover window or record them for replay. Start with a small category, compare every created 1C order, then increase volume only after duplicate and stock tests remain clean.

Name the people allowed to edit product mappings. A missing mapping should stop that SKU from sale or enter a visible review queue; it should never fall back to a similarly named product. Keep a history when codes merge or change so returns against older orders remain traceable.

Operational support needs a plain dashboard: last successful catalogue and stock sync, queued orders, oldest failure and provider status. Warehouse staff should know whom to contact and which manual actions are safe. If emergency processing is used during downtime, those orders need a controlled import and duplicate check afterward.

Review capacity before promotions. Full exports, payment callbacks and order creation can compete for resources in a customised 1C installation. Load-test against a representative copy, schedule heavy catalogue work outside peak checkout, and agree maintenance windows with accounting.

Write field-level rules before development. Define whether “available stock” means physical quantity, quantity minus paid reservations, or quantity minus all active carts. Specify rounding, units, VAT, branch time zone and when promotional prices start and end.

Use an integration ledger that records source event, entity ID, version, attempt and result. If 1C accepts an order but the response is lost, a retry must query or reuse the same external ID rather than create another document. The same rule applies when a callback is delivered more than once.

Test data should include:

• products with variants and Cyrillic names;
• discontinued and temporarily unavailable SKUs;
• orders split across warehouses;
• price change during checkout;
• partial cancellation and return;
• Payme/Click confirmation arriving late;
• 1C maintenance or network outage;
• manual correction by an accountant.

Staff need a reconciliation screen showing unsynchronised orders and stale stock, with safe retry and escalation. Do not ask warehouse employees to inspect server logs. During rollout, compare website stock with a physical and 1C sample each day.

For regional branches, decide whether each warehouse fulfils directly or central routing chooses a source. Delivery promises must use the chosen warehouse after reservation. Measure oversells, sync delay, duplicate documents and manual corrections before expanding the catalogue.

Can every 1C setup use the same connector?
No. Editions, customisations and hosting differ. Inspect the actual configuration first.

Should the website query 1C on every page view?
Usually not. A resilient integration uses a synchronised catalogue or inventory service and exposes sync freshness.

How do refunds work?
Define provider refund, internal order state and 1C document changes as one tested workflow.

Can we launch category by category?
Yes. A limited catalogue pilot reduces mapping risk.

Fera Tech builds ecommerce backends and local integrations through our services. Contact us with the 1C edition, store platform and stock rules for a technical assessment.