How We Implemented a Unified Counterparty Management System for Muztorg

Context

"Muztorg" is a retail and distribution business with a heavy document flow. Counterparties exist in three 1C environments at once - sales, accounting, and logistics - and each environment has its own version of the truth: local IDs, its own data-entry rules, its own required fields. In practice, that means the same legal entity is duplicated across several similar records.

Legal entity names are written differently, addresses do not match, details become outdated, and any consolidated reporting turns into a fight with duplicates. Employees lose time on manual entry and corrections, accounting returns documents because of errors, and logistics runs into mismatches during data exchange. At the same time, the accounting core cannot be changed: the solution has to sit on top of the existing 1C systems, without a major overhaul or new complexity for users.

Another boundary is personal data: for the historical load, we intentionally include only legal entities. So the task is defined clearly and simply: one record per legal entity, one global identifier for all environments, a clear web form that prevents bad data from being entered, and automatic distribution of changes back to all 1C systems. If that works, retail processes orders faster, accounting stops chasing errors, and reporting is built from identical entities rather than similar ones.

Goals and business results

To stop living with three versions of the truth, we defined a short set of goals, all practical and measurable.

• First, one record per legal entity across all 1C environments: a master record with a global ID, with no duplicates or sync drift.
• Second, creation speed: from clicking "Create" in 1C to a live record in all systems takes about one minute thanks to the web form and auto-filled details.
• Third, data quality at entry: we validate tax IDs, names, and addresses so documents do not come back because of errors. We also simplify the approval route (separately for the dealer environment) so the process is not slowed down by unnecessary steps.

How it was measured

‍

Operational resilience was a separate focus: minimal support load and the ability to run the system independently after launch.

• Consistency - through monitoring discrepancies by global ID across systems;
• Speed - the time from launching the form to the record appearing in the systems;
• Quality - share of records returned for rework because of details;
• Process - length of the approval route and processing time;
• Migration - share of records that passed historical loading on the first run and after fixes.

Solution: one entry point, one identifier, one source of truth

We deployed a counterparty master system on Pimcore, which became the single source of the current legal entity record for all 1C environments - sales (1C:Trade Management), finance/budgeting (BIT.FINANCE), and accounting (1C:Accounting). On top of that is a simple web interface: creation is initiated from 1C, and a button opens a form where it is enough to enter the tax ID or name. The system pulls in details and addresses, checks correctness at entry, and does not allow inconsistent data to be saved.

Counterparty record: create and edit via web form

‍

After saving, the record with the global identifier is automatically distributed to all 1C databases. Any later changes are synchronized bi-directionally so that Sales (UT), Finance (BIT.FINANS), and Accounting (1C:Accounting) all keep the same record.

The user flow fits into a short sequence:

‍

At this stage, quality rules already kick in: key details and addresses are validated, and input errors that previously led to returned documents and discrepancies between sales, finance, and accounting environments are eliminated.

‍

"Accounts" tab: counterparty bank details

‍

Key elements of the solution:

• Initiate creation from 1C (single entry point for Trade Management / BIT.FINANCE / Accounting)
• Open form
• Enter tax ID or name
• Check auto-filled fields, including bank and address data critical for accounting and payments
• Save
• Pimcore as the MDM core, where the reference record and the counterparty's global ID are stored.
• Mappings from the global ID to local identifiers in UT, BIT.FINANS, and 1C:Accounting to prevent entity duplication.
• Web form launched from 1C. Short, clear interface for retail and back office.
• Inbound validation of company details and addresses via DaData. Invalid values are not saved, preventing errors in shipments (UT), payments and budgets (BIT.FINANS), and journal entries (Accounting).
• Automatic bi-directional synchronization of changes between the master and all 1C systems.
• Role-based model and simplified approval routes. The dealer domain uses a separate short flow.
• Historical load of legal entities from three 1C databases: data cleanup, duplicate consolidation, spelling normalization, global ID assignment, and back distribution of local identifier mappings.
• A procedure for rare exceptions, such as when information is not found in the directory: an administrator creates the record so work is not blocked.

Separate note on data logic

The master stores the reference record, and it defines the field set and format. Consistency is maintained through the global identifier and inbound rules: every new record is validated before entering 1C, and changes from 1C do not drift away from the master because synchronization is bi-directional and centralized. This removes the root cause of duplicates and mismatches across systems.

Importantly, the solution runs on top of the existing 1C systems, without redesigning the accounting stack. Users keep working in their familiar environment, but create and edit counterparties through a single entry point with quality checks at data entry.

For the business, this means fast record creation (about a minute), identical details across all databases, fewer returned documents, and no manual matching between systems.

For the support team, it means they can run the system on their own: rules are centralized, the interface is simple, and exceptions are covered by procedure.

Pimcore: editing the reference counterparty record

‍

What changed for the business

• One record across all 1C systems. Duplicates removed, changes distributed centrally. Consolidated reporting is built from identical entities.
• Creation speed. Before: about 1 hour (manual entry and verification of details, frequent rework). After: about 1 minute (1C -> form -> auto-fill -> save).
• Input quality. Errors in details and addresses are caught at entry. Returned documents have dropped significantly.
• Historical base. During the first load of counterparty records through master validations, about 10% were rejected (details, duplicates, mismatches). After we fine-tuned the merge and validation rules and corrected the source data, the client's rejection rate dropped to about 3-5%.
• Approvals. There used to be no single process: counterparties were created in different systems, often without approvals, which led to invalid and duplicate records entering the database. We built a single flow with mandatory role-based checks, removed unnecessary steps, and created a separate short route for dealer counterparties inside the dealer department.
• Support. About two months after launch, external support was no longer needed: there were almost no requests, and procedures plus validation covered standard cases. The team now runs the system in-house, responds faster, and saves budget.
• Operational resilience. New records and edits go through the same quality rules, so data-entry quality has not declined over time.

Challenges and how we solved them

• Too many participants and long approvals. At the start, the workflow was overloaded. We shortened the chain and kept only the control points that were truly necessary.
• A mixed legacy history across three 1C systems. Different formats, duplicates, and inconsistent spellings. We cleaned the data, defined merge rules, assigned global IDs, and distributed mappings to local identifiers.
• Incomplete information in external reference data. Not all counterparties/branches are found in DaData. For such cases, a procedure was introduced: a superuser creates the record so the flow is not blocked.
• Different input rules across systems. Errors were leaking into accounting. We moved validation into the master: inbound validation of TIN, names, and addresses prevents invalid values from being saved.
• There was a risk of disrupting 1C operations, so the solution had to sit on top of existing systems. We launched it in stages and kept enhanced monitoring for the first week, with no rollback and no downtime.

Timeline

• September-October 2023. Analysis, design, and alignment on the target data model and integration points.
• November 2023 - May 2024. Development of the Pimcore master, web form, bi-directional sync with 1C, and validation setup.
• June-August 2024. User testing, historical load of legal entities, fixes based on feedback, and refinement of merge rules.
• September-October 2024. Production launch, with enhanced monitoring during the first week. The exception procedure was enabled, and no rollback was needed.
• November-December 2024. Stabilization and transition to client-side self-support.
• 2025. In operation; no major enhancements are planned - the system runs according to procedure.

Technologies and architecture

At the center of the solution is Pimcore as the master system for counterparties. It stores the reference legal entity record and the global identifier, as well as mappings to local IDs from the three 1C environments (sales, accounting, logistics).

On top of the master data, a short React web form: launched from 1C with a button, TIN or name entry, auto-fill of company details and addresses, input validation via DaData, and saving only clean values.

Process management was reduced to a few clear rules. New records are created only through a validated form. Direct entry is discouraged so the old data quality issues do not return.

Different workflows are configured for different roles: a basic one for retail, separate ones for back office and logistics. The historical legal entity base was loaded from three 1C systems: the data set was cleaned, duplicates merged, spellings standardized, global IDs assigned, and local ID mappings sent back.

As a result, the architecture solves three key tasks at once: one entry point for creation and edits, one identifier for end-to-end consistency, and one source of truth that syncs with all 1C systems without manual mapping. That is what delivers the promised gains in speed, quality, and reporting.

Counterparty list with search and statuses

‍

The launch went live without rollback, and after stabilization the client has been running the system independently. Rare exceptions are handled according to procedure through a superuser. In effect, Muztorg now has one entry point, one identifier, and one source of truth - and that is what keeps quality and pace high without making life harder for users.

Client testimonial

"When we first discussed the project, it felt like we would have to rip apart all our 1C systems and rewrite the processes from scratch. In practice, the solution turned out to be easy to use: employees create a record directly from 1C, the system checks the details automatically, and syncs everything across environments. For us, that meant less stress in accounting, fewer returned documents, and faster order processing. Today we really feel that our data is under control, and we can manage without external support"

‍