In a business that has been using Mikro for years, the accounting order is established, the financial advisor is accustomed to it, and the historical data is right there. Changing this structure creates a much bigger problem than the one you want to solve.
In contrast, needs such as field sales, marketplace operations, or mobile usage may fall outside the scope of the existing system. At this point, the right question is not to change the system, but what to add alongside it.
In this article, we explained how to set up an installation that works together with Mikro, data flow, record ownership, and boundaries.
Table of Contents
Core approach
EQLEM is a solution platform and does not aim to replace your existing ERP system. The goal is to work alongside that system and complement the areas it does not cover.
In this approach, Mikro remains the center of financial records. The accounting order, financial advisor habits, and historical data are preserved as they are.
EQLEM, on the other hand, comes into play in field, mobile, marketplace, and operational processes. These areas generally remain outside traditional accounting systems.
A synchronization is established between the two systems, and data duplication is eliminated. The same information does not need to be entered twice.
This model adds capabilities without taking the risk of changing the system.
Record ownership
The success of integration projects depends on a clear answer to a single question: in which system does each data type originate?
When this question is not answered, the same record is created in two places and conflicts begin. Which piece of information is correct becomes a matter of debate.
The general rule is to designate a single owner for each data type. The other system only reads that data.
It is a common setup for current accounts to originate in the existing system and field activities in the platform.
Ownership decisions must be put in writing and shared with the entire team.
Which data flows?
The synchronization scope is determined by needs, and not every data type needs to be transferred.
Current accounts are shared in almost every setup; customer information is required on both sides.
Stock cards and balances are also commonly transferred. The field team seeing the current stock depends on this.
Sales documents are usually created in the platform and transferred to the existing system. This is the main flow that ends duplicate data entry.
Keeping the scope narrow is recommended; every additional data type means extra maintenance overhead.
Flow direction
The flow direction is determined separately for each data type, which stems directly from record ownership.
Unidirectional flow is much more reliable than bidirectional. The possibility of conflicts is eliminated.
When bidirectional flow is required, field-level separation can be applied. Some fields are updated from one system, and others from the other.
In case of a conflict, which side wins must also be defined from the beginning.
We discussed conflict management in the sync conflict article.
Connection architecture
Micro generally runs on a server in the company network and cannot be accessed directly from the cloud.
Therefore, a connection component installed on the local network is used. This component does not accept incoming connections from the outside.
The connection is established from the inside out; this model makes opening ports on the firewall unnecessary.
Thus, the server can exchange data with the cloud platform without being exposed to the outside world.
We detailed the architecture in the on-prem agent article.
Mapping definitions
Since the domain structures of the two systems are not identical, a mapping definition is required.
Code matching is the most critical step; it must be clear which card corresponds to which card.
Using a common code structure greatly simplifies this mapping.
Definitions such as unit, currency, and tax rate must also be mapped. Errors in these mappings result in discrepancies in amounts.
The equivalents of warehouse and branch definitions must also be determined; otherwise, inventory will be recorded in the wrong location.
Synchronization frequency
Synchronization frequency should be differentiated according to the data type; everything does not need to be real-time.
Stock balances should be updated frequently; outdated stock data leads to wrong sales decisions.
Current accounts, on the other hand, can be transferred less frequently; new customers are not added every minute.
Document transfer is usually done a few times during the day or at the end of the day.
As the frequency increases, the system load also increases; the balance is determined during setup.
Error management
Errors are inevitable in integrations; what matters is that errors are visible and correctable.
The most common error stems from unmapped cards. A code that does not exist on one side halts the transfer.
Second are connection interruptions; in this case, records must wait in the queue and be sent later.
Failed transfers should be collected in a list and checked daily.
We explained the monitoring method in the monitoring integration errors article.
Setup steps
The setup begins with the detection of the current system version and configuration. The scope may vary depending on the version.
In the second step, decisions regarding record ownership and flow direction are made and documented.
In the third step, the connection component is installed and access is verified.
In the fourth step, mapping definitions are made and tested with a small number of records.
In the final step, the scope is gradually expanded; opening all data at once makes it difficult to isolate issues.
Points to consider
Leaving record ownership ambiguous is the most common reason for integration project failures.
Keeping the scope broader than necessary also makes the maintenance burden unsustainable.
Version updates of the existing system must also be monitored; structural changes can affect the integration.
Skipping the testing phase creates data issues that are difficult to fix in the live environment.
Scope and version compatibility must be verified separately for each setup.
Frequently asked questions
Do we need to change our existing system?
No, you don't; EQLEM works alongside your existing ERP system and does not touch your financial record order.
Which versions are supported?
The scope varies by version; we jointly confirm support for your existing setup prior to installation.
Is external access to our server required?
No, it is not; the connection is established from the inside out and no ports need to be opened on the firewall.
Are historical data transferred?
Usually, the current period is started with; the need for historical data is evaluated separately during the installation phase.
Gaining operational capability without changing your existing ERP system is the lowest-risk path for most businesses. While the accounting order stays in place, the field and mobile sides speed up.
Clarify record ownership from the start and put it in writing; most integration projects get stuck in this ambiguity.
Also start by keeping the scope narrow; every additional data type brings a permanent maintenance burden.
Prefer one-way flow; two-way synchronization carries the risk of conflict unless required.
Check the error list daily as well; transfer errors that accumulate silently are noticed days later.
By consulting with the EQLEM team,you can clarify your integration scope.