The accounting side is set up on Logo, the team is used to it, and the financial advisor works with the same routine. In contrast, the field team still walks around with paper, and orders are re-written at the office in the evening.
In this picture, changing the existing system creates a much bigger problem than what you are trying to solve. The real need is to speed up the field and mobile side while preserving the financial record order.
In this article, we explained how to set up an installation that works alongside Logo, data flow directions, mapping definitions, and installation steps.
Table of Contents
Working together model
EQLEM is a solution platform and is not designed to replace your existing ERP system. The goal is to complement the areas that system does not cover and connect the two structures.
In this model, Logo remains the center of financial records and accounting processes never change. Your financial advisor's working routine is not touched.
The platform, on the other hand, steps in in areas such as field sales, mobile usage, marketplace operations, and customer relations. These areas are outside the natural scope of classical accounting software.
The synchronization established between the two systems prevents the same information from being entered twice. Double data entry is the first and most concrete problem that integration solves.
The biggest advantage of this approach is that it brings new capabilities without taking the risk of changing systems at all.
Where is which record born?
The most critical decision in integration setup is which system each data type will be created in. Technical setup should not be done before this decision is clear.
Each data type must have a single owner, and the other system must only read that data. Records created in two places at once inevitably conflict.
In the common setup, current account and stock cards are born in the existing system; the accounting order requires this. The platform reads these cards and uses them in operation.
In contrast, field orders, visit records, and customer activities originate natively on the platform. These do not have a counterpart in the existing system anyway.
Putting these decisions in writing and sharing them with the team prevents future arguments from the start.
Current account card flow
Current account cards are almost always the first type of data shared during any setup. Customer information is required on both the accounting and the field sides.
In the general setup, cards are created in the existing system and transferred to the platform. This ensures tax information and accounting codes are managed in a single place.
A different setup is required when the field team needs to create a new customer record. These records can be opened as prospects and transferred to the existing system after approval.
Transferring current balances as well allows the field team to see customer risk. Shipments made without knowing the balance turn into collection problems.
We covered the card structure in the current account card article.
Stock card and balance flow
Stock cards are also generally defined in the existing system and transferred to the platform. Managing product codes from a single place ensures consistency.
Balance flow requires more attention because it is frequently changing data. Outdated balance information leads to promising the wrong orders in the field.
Therefore, stock synchronization is run more frequently than other data types. The frequency is determined based on transaction volume.
Transactions generated on the platform must also be reflected in the existing system. Otherwise, the stock on both sides will diverge.
Warehouse mapping is critical at this point; an incorrect warehouse definition causes stock to be written to the wrong location.
Document transfer
The true value of integration emerges in document transfer. Re-writing orders created in the field back at the office ends with this step.
Orders are created on the platform and transferred to the existing system. Invoicing and accounting processes continue there.
The timing of the transfer must also be determined; whether orders are sent upon approval or at the end of the day depends on the workflow.
The number of the transferred document must be trackable on both sides. This link forms the basis for subsequent checks.
Collection records can be transferred in a similar manner; field collections are instantly reflected in the office.
Mapping definitions
Since the data structures of the two systems do not overlap one-to-one, a detailed mapping definition is required. This definition is the silent backbone of the integration.
Matching card codes is the first step, and a common code structure should be used if possible. A common code makes mapping almost unnecessary.
Unit definitions must also be mapped; different units lead to amount discrepancies. Mixing up kilograms and grams produces thousand-fold errors.
Matching tax rates and currency definitions is also essential for the accuracy of amounts.
Warehouse, branch, and document type equivalents must also be defined; when these are skipped, records end up in the wrong place.
Connectivity and security
Logo typically runs on a server within the corporate network and is not directly accessible from the cloud. This is not a restriction, but a correct structure in terms of security.
Therefore, a connection component installed on the local network is used. The component does not accept incoming connections from the outside; it establishes the connection itself.
This model makes opening ports on the firewall unnecessary. The server can exchange data without being exposed to the outside world.
Access privileges should also be kept limited; the component must only access the tables it needs.
We detailed the architecture in the on-prem agent article.
Error management
No integration works without errors; what matters is that errors are visible and correctable.
The most common error stems from cards that lack a counterpart. A code missing on one side stops the transfer, and the record waits in the queue.
Connection disruptions come in second. In this case, records must not be lost and should be sent once the connection is restored.
Failed transfers should be gathered in a single list and checked daily. Errors that accumulate silently are noticed days later.
We explained the monitoring routine in the monitoring integration errors article.
Installation steps
Installation begins with detecting the version and configuration of the existing system. The scope may vary depending on the version.
In the second step, record ownership and flow directions are decided. This step is a managerial decision, not a technical one.
In the third step, the connection component is installed and access is tested. Preparation on the network side is completed at this stage.
In the fourth step, mapping definitions are made and a trial transfer is performed with a small number of records.
In the final step, the scope is expanded gradually; opening all data types at once makes it difficult to isolate problems.
Points to consider
Leaving record ownership undefined is the most common reason for integration project failures. Most technical issues stem from this ambiguity.
Keeping the scope unnecessarily broad also makes the maintenance burden unsustainable. Every additional data type means a permanent responsibility.
Version updates of the existing system must also be tracked; changes in the data structure can affect the integration.
Skipping the testing phase leads to data issues that are difficult to fix in production.
Scope and version compatibility must be verified separately for each setup; rather than a general commitment, your specific installation should be evaluated.
Frequently asked questions
Do we need to abandon our existing system?
No, it is not necessary; EQLEM works alongside your existing ERP system and does not touch your financial record order.
Which versions does it work with?
The scope varies depending on the version and configuration; we confirm support in advance together for your current setup.
Is external access opened to our server?
No, it is not; the connection is established from the inside out and no ports need to be opened on the firewall.
Is bidirectional synchronization possible?
It is possible; however, ownership must be defined on a field basis. Refer to the synchronization conflict article.
Accelerating field and mobile operations while maintaining the current accounting order is the lowest-risk path for most businesses. System replacement projects can often take away more than they gain.
Clarify record ownership from the start and put it in writing; almost all debates in integration projects stem from this ambiguity.
Also start by keeping the scope narrow; once current account and inventory flows are operational, adding document transfers becomes much easier.
Try to use a common code structure; this largely eliminates the need for mapping tables.
Make it a routine to check the error list daily; transfer errors that accumulate silently produce the most expensive surprises.
By consulting with the EQLEM team, you can clarify your integration scope.