SOLUTIONS
Need more than 1C does, without replacing it? 1C integration: your own tools next to your accounting
I connect 1C, the accounting and ERP system common in CIS countries, to websites, spreadsheets, documents and custom tools. 1C stays in place.
Suited toImproving current toolsNew internal system
The topic will already be filled in.
What this looks like in practice
Software that counts parts and materials from Excel BOMs, checks them against 1C, consolidates orders and prepares work for shops and contractors.
ArticleThe server: data, access and workflow coordinationWhy a system needs a shared core that preserves state, checks permissions and coordinates data processing.
DemoCalculator: manual data workEstimate what routine document work costs and what automating part of it could free up.
When 1C keeps the books but not everything else
1C is the accounting and ERP platform many companies in Russia and other CIS countries run on. Your item catalog, stock, documents and bookkeeping live there. You're not planning to replace it: the setup works and your staff know it. But tasks pile up around it that are awkward to handle inside 1C. Someone retypes website orders by hand. Someone checks stock against an Excel export. Engineers calculate materials in spreadsheets and then search the 1C catalog to see if those items exist.
For tasks like these I build a separate tool or integration that runs next to 1C and pulls data from it. 1C stays your accounting system. The logic it doesn't have runs on its own server.
How this worked at a manufacturer
In 2024 I built a program for a manufacturer of complex products. Each product was described across many Excel specifications, and staff used to total parts and materials by hand. The program breaks a product down into parts, calculates materials for the ordered quantity, checks them against the 1C item catalog and flags items that are missing from 1C. The output goes to the company's internal accounting, warehouse and planning systems and to subcontractors. Accounting stayed in 1C, and the calculation and checks run in a separate program. The parts and materials case study has the details.
What I clarify before development
First I look at your 1C configuration and who maintains it. That decides how data moves: scheduled file exports, HTTP services or the standard OData interface. If the exchange needs changes inside the configuration itself, the 1C developer who already looks after your database usually makes them. I agree the format with them and build my side.
Then we decide which system owns what. Stock and prices most likely stay authoritative in 1C. The status of a website order or a calculation for the workshop can belong to the new tool. If we skip this step, the two systems end up disagreeing about which number is right.
I also need anonymized examples: a few ordinary documents and a couple of awkward cases, such as an item that appears in an order but not in the catalog.
A possible first stage
One data flow, end to end. Say, website orders reach 1C with no manual entry. Or the program checks materials from your specifications against the catalog and shows mismatches as a list. Telephony or a CRM can come next, once the first flow works. We agree the scope and cost of the first stage before development starts.
How we accept the result
We run the agreed examples: an ordinary document, a repeated submission, an item missing from 1C, the database being down for a while. We check what landed in 1C or in the new tool, what got flagged as an error and what the employee sees. Along with the integration you get a description of the fields and the steps to take if the exchange stops.
Related pages
API integrations, spreadsheet automation if your data still lives in Excel, and an article on why a system needs its own server. If you run 1C and have a task it doesn't cover, tell me about it.