# How to add a mobile app to Baan IV / Baan V > Source: https://netray.co/integrations/baan-mobile-app > Publisher: Netray (netray.co), AI and integration engineering for ERP and manufacturing systems. > Section: Integrations ## Short answer Put a thin middleware API between the phone or scanner and Baan. The app talks to the middleware; the middleware reads Baan through the database for lookups and writes through AFS or data exchange for transactions. This avoids installing Baan clients on handhelds and gives you offline queues and audit. ## System Baan IV / Baan V ## Capability mobile-app ## Intro Baan shop floors typically use terminal emulators, paper travellers and a clerk who keys in what operators write down. Warehouses count and move stock with printed pick lists. The data arrives late, which is why inventory and production reporting in Baan are only as fresh as the last keying session. Handhelds and phones change that: scan the location, scan the item, key a quantity, and the transaction is posted without a middleman. The difficulty with Baan is that it has no mobile API. The old Windows client or terminal session is unusable on a handheld, so a middleware layer is mandatory. The design question is not which phone but where validation lives. Baan rules must still apply, so the middleware should post through supported entry paths and return Baan's errors to the operator immediately. ## Use Cases ### Goods receipt against purchase order **Description:** Scan PO and item barcode, enter quantity and lot, and post the receipt. Over-receipt tolerance is enforced and the result is returned on the device. ### Warehouse stock transfers **Description:** Scan from-location, item and to-location to move stock, with immediate feedback if the item is blocked or the location is invalid. ### Production labor and quantity reporting **Description:** Operators start and stop operations by scanning a traveller barcode, reporting good and scrap quantities and reason codes at the work centre. ### Cycle counting **Description:** Counters receive a list by location, scan and count, and submit variances for supervisor approval before an inventory adjustment is posted. ### Supervisor approvals on the floor **Description:** Scrap above a threshold, rework orders and requisitions are approved in-app with the context needed to decide. ## System Surface Application Function Server (AFS) for programmatic entry into Baan sessions such as receipts, inventory transfers or production reporting, with business validation intact. Availability and syntax depend on the Baan version and porting set. Data exchange and EDI-style batch imports for lower-volume or deferred transactions, useful when an offline device syncs later. Read-only database views for lookups: item, location, open POs, open production orders and bills of material, which keep screens quick. Baan item and warehouse structures such as item codes, warehouse and location, lot and serial tracking, whose rules you must reproduce in the app's validation. Baan user codes and authorisation, mapped to mobile users, with the middleware performing transactions under a defined integration identity and logging the real operator. ## How It Works ### Pick the transactions **Detail:** Start with receipts and transfers or with production reporting, not all at once. Observe the real floor flow, including mistakes operators make today. ### Build the middleware API **Detail:** Expose endpoints such as lookup item, validate location, post receipt. Cache master data and keep queries to indexed fields so responses stay under a second. ### Choose the device and client **Detail:** Rugged Android scanners with a progressive web app or native app. Keep screens large, scan-driven and tolerant of gloves. ### Design for offline **Detail:** Queue transactions locally with IDs, sync when the Wi-Fi returns and surface conflicts. Warehouses with dead zones need this from day one. ### Post with validation **Detail:** The middleware posts through AFS or a staged import, returns Baan's message to the operator and rolls the queue entry to failed status for review when Baan refuses. ### Pilot on one area **Detail:** Run in parallel with the old process for a few weeks, compare inventory accuracy and time per transaction, then roll out. ## Example Flows ### Receiving a delivery **Trigger:** A truck arrives with goods for PO 5502. **Steps:** - Operator scans the PO barcode on the packing slip. - App shows open lines and expected quantities. - Operator scans each item and enters counts, lot numbers where needed. - Middleware posts each line to Baan and returns success or the reason for refusal. - Labels are printed for putaway. **Result:** Receipts post at the dock in real time, not at the end of the day, so MRP and AP see them immediately. ### Production operation reporting **Trigger:** An operator finishes a batch at a work centre. **Steps:** - Operator scans the traveller barcode and selects the operation. - Enters good quantity, scrap quantity and a scrap reason. - Middleware queues and posts the report, flagging scrap above threshold for approval. **Result:** WIP and scrap reflect reality during the shift, and supervisors see exceptions as they happen. ## On Prem Handhelds on the plant Wi-Fi talk to a middleware server inside the network, which is the only component that talks to Baan. Nothing needs to leave the building, and the app can run entirely on a private subnet with certificate-based device authentication. For remote warehouses, use a VPN or private APN rather than exposing the middleware to the internet. If the plant is air-gapped, deploy the app via an internal MDM or sideloading, and keep time sync and printing local. Any AI features, such as reading labels or answering item questions, can use local models on the same server. ## Security - Authenticate users on the device with the plant's identity provider or badge, and record the operator on every transaction. - Use device certificates and enforce MDM policies on scanners and phones. - Rate-limit and validate every request in the middleware; never pass raw input into SQL or into Baan sessions. - Keep the integration account's rights limited to the transaction types the app needs. - Encrypt the local offline queue and wipe it on device loss. ## Options ### Third-party warehouse or MES mobile product with a Baan adapter **Fit:** Large warehouses wanting proven scanning workflows and a vendor to maintain them. **Effort:** Licence cost and adapter project; check the vendor's real Baan references and supported versions. ### Custom progressive web app plus middleware **Fit:** A handful of transactions and a developer who can maintain it. **Effort:** Several weeks for receipts and transfers, plus testing of every Baan edge case. ### Netray-built app and API layer **Fit:** When you also want assisted lookups such as asking the app about an item, built on a local model. **Effort:** Scoped project, piloted on one area before extension. ## Pitfalls - Offline conflicts: two operators moving the same stock produce errors on sync. Decide the rule and show the operator what happened. - Baan sessions that expect screen sequences are brittle when automated. Prefer AFS or batch imports to screen scraping. - Barcode content rarely matches Baan item codes. Plan the label design and cross-reference before buying scanners. - Response time over a slow database kills adoption. Cache master data and keep lookups indexed. - Posting under one shared integration user hides who did what unless you log the real operator in your own audit table. ## Faq ### Does Baan have a mobile client? **Answer:** Not a modern one. Baan IV and V use terminal or Windows clients, and the vendor ecosystem has not provided a mobile app for these versions. Practical mobile access is through a middleware API that you build or buy, which reads Baan data and posts transactions via AFS or data exchange. ### Can we use cheap Android phones instead of rugged scanners? **Answer:** For low volumes and light-duty environments, yes, with camera scanning. For heavy scanning, gloves, drops, dust or cold storage, rugged devices with hardware scanners pay back quickly in speed and fewer misreads. Pilot with both in one area and measure time per scan and error rates. ### How do we handle lot and serial tracking? **Answer:** Treat them as first-class in the app: require lot or serial scans where the Baan item is tracked, validate them before posting and pass them through the same entry path Baan uses. Look up the item's tracking flags in your version's item master so the app enforces the rule at the point of scanning. ### What about real-time inventory accuracy? **Answer:** Real time is limited by how quickly transactions post. If the middleware posts synchronously through AFS, the result is available immediately. If you queue for offline or batch for load, there is a lag. Choose per transaction: synchronous for receipts and transfers, deferred for low-risk reporting. ### Could Baan be replaced instead? **Answer:** Possibly, and many sites plan to move to Infor LN or another ERP eventually. A middleware-based mobile layer helps either way, because the app talks to your API and only the adapter changes later. That makes the mobile investment survive a future migration instead of being thrown away. ## Search terms baan mobile app, baan barcode scanning, baan warehouse mobile, baan iv mobile, baan v handheld, baan shop floor app, baan labor reporting mobile, mobile app for legacy erp, baan inventory scanner, baan rf scanning --- Talk to an engineer: https://netray.co/contact?intent=erp_ai | Machine catalog: https://netray.co/agent/catalog.json