1C:ERP for Manufacturing and Trading Companies

1C:ERP is modular, and trying to switch on every process area at once is the most common reason a project drags on. Each module brings its own master data, roles, and procedures, and all of them have to be aligned across different departments at the same time.

The typical sequence is this. First comes finance and warehouse: this is where the impact shows fastest, and stock and cost data are needed by all other modules. Then Purchasing and sales They rely on an already normalized item master. Manufacturing are connected only after specifications and bill of resources are in place: there is nothing to plan until reliable standards exist. Budgeting and Management Reporting come last, since they aggregate data from all previous process areas.

The practical conclusion is clear: the first measurable result comes not at the end of the project, but after the first process area goes live. If a contractor says the effect will only be visible after a year, that is a sign the phases have not been separated.

Moving to 1C:ERP is almost never a simple lift-and-shift of the old setup. The 1C:ERP data model differs from UPP: production specifications, cost accounting, and stage-based allocation are structured differently. So the project is not a migration, but a redesign of accounting with data transfer.

What transfers without loss: master data (after normalization), balances, settlements, open orders, and documents for the required period. What transfers with rebuilding: production specifications, cost allocation schemes, and reporting, which have to be redefined for the new model. What does not transfer: custom code from the old configuration, which is either recreated as an extension or moved outside if it is integration logic.

The most expensive mistake at this stage is bringing dirty master data into the new system. Duplicate counterparties and item masters will spread across every integration after go-live, and you will have to clean them up in production under load.

Warehouse accounting is built into 1C:ERP itself, and for many companies that is enough. A separate WMS is needed where the warehouse stops being a storage location and becomes an operation center: bin-based storage, picking tasks on handheld terminals, wave picking, and location-level control.

The boundary is defined by who manages the operation inside the warehouse. ERP is responsible for what to ship and to whom, while WMS is responsible for how to physically pick and assemble it. When both systems are in place, the exchange between them is critical: stock, tasks, and shipment statuses. If the exchange is done through direct database exports, discrepancies appear at the first load spike.

We connect 1C:ERP and the warehouse system through an integration layer with an exchange log, so discrepancies are visible as soon as they arise, not at inventory count. More on the warehouse area in the solution for warehouse automation and WMS.

How long does implementation take? It depends on the number of process areas, not the size of the company. The first area (finance and warehouse) takes months, not years; a full transition with production and budgeting takes much longer. We give a realistic estimate after process assessment, not based on user count.

Do processes need to change to fit the system? Partially, yes. 1C:ERP comes with its own accounting model, and trying to fully replicate old processes with customizations leads to a configuration that cannot be updated. We separate what is specific to the business and support that; what is merely habit, we bring back to the standard approach.

Will the configuration remain updatable? Yes, if custom changes are moved into extensions and integrations are placed on the bus rather than in the configuration code. That is the condition under which platform updates do not turn into a separate project.

Can you start without replacing the entire landscape? Yes. 1C:ERP connects to existing systems through defined APIs, so CRM, WMS, MES, e-commerce, and BI stay in place, while the data exchange method changes.