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

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, what are the interfaces available ?

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, MySQL, NoSQL
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 : Ready-to-use or customized barcode & rfid mobile & web traceability apps
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 networks savings of OFFLINE mode of our 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 information system and a fourth solution .

• 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 fourth solution without interface: scan on a tablet with integrated scan :

  

  if no solution is provided in your information system to make semi-real time exchanges with other barcode systems, the only solution that remains is to put a screen with a scanner / imager included, all mobile with a free hand: a professional tablet (most commonly under Windows 10): without development required, we can deliver.

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 editor about what exists as standard as output interfaces, possibility to have direct reading rights to database at least 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 Data entry, mobile printing, stock management on hosted ERP DOLIBARR

We can answer your specific questions.