How do you plan the interfaces between ERP and mobile data entry terminals? Development strategies

All the versions of this article: [English] [français]

You have an ERP (ERP), a WMS and you want to make mobile intelligent entries by barcode / Rfid of your incoming orders, dispatches and outgoing stock, traceability and quickly see the result in this ERP or WMS?

You have checked with your publisher that he has nothing to offer you by himself and you intend to add this function with our software and terminals: here then are the requests to be made and questions to ask your publisher first before calling us because the fundamental question at this stage is NOT: "how should it be done? "BUT" how do we exchange data? "and "how far do I want to go with automation? »

Presentation of the issues:

Our aim was to significantly reduce the cost of integrating our mobile traceability applications into an ERP project by standardising them. You are thus able to optimise our services in a short period of time and at low cost. But beyond the expenses, there is the question to be answered beforehand: is it possible to integrate with my ERP?

Many factors for integrating mobile traceability solutions depend on your publisher and your choices. So here are the elements that enable you to make your requests to your publisher and make your choices for the future: exchange principles, requests and strategies.

Principles and types of exchanges of mobile applications with ERPs, requests to be made to your publisher in function

ERPs are in "3-tier" architecture (example of AX from Microsoft):

  1. the database: SQL Server,
  2. application logic, in Microsoft standard techno + a proprietary development language called X++,
  3. the presentation layer, also known as the "client", installed on your PC. The standard client exists, the "thin" browser client also exists, it allows a little less functions.

Or in web architecture : (a lot in Opensource, like Dolibarr)

  1. the database
  2. application logic in PHP or Python: provision of screens accessible by the "client" browser

What is a mobile terminal with integrated scanner?
See paragraphs of : Std & customized mobile production or delivery traceability apps "KX-mobile"
We use on these terminals their own processor, their embedded base system and NOT their browser.

Impacts on the exchanges of mobile terminals with the ERP
These tips or requests are easier to make or obtain before buying an ERP, than after: think about them when choosing an ERP.

Our mobile link with ERPs depends on their architecture :

  • in Web architecture: we are online and can access the screens provided, if they are "responsive", directly via the terminal’s browser (and you don’t need us). But in general, their ergonomics are not designed to go quickly in bursts with a scanner, so we are brought back to the next case.
  • in "3-tier" architecture: we use the Offline mode: see The advantages and savings of OFFLINE mode in mobile applications: we read or integrate a part of the ERP base concerned by the process in question, we work on it with the local mobile base and we transfer the data at the end of the process.

There are 3 modes of data exchange with the ERPs There are 3 modes of data exchange with the ERPs.

  • Old and manual mode by "import - export" of files in general in "csv" format (readable by Excel): the mobile terminal will therefore automatically read the files made available by the ERP operator and automatically write the files to be integrated by the ERP on manual or sometimes automated execution (request to be made). The processes covered are therefore listed by the ERP and all you need to do is send us sample and tested import and export csv files by process.
  • direct database exchange mode: rights are granted by the editor by table, by base, by mode: read or write. The OLE DB or ODBC connection mode, depending on the base engine, is then installed for exchanges.
    To read ERP data to terminals, this does not pose many problems of rights and responsibilities, provided that ask the editor for authorization to read the database and its "data dictionary".
    On the other hand, neither the publisher nor we take responsibility for writing or directly modifying the data in the database, otherwise we lose all the consistency checks that are assured. It is therefore necessary to ask (the editor), if this is not provided for, and by process, to create a table which is called a "pivot" which allows the terminal to pour its data into it and the ERP to integrate it properly into its base by the process of the editor (development in general in addition, done by the editor) which empties this table. A sort of batch mode as well, which is not necessarily perceived by the user because its frequency can be high.
  • the direct exchange mode by API: the write and read exchanges are fully controlled in terms of possibilities and rights by interface programs ("API") made available by the editor: here again the documentation is to be requested from the editor.
    At this level we have a complete, clean and simple automation. For example, the ’ERP Open Source Dolibarr since its version 10, has an important number of APIs (inventory, goods receipt, maintenance on site and exchange of parts on machines, picking, goods issue, updating of type of storage locations, entry of time spent, etc...). ) . In our case, we import into the mobile phone’s database a table of articles with their descriptions, values, photos produced by our own orders and we write back the scanned values as an inventory. The ERP, through its APIs, takes care of the consistency of its database.

The high performance of the functionalities that we will install will be an advantage, thanks to links that do not need to be synchronised in real time: off-line mode is very useful in areas without a network, or conversely, places that are heavily used in near real-time on-line mode such as picking lines.

In parallel with these modes, the question must be asked knowing if these (new?) data to be entered from the process can be integrated into the ERP.

Example: Enter the optimal use-by date (EOLD) or date, serial number, etc., if the ERP does not have fields or tables to store them.

There are four cases:

  • these data are provided for in the ERP: so no worries,
  • these data are not provided for in the ERP: you therefore have the choice between :
    • have this function integrated by the editor,
    • change ERP,
    • have us add a separate database: the linkage of the analyses between the tables and databases will then be planned.

Strategies for ERP changes depending on the case

  • You have recently acquired an ERP , the investment has been heavy or change is impossible: ask your publisher about what exists as standard and according to the answers and your desired level of automation, negotiate additions: see the points and questions above, then come back to us.
  • You have a tool that is more than a "business" commercial management tool: calculations are made and supplier catalogues are included (for example in the automotive sector, blinds, etc.): no question of changing it. So you keep it, you print your customer orders and the rest (like stock management, production) can be done in mobile terminal linked to Dolibarr by OCR reading of the purchase order references: you test by direct download on your PC, we realize the hosting and backup on a server, the parameter setting and the adapted mobile scanning applications if they are not standard.
  • You can change ERP then you come back to the above case with the commercial management included in Dolibarr.

We can answer your specific questions.