In any setup where two systems work together, the same question is asked sooner or later: on which side will we create this record? When the answer is not given from the start, the same customer is created in two places with different information.
Then the debate begins over which information is correct, and the integration loses credibility. Instead of trusting the system, the team reverts to confirming by phone.
In this article, we explained record ownership, mapping definitions, synchronization frequency, and validation methods in a setup working with Piconn.
Table of Contents
Working together model
EQLEM is a solution platform and does not aim to replace your existing ERP system. In the established structure, both systems work together and each remains in the area where it is strong.
The existing system continues to manage the financial and accounting side. Habits and historical data in this area are preserved as they are.
The platform, on the other hand, comes into play in field, mobile, customer relations, and operational processes. These areas are generally outside the scope of the existing system.
Synchronization between the two sides eliminates entering the same information twice. The gain comes from both time savings and reduced errors.
This model is preferred in most businesses because it adds new capabilities without taking the risk of changing systems.
Record ownership decision
Record ownership is the decision that determines which system will originate which data and is the foundation of the integration. Although it seems like a technical issue, it is actually a managerial choice.
A single owner must be designated for each data type. The second system only reads that data and does not make changes to it.
When this rule is relaxed, conflicts begin and it becomes unclear which information is valid. Uncertainty rapidly erodes trust in the system.
Ownership decisions must be made on a data-type basis; current accounts, stock, orders, and invoices are evaluated separately.
Keeping decisions in a written table prevents the loss of knowledge during team changes.
Synchronization scope
Not every data type needs to be transferred, and keeping the scope narrow is strongly recommended. Every additional data type brings a permanent maintenance burden.
Current account cards are shared in almost every setup; customer information is required on both sides.
Stock cards and balances are also commonly transferred. The field team's ability to take orders with accurate information depends on this.
Document transfer is the flow that provides the highest return; it is the step that truly puts an end to double data entry.
The scope should be expanded gradually; each step should be given time to settle.
Matching key selection
A key field must be selected to link the records in the two systems. This selection directly determines the reliability of the matching.
The healthiest method is to use a common code structure. Using the same code on both sides almost eliminates the need for a mapping table.
If a common code is not possible, a mapping table is kept, and equivalents are defined for each card. This table requires regular maintenance.
In current account cards, the tax number is a reliable key; however, it may not be filled in every record.
Matching based on name similarity must never be used; a mismatched record creates data problems that are very difficult to correct.
Field-based mapping
Once the records are matched, it must be defined which field corresponds to which field. This definition contains more details than it appears.
Unit definitions are the most error-prone field; different units can skew amounts by a factor of a thousand.
Tax rates and currency codes must also be mapped. An error in these mappings directly creates financial consequences.
When warehouse and branch equivalents are not defined, stock is written to the wrong location, and the discrepancy is hunted down later.
Mandatory fields must be filled on both sides; a missing field halts the transfer.
Synchronization frequency
Synchronization frequency should be differentiated according to the data type; having everything instantaneous is neither necessary nor efficient.
Stock balances are the data that needs to be updated most frequently. Outdated balances lead to making false promises in the field.
Current account cards, on the other hand, can be transferred less frequently; new customers are not added every minute.
Documents are generally sent when they are created or at specific intervals during the day.
As the frequency increases, the system load also increases; the balance is determined based on the volume during setup.
Conflict resolution
It must be predefined what happens if the same record is modified on both sides. Without this rule, data is silently corrupted.
The simplest solution is for the owner system to always win. Changes on the other side are invalidated and overwritten.
Field-based ownership can also be designed; the address is managed by one system, and the risk limit by the other.
It is important to log conflicts; frequent conflicts indicate that the ownership structure is wrong.
We discussed the details in the synchronization conflict and resolution article.
Validation and reconciliation
Instead of assuming the integration works, it needs to be verified regularly. Silent errors are the most expensive errors.
The most practical method is comparing record counts. The number of current accounts and stock cards on both sides must match.
Balance reconciliation should also be done periodically; small differences grow over time.
Checking document counts reveals untransferable records. This check can be done daily.
When a discrepancy is found, its source must be investigated and the root cause fixed; manual correction is not a permanent solution.
Installation steps
Setup begins with reviewing the existing system's configuration and data quality. Dirty data makes integration difficult from the start.
In the second step, ownership and flow direction decisions are made and documented in the table.
In the third step, the mapping key is determined and, if necessary, the code structure is corrected.
In the fourth step, tests are performed with a small number of records, and the results are compared on both sides.
In the final step, the scope is gradually expanded and a reconciliation routine is established.
Points to consider
Leaving the ownership decision ambiguous is the most common and costly mistake. Most technical problems stem from this ambiguity.
Mapping based on name similarity also carries serious risks and should not be used.
Failing to establish a reconciliation routine leads to the accumulation of silent errors.
Opening the scope completely at once makes it impossible to isolate the source of problems.
Scope and version compatibility must be verified separately for each setup; system sync structure is planned accordingly.
Frequently asked questions
Will our existing system remain in place?
Yes, it remains; EQLEM works alongside your existing ERP system and does not interfere with the financial record order.
Is a shared code structure mandatory?
It is not mandatory; however, it is strongly recommended as it significantly reduces mapping maintenance.
How often should reconciliation be performed?
Document counts should be checked daily and balances periodically; the frequency can be increased based on volume.
Does duplicate data entry end completely?
When the scope is set up correctly, it largely ends; see the duplicate data entry article.
In setups where two systems work together, what determines success is not technology, but decisions made from the beginning. When ownership is clear, the integration works silently.
Designate a single owner for each data type and record this in a written table; when the team changes, this table becomes the sole source of reference.
Try to establish a shared code structure; it largely eliminates the need for a mapping table and maintenance burden.
Consider the reconciliation routine as part of the setup; integrations that are assumed to work but are not verified produce the most expensive surprises.
Open the scope gradually; activating everything at the same time makes it unclear which workflow the problem is coming from.
By consulting with the EQLEM team, you can plan your sync architecture.