How to build a mobile app for SAP ECC 6.0
Short answer
Build a mobile or handheld app that talks to ECC through BAPIs and function modules via a thin API layer, or OData if Gateway is installed. Cover barcode scanning, goods movements, production confirmations and approvals, and plan for flaky Wi-Fi with queued transactions rather than assuming a constant connection.
ECC's native shop-floor options are the SAP GUI on a PC, RF transactions in Warehouse Management, and Fiori on a front-end server if you have set it up. Many sites have none of them in the right place: operators still write quantities on paper and a clerk keys them later.
A purpose-built mobile app for three or four tasks usually beats a general mobile client. The difficulty is not the screen but the interface: which BAPI, which movement type, which errors the operator can actually fix.
What teams use it for
Goods receipt by scan
Scan the PO barcode and item labels to post a goods receipt, with quantity checks against open PO lines.
Production order confirmation
Confirm yield, scrap and labor time to a production order operation from the line.
Inventory moves and counts
Transfer postings between storage locations and physical inventory counting with scan validation.
Mobile approvals
Release purchase requisitions and POs for managers away from a desk.
Maintenance rounds
Create PM notifications with photos and confirm maintenance orders from the field.
SAP ECC 6.0 integration surface
- BAPI_GOODSMVT_CREATE for goods receipt, issue and transfer postings; movement types and account assignment rules matter.
- BAPI_PRODORDCONF_CREATE_TT (or the confirmation interface your release supports) for production confirmations; verify names in transaction BAPI.
- Warehouse Management RF framework (LM00 menus) if you already run WM, which gives standard handheld dialogs.
- SAP Fiori on a front-end server (if installed) and NetWeaver Gateway OData services (SEGW, /IWFND/MAINT_SERVICE) for web-based apps.
- RFC via SAP NCo, PyRFC or node-rfc behind a thin REST service is the most common custom path for ECC.
How it works
- 1
Choose the first workflows
Pick two or three tasks that cost the most keying time, such as goods receipt and production confirmation.
- 2
Build an API layer
A service wraps BAPIs with simple JSON endpoints, handles commit (BAPI_TRANSACTION_COMMIT), errors and idempotency keys.
- 3
Choose the client
A progressive web app works on most Android scanners; native apps give better scanner and offline control.
- 4
Add scanning
Use hardware scanners (keyboard wedge or intent-based) and validate labels against material, batch and PO.
- 5
Handle offline
Queue transactions locally and replay them with unique IDs; warn when the queue holds anything stale.
- 6
Pilot on one line
Run next to the current process for a few weeks and track mismatches before extending.
Example flows
Dock receiving
Trigger: A truck arrives with a delivery for open POs.
- The operator scans the PO barcode.
- The app lists open lines.
- Item labels are scanned and quantities entered.
- The app posts goods receipt via the BAPI and prints labels.
Result: Receipts are posted at the dock, not hours later.
Operation confirmation
Trigger: A machinist finishes a batch.
- They scan the production order traveler.
- They enter good and scrap quantities.
- The app posts the confirmation and shows remaining quantity.
Result: WIP in ECC reflects the floor.
Keeping data on-prem
A mobile app for ECC is usually on-prem by nature: handhelds connect over plant Wi-Fi to an API server in your network, which talks RFC to ECC. Avoid cloud relays for shop-floor posting. If you add voice or photo understanding, run those models on local servers so defect photos and part data stay inside the site.
Security checklist
- Authenticate users with corporate SSO or SAP credentials and map to individual SAP users, not a shared handheld user.
- Lock devices with MDM and enforce screen locks and remote wipe.
- Make every posting idempotent so retries cannot double post.
- Use TLS between device, API and ECC, and restrict the API to the plant network or VPN.
Ways to get it done
SAP-standard RF or Fiori
Effort: Config and training; limited customisation.
Sites already on WM or with a Fiori front-end server.
Custom PWA or native app over an API layer
Effort: 6 to 12 weeks for the first release.
A few specific flows with tailored screens.
Partner such as Netray
Effort: Pilot on one line in weeks.
You want scanning plus AI assistance (defect photos, voice notes) on local models.
Pitfalls
- !Forgetting BAPI_TRANSACTION_COMMIT leaves documents uncreated even when the call returns no error.
- !Locks on material or order records cause intermittent failures; handle and retry.
- !Batch-managed and serial-managed materials need extra fields; test these cases early.
- !Offline queues posting stale data can break negative stock rules.
Frequently asked questions
Is there a standard mobile app for ECC 6.0?
Options exist: WM RF dialogs for warehouses, Fiori on a front-end server, and SAP mobile platforms depending on your landscape. Many sites still build a small custom app for their specific shop-floor tasks.
Do we need NetWeaver Gateway?
No. A thin REST layer over RFC works with plain ECC. Gateway helps if you already run it and prefer OData.
How do we support offline work?
Queue postings locally with unique IDs and replay them when connected. Expect to define rules for conflicts, since stock may have changed in the meantime.
What devices work best?
Rugged Android scanners are common because they have built-in scanners and are manageable by MDM. A progressive web app keeps development simple.
Can AI be added to a mobile app?
Yes, for example photo-based defect notes or voice entry. Run the models locally and keep the posting logic deterministic, with a person confirming.
Want Mobile app working on your SAP ECC 6.0?
A free 30 minute assessment: we map the integration path for your version and setup, and where it should run.
Get a free assessment