How to add a mobile app to abas ERP
Short answer
Build a thin mobile front end over an API layer in front of abas. Scan barcodes, post goods receipts and stock moves, report production quantities and approve documents, with an offline queue for poor Wi-Fi. Check first whether an abas mobile product already covers your processes.
The abas client is built for a desk. On the warehouse floor and in the field you need something that fits a handheld scanner or a phone: scan a bin, scan an item, confirm a quantity. Without that, people write on paper and someone keys it in later, so stock is wrong for hours or days.
Before building, check what abas and its partners already offer for mobile and warehouse processes in your version. A vendor-supported option is usually the right first choice. A custom app makes sense when your process is unusual, when you need one app across several systems, or when the standard option does not cover a step such as your inspection routine.
The design below assumes a small API layer in front of abas, because mobile devices should never talk to the ERP directly.
What teams use it for
Goods receipt against a purchase order
Scan the PO or delivery note, scan items and enter quantities, and post the receipt with lot numbers, flagging over-delivery.
Stock transfer and bin moves
Scan source bin, item and target bin, and post the movement immediately so the stock list is right while the forklift is still moving.
Production confirmation
Report good and scrap quantities and time against a work order from the machine, with a reason code for scrap.
Picking for shipments
Show the pick list in sequence, confirm each line by scan, and short-pick with a reason when stock is not found.
Approvals and inspections in the field
Approve a requisition from a phone, or record a quality inspection with photos attached to the lot or work order.
abas ERP integration surface
- EDP interface for transactional posting such as stock movements and confirmations from a service process; the calls and field names depend on your abas release and configuration.
- REST API on newer releases for lookups and some transactions; confirm what is exposed and licensed.
- Existing abas mobile or warehouse offerings and partner add-ons, which may already use a supported interface and should be evaluated first.
- Storage location, bin and lot structure in your abas setup, which defines what a scan must resolve.
- User and role model for authorising moves per warehouse, plus any authentication your site uses such as directory sign-in.
How it works
- 1
Pick processes by pain
Start with one or two high-volume tasks, usually goods receipt and stock transfer. Walk the floor with a user and note the exact scan sequence.
- 2
Design the API layer
Create endpoints that mirror tasks, such as receive_line or move_stock, not generic records. Each validates input and calls abas through EDP or REST.
- 3
Choose the client
Use a progressive web app for simple screens on any device, or a native or cross-platform app when you need robust scanner integration and kiosk mode on rugged handhelds.
- 4
Handle offline
Queue transactions locally with a unique id, sync when connected, and make the server idempotent so a retry never posts twice. Show queue status clearly.
- 5
Authenticate and authorise
Sign users in with your directory or badge, map them to abas users, and enforce warehouse and document rights on the server.
- 6
Roll out in a pilot area
Run one warehouse or line for a few weeks, watch error rates and scan times, and fix the screens before widening.
Example flows
Receiving with a flaky Wi-Fi corner
Trigger: A truck arrives with a delivery note.
- The operator scans the PO barcode and the app loads open lines.
- Each item scan adds a received quantity and lot, stored locally first.
- When the connection returns, the queue posts to the API with idempotency ids.
- The server posts the receipt in abas and returns success or a reason.
Result: Stock is current within minutes, and a failed line is shown clearly instead of being lost.
Scrap reporting at the machine
Trigger: An operator finishes a batch with rejects.
- They scan the work order tag on the traveller.
- They enter good quantity, scrap quantity and pick a reason code.
- The API posts a confirmation and optional scrap booking in abas.
Result: Planning sees real yield the same shift, not the next morning.
Keeping data on-prem
Keep the API layer inside the plant network, close to abas, and expose it to the devices over the plant Wi-Fi or a private VPN. Handhelds never reach the ERP directly. If devices must work outside the plant, use a VPN or a reverse proxy with certificate-based device authentication and no direct inbound path to the ERP host. Because everything is local, no cloud service is required at all, and operation continues if the internet link fails. If you add AI features such as photo-based inspection or voice notes, run the models on a local server and send only results to the API.
Security checklist
- Use mutual TLS or managed device certificates, and enrol handhelds in mobile device management with remote wipe.
- Enforce authorisation on the server for every call, using the mapped abas user and warehouse rights.
- Make every posting idempotent with a client-generated id, and log device, user and time.
- Do not cache sensitive prices or customer data on the device unless needed.
- Separate a test and production environment so training does not post real stock moves.
Ways to get it done
Vendor or partner mobile and warehouse add-on for abas
Effort: Weeks, with licence cost; check version compatibility.
Standard receiving, picking and moves where a supported product matches your process.
Custom PWA or app over your own API layer
Effort: About 6 to 12 weeks for a first pair of processes.
Process steps the standard product does not cover, or one app across several systems.
Partner build such as Netray
Effort: A scoped pilot in one area, then extend.
You want the API layer, app, offline handling and optional AI features such as photo inspection built and documented together.
Pitfalls
- !Letting the app call generic EDP commands instead of task-specific endpoints.
- !No idempotency, which creates duplicate receipts after a retry.
- !Designing screens for a desktop, not for gloved hands and a small scanner display.
- !Ignoring unit of measure and packaging conversions at the scan.
- !Rolling out plant-wide without a pilot and a fallback to the previous process.
Frequently asked questions
Does abas have a mobile app?
abas and its partners have offered mobile and warehouse solutions, but availability and scope vary by version and partner. Ask your abas partner first, because a supported product is easier to maintain than a custom one.
Can it work offline?
Yes, with a local queue on the device and an idempotent API so retries are safe. Reference data such as item lists and bins is cached, and anything that must be live, like available stock, should be clearly marked.
Which devices should we use?
Rugged Android handhelds with built-in scanners are common in warehouses, while phones are fine for approvals and light tasks. Test scanner integration early, since scan intents differ by vendor.
Is a PWA good enough?
For simple, online-first tasks, yes. For heavy scanning, kiosk mode and robust offline, a native or cross-platform app is more reliable on handhelds.
Can we add AI to the app?
Yes. Examples are photo-based inspection notes, voice-to-text for defect reports, and asking for stock by speaking an item name. Run models locally and keep the ERP write path under the same server-side rules.
Want Mobile app working on your abas ERP?
A free 30 minute assessment: we map the integration path for your version and setup, and where it should run.
Get a free assessment