Extending 1C without coding inside 1C: moving retail sales into a dedicated application

Summary: 1C can remain the accounting backbone while a role-specific bottleneck moves into a modern, dedicated module.

When a standard form stops serving the role

For a salesperson, the important sequence takes seconds: scan an item, see availability, add a customer, accept payment and issue a receipt. A standard ERP form is not always the best interface for that work.

This anonymised retail project created a local POS module for sales and returns. It works alongside 1C and deliberately does not try to recreate the whole ERP.

What the first working scope covers

The MVP supports the everyday checkout flow:

• product search by barcode, name, article, characteristic and warehouse;
• multi-line receipts, quantities, discounts and line totals;
• customer lookup and creation by phone;
• cash, card, debt, deposit and certificate payments;
• a check that payments equal the receipt total;
• daily transaction journal plus Excel and CSV exports.

Returns cannot be a later feature

The module supports returns from local receipts and historic 1C sales. A local return is a separate operation linked to its original receipt. For a historic return, the cashier finds the customer, retrieves the relevant sales period and selects the original sale.

Architecture: 1C remains the core

Angular 21 provides the sales interface; NestJS 10 contains sales and return rules; SQLite stores local checkout operations and a local projection of reference data. 1C HTTP services provide catalogue data, attributes, stock, prices and sales history. End-of-day control uses Excel `.xlsx`, while CSV `.csv` provides a predictable technical exchange format.

The key rule is that a temporary 1C outage must not stop the checkout. A transaction is stored locally, receives a synchronisation status and is transferred to the accounting layer in a controlled way.

Why modular replacement is the safer path

The interface can be designed for one role, changes can ship independently of the accounting core, and the integration contract stays explicit. The business modernises one measurable bottleneck instead of taking the risk of a full ERP migration.

For production rollout, the next steps are an exchange-error journal with retries, roles and multiple stores, 1C validation for deposits and certificates, Windows workstation packaging and an agreed end-of-day upload contract.

The practical first step is not replacing ERP: it is isolating the process that is currently slowing employees down.