Interfaces between your information system and mobile PDAs?

Strategies for upgrading systems by integrating mobile applications:

Do you have a production management information system (ERP / PGI), or a logistics management system (WMS), and would you like to make intelligent mobile barcode / Rfid entries of your incoming orders, shipments and outgoing stock, traceability and quickly see the result in this management information system? Exchanging scanned data with your ERP/PGI ?

You’ve checked with your editor that he has nothing to offer on his own, and you’re planning to add this function with our software and terminals (PDAs): here are the requests to make and questions to ask your editor first, before calling us, because the fundamental question at this stage is NOT: “how do we do it? BUT “how do we exchange data?” and “what level of automation do I want to achieve?”

Definition of mobile application integration:

The integration of mobile applications enables applications and systems that have been created separately to work together, resulting in efficiency gains that reduce costs, provide information, and much more besides, such as the “offline” mode of our mobile-specific apps (and even more so for us in Android: see the articles on this site about mobile offline), which avoids unnecessary investment to cover an entire area or volume (e.g. warehouses or workshops with lots of metal) with networks (Wifi).

Stakes presentation:

We aim to significantly reduce the cost of integrating our mobile traceability applications into an ERP project by standardizing them. In this way, you’ll be able to optimize our services in no time and at little cost. But beyond expenses, there’s the question to answer first: is it possible to integrate with my ERP, and what are the possible interfaces?

Many of the factors involved in integrating mobile traceability solutions depend on your vendor and your choices. Here, then, are the elements that will enable you to make your requests to your editor and make your choices for the future: exchange principles, requests and strategies.

Principles and types of mobile application exchanges with ERPs, requests to be made to your editor according to

ERPs are :

either a “3-tier” architecture: (e.g. Microsoft AX) the presentation layer, also known as the “client”, installed on your PC. The standard client exists, as does the “thin” browser client, which offers slightly fewer functions.
either in Web architecture: (many are Opensource, like Dolibarr) application logic is written in PHP or Python: provision of screens accessible by the “client” browser.

What is a mobile terminal with integrated scanner?

See advantages of ruggedized terminals with scanner

On these terminals, we use their own processor and embedded database system, NOT their browser.

Impacts on exchanges between mobile terminals and ERP.

This advice or request is easier to make or obtain before purchasing an ERP system, than afterwards: think about it when choosing your ERP system.

Our mobile links with ERPs depend on their architecture:.

in Web architecture: you’re online, and you can access the screens provided, if they’re “responsive”, directly via the terminal’s browser (and you don’t need us). But in general, their ergonomics and screens are not designed to quickly accept a burst of data with a scanner, so we’re back to the next case.
in “3-tier” architecture: we use the Offline mode: see OFFLINE 1st on mobile apps :we read or integrate a part of the ERP database concerned by the targeted process, work on it with the local mobile database and reverse the modified data at the end of the process.

There are 3 ways of exchanging mobile data with centralized management systems / ERP and a fourth integration solution

the old, manual “import-export” method, with files generally in “csv” format (readable by Excel):The mobile terminal will automatically read the files made available by the ERP operator, and automatically write the files to be integrated by the ERP system, either manually or automatically (by request). The processes covered are therefore listed by the ERP, and all that’s required is to send us by e-mail the model and tested import and export csv files. This mode is the customer’s responsibility; we always have a csv import/export mode on our app, but this mode is tedious to operate.
direct database exchange mode: rights are granted by the editor per table, per database, per mode: read or write. The OLE DB or ODBC connection mode, depending on the database engine, is then installed for exchanges. It is no longer used for technical reasons (old mode), security and liability reasons. This mode is the customer’s responsibility. We always have a csv export and import mode on our app, but this mode is tedious to operate.
When it comes to reading ERP data into terminals, this doesn’t pose many problems of rights and responsibilities, provided you ask the publisher for authorization to read the database and its “data dictionary”. On the other hand, neither we nor the publisher take responsibility for writing or modifying data directly in the database, otherwise we lose all the consistency checks we’ve ensured. We must therefore ask (the editor), if this is not already the case, to create a so-called “pivot” table which allows the terminal to dump its data into it, and the ERP to integrate it cleanly into its database via the editor’s own process (development generally done by the editor), which empties this table. A sort of batch mode, too, which is not necessarily perceived by the user as its frequency can be high.
direct exchange via API: write and read exchanges are fully controlled in terms of possibilities and rights by interface programs (“APIs”) made available by the publisher: here again, documentation should be requested from the publisher. Here too, documentation should be requested from the publisher.
At this level, complete, clean and simple automation is available: through our favorite no-code interface with your databases
The ERP, through its APIs, takes care of database consistency.
the fourth solution without interface: (here, as we don’t sell hardware without software, this is just a tip for you) if your information system doesn’t provide a solution for semi-real-time exchanges with other barcode systems, the only solution left is to use a mobile screen with “hands-free” scanning:_

either a professional tablet with an imager included underneath (usually under Windows, check and test beforehand, and in the case of web architecture, you can use Android and scan under Chrome).
or a tablet without an imager and add a finger-scan ring, see barcode mobile device types

The high performance of the functionalities we’ll be installing with the API will be an advantage, thanks to links that don’t need to be synchronized in real time: the off-line mode is very useful in areas with no network, or conversely, places that are heavily used on-line in near-real time, such as picking lines.

At the same time, we need to ask ourselves the following question: Can and should the new data captured by the mobile process be integrated into the ERP system?

Example : if the ERP doesn’t have fields or tables to store them, it’s not necessary. You can put them in a database which will only be read in the event of a product recall, i.e. as rarely as possible.

There are four possibilities for mobile data feedback:

this data is already provided for in the ERP: so don’t worry, just ask for the API instructions.
this data is not provided for in the ERP: you therefore have a choice between :

have the editor integrate this function,
change ERP,
have us add a separate database: the analysis link between tables and databases will then have to be set up.

ERP changeover strategies by case

You have recently acquired an ERP / information system. the investment was high, or change is impossible: ask your publisher about the standard output interfaces and direct-read access to the database, and depending on 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 akin to a “business” sales management system. calculations are made in this ERP and supplier catalogs are included (e.g. in the automotive industry, blinds, etc.): there’s no question of changing it. So you keep the tool, you print your customer orders and the rest (like stock management, production) can be done on a mobile terminal by OCR (option) reading of the purchase order or BL references: we’ve created this app and its online database: Developed mobile stock management solution

We can answer your specific questions.