When two systems open the same current account with different codes, invoices do not match, and the team spends days drowning in cleanup. The most expensive mistake in a sync project is installing an adapter without discussing record ownership.
A good plan dictates from the start where each piece of data originates, which direction it will flow, and how often it will be validated. In this article, we explained the planning steps in order.
EQLEM is a solution platform; it works alongside your existing ERP systems such as Mikro, Logo, or Piconn, and does not replace them.
Table of Contents
The purpose of sync
The goal is to end dual data entry and leave consistent records on both sides. Copying every single field is not the objective.
Keeping the scope narrow accelerates success; starting with current accounts, stock, and documents is sufficient for most setups. A broad scope inflates the maintenance burden.
Business value must be clearly stated; for example, field orders not being re-entered into accounting. Without value, the project drifts.
We explained the path to ending dual entry in the dual data entry article.
EQLEM does not replace the existing ERP; it carries out complementary operations.
Record ownership matrix
A single owner is designated for each data type; the other side only reads or receives approved transfers. Two owners mean conflict.
Current and stock cards usually originate in the existing ERP system. The platform uses these cards in operations.
Field orders, visits, and service records originate in the platform and have no equivalent in accounting. This distinction must be clearly written.
It is shared with the team as a matrix table and signed. Oral agreements are forgotten in the middle of the project.
Field-level ownership may also be required; addresses are updated in the platform, and tax IDs in the existing system. This subtle distinction cuts off conflict from the start.
Flow direction selection
One-way flow is easy to manage; two-way flow should only be enabled in mandatory fields. Fields open in both directions generate conflict.
Cards can flow from ERP to the platform, and documents from the platform to ERP. This is the classic and secure model.
For frequently changing data such as balances, the reading frequency is increased. Outdated balances generate wrong promises in the field.
We covered the Logo setup in the Logo integration article, and Mikro in the Mikro integration article.
Direction decisions must be made with business owners before the technical team. Technical preference should not precede business rules.
Mapping definitions
Code, unit, warehouse, tax, and document type equivalents are gathered in a single table. Missing rows produce silent errors in production.
A common code structure is preferred whenever possible; it reduces the need for mapping. Different codes require constant maintenance.
Unit multipliers are especially dangerous; the confusion between grams and kilograms creates a thousand-fold error. It must be verified during testing.
It is also decided whether passive cards will be transferred or not. Dead data generates noise.
Versions must be kept when mappings change; it must be known who changed what and when. Mapping without versioning produces surprises in production.
Frequency and priority
Layered frequencies can be defined, such as cards at night, balances hourly, and documents instantly. A single frequency does not fit all data.
The priority queue sends critical documents first; orders are not delayed during heavy traffic. FIFO is not always correct.
Window hours protect the existing ERP load; heavy synchronization in the middle of the workday decreases performance. Cooperation is essential.
Marketplace stock synchronization requires a different pace; marketplace stock sync see the article.
Frequency changes must be monitored; a load increased silently strains the server.
Connection model
Instead of opening an external port to the on-prem ERP, an inbound connection is preferred. The security model is established accordingly.
The connection component should only access necessary tables; broad permissions increase risk. The principle of least privilege applies.
File-based transfer is sufficient in some scenarios; simplify if real-time is not required. File integration see the article.
We explained the on-prem agent architecture in the on-prem agent article.
Going live should not happen without monitoring connection health.
Testing and validation
End-to-end tests are performed with a small number of sample records; amounts, units, and warehouses are checked. This is mandatory before bulk loading.
Negative tests are also required; non-existent codes, broken connections, and duplicate documents are tested. The happy path alone is not enough.
The business user must also sign off on the test; technical success does not mean business success. The language in the field is different.
The verification checklist is recorded and repeated after going live. It catches surprises in the first week.
The test environment should be a copy of production data; an empty environment does not show real errors. Synthetic data misses many edge cases.
Error and conflict plan
Failed transfers should remain in the queue and be monitored daily. A silent error is the most expensive error.
Conflict rules are written upfront; last write wins or a manual queue is chosen. Sync conflict see the article.
Error monitoring to monitor integration errors in the article.
Without a designated owner, the queue piles up; ownership is required here as well.
The retry policy must be exponential; tight loops can lock up the opposing system.
Going live
Scope opens gradually; cards first, then documents. If everything opens at once, the root cause cannot be found.
A war room is established in the early days; business and technical teams stay in the same channel. Tickets alone are not enough.
A rollback plan must be written; if the issue escalates, synchronization is stopped and manual processing continues. Unplanned panic causes greater damage.
Piconn scenarios Piconn integration we discussed in the article.
Post-launch metrics for the first week are compared against the plan and adjustments are made.
Points to consider
Do not set out with ambiguity in ownership; technical setup does not solve this. RACI matrix first, then the adapter.
Do not open every field bidirectionally; maintenance and conflict costs rise rapidly. A narrow scope wins.
Do not position EQLEM as an ERP; the existing system remains at the financial center. The platform completes the operation.
Do not skip testing and rush to production; data correction is more expensive than integration setup.
Track version updates; when the ERP data structure changes, mapping can break.
Frequently asked questions
Which data should be synchronized first?
Generally current accounts and stock cards, followed by documents. Start with the narrowest set that delivers value.
Is two-way synchronization always necessary?
It is not necessary; in most setups, cards one-way and documents the reverse direction are sufficient. Two-way is the exception.
Does EQLEM replace the existing ERP?
No, it does not; it works alongside it as a solution platform and connects via synchronization.
How long does the plan take?
If ownership and mapping are clear, setup accelerates; ambiguity wastes weeks. Decision first, then technical work.
Sync success comes from the ownership matrix before the adapter. Do not proceed without answering the question of where each record originates.
Keep the scope narrow, keep the mapping in writing, and adjust the frequency according to the data type. A single pace breaks all data.
Have the business user sign off on the test; a technical green light is not enough. Go live gradually.
Assign an owner to the error queue; records accumulating silently are the most expensive surprise.
Write the conflict rule in advance; have a roadmap ready before both sides modify the same field.
By consulting with the EQLEM team you can clarify your sync plan with record ownership.