Mobile processes, BE-Mobile Fusion, and legacy MDE
Purpose
This page explains how mobile scanning processes should be classified from a business and technical perspective in Automotive. It connects today’s target architecture around Reactor Mobile or BE-Mobile Fusion with the legacy MDE scenario. This helps project leads, key users, and technical setup roles decide which mobile operating model fits a process and how to set it up reliably.
When each mobile path makes sense
| Situation | Recommended path | Why it matters |
|---|---|---|
| New implementation or current project | use Reactor Mobile or BE-Mobile Fusion | This is the intended path for current mobile warehouse, production, and inventory processes. |
| Existing legacy customer with historical MDE | continue the existing legacy MDE in a controlled way | The old solution grew customer-specifically and should not be introduced as a new standard. |
| Transition phase with hybrid operation | define process boundaries clearly | Without clean separation, double postings, unclear menus, and conflicting operating paths appear quickly. |
| Pure detail questions about the Reactor app | use the dedicated Mobile Solutions documentation | Those pages already describe current app functions per module. |
Mobile processes are real execution, not just a convenience UI
In Automotive, mobile processes are not just an additional screen. A scan on the device controls real warehouse, package, and production movements. Errors in barcode logic, endpoint setup, bin handling, or mandatory fields therefore have immediate operational impact.
Typical mobile use cases are:
- goods receipt and mobile packaging-structure capture,
- put-away and warehouse activities,
- component staging and worker demand,
- production feedback,
- picking and outbound processing,
- mobile inventory and stock reconciliation.
That is why, especially in Logistics Supply Chain, mobile capture, master data, packaging structure, and warehouse logic must always be considered together.
1. Reactor Mobile or BE-Mobile Fusion as the target model
For current projects, mobile usage should generally be planned through the current mobile solution. The repository already contains dedicated module areas for logistics, manufacturing, and inventory. From the Automotive perspective, this page therefore focuses on overall classification and the key setup decisions.
Typical setup areas
| Area | What is defined there |
|---|---|
| Logistics | selection and processing of warehouse activities, scan logic, warehouse document patterns, mobile picking, and put-away |
| Manufacturing | component staging, production feedback, and the related mobile mandatory logic |
| Inventory | mobile counting, item or package capture, and verifiable stock feedback |
Endpoint and profile principle
The legacy documentation makes clear that mobile applications must be profiled cleanly per endpoint and company. The same principle still applies for current projects:
- one approved endpoint per target environment,
- clear separation between test, sandbox, and production,
- explicit alignment of company, authentication, and process scope,
- no reuse of outdated test credentials in general end-user documentation.
The older Fusion notes assume an OData-V4-based endpoint. For current projects, always use the endpoint and authentication path that is technically approved for the respective Reactor or Fusion setup.
2. Treat legacy MDE consciously as a legacy case
The old MDE application is historically grown and was relevant for classic scanner processes in older installations. It is not the preferred target path for new implementations. If an existing installation still uses it, it should be handled consciously as a legacy scenario.
What must be maintained in Business Central or NAV
The legacy documentation mainly names these setup areas:
| Area | Business meaning |
|---|---|
| MDE captions | texts and captions for the mobile display |
| MDE function group list | main menu groups and visible button areas |
| MDE function list | available functions and their assignment |
| MDE function group linkage | which users see which function groups |
| MDE menu linkage | which functions are offered in which menu |
The important point is that caption or function changes must not be tested only locally. They must be verified in the customer-specific overall menu because visibility, order, and call logic depend directly on these tables.
Export and transport of legacy MDE setup
If legacy MDE continues in an existing project, captions and configuration should be moved in a controlled way between environments. The already described export/import functions for MDE configuration and MDE captions are relevant for that.
3. Recommended setup flow for current projects
- Decide first whether the process will run on Reactor/BE-Mobile Fusion or on an existing legacy MDE.
- Keep new processes strictly separate from legacy MDE special paths unless a conscious hybrid mode was agreed.
- Prepare endpoint, company, permissions, barcode logic, and the relevant warehouse or production parameters.
- Maintain the mobile settings per process area, meaning logistics, manufacturing, or inventory.
- Test at least one complete end-to-end case per process with a real scan, posting, and proof in the web client.
- Always define a clear manual fallback process for outage, offline situation, or failed scan.
4. Special rules for hybrid operation
Hybrid operation with old MDE and the current mobile solution is manageable only when processes, devices, and responsibilities are clearly separated.
In such projects, at minimum separate:
- which warehouse or production steps run only through legacy MDE,
- which processes are executed only through Reactor/BE-Mobile Fusion,
- which users and devices belong to which operating path,
- how double postings and parallel scan paths are prevented.
If this separation is missing, typical symptoms are wrong menus, unclear posting results, or contradictory process feedback.
Control steps
| Point in time | What to check |
|---|---|
| Before project start | mobile target architecture is defined clearly |
| Before the first device test | endpoint, company, authentication, and process scope fit together |
| Before go-live | at least one real goods receipt, warehouse, production, or inventory test was successful |
| In hybrid operation | process boundaries between legacy MDE and the current mobile solution are documented |
| After changes | menu visibility, function logic, regex behavior, and document processing were retested |
Typical error patterns
| Situation | Possible cause | Check |
|---|---|---|
| User sees the wrong or too few menus | function group, menu assignment, or module enablement does not fit | inspect mobile menu logic and permissions |
| Login works, but no data appears | endpoint, company, or authentication is wrong | inspect profile and service setup |
| Scan opens the wrong document | barcode or regex logic was not maintained correctly | inspect document patterns and mobile field logic |
| Mobile posting fails although the process seems correct | bin, packaging structure, lot, or mandatory field is missing | inspect BC master data and the mobile scenario together |
| Hybrid operation creates contradictory results | legacy MDE and current mobile solution touch the same process | inspect process separation and device usage |
Result
- You can distinguish current mobile target processes cleanly from historical legacy MDE scenarios.
- You know which setup areas are critical for mobile warehouse, production, and inventory processing.
- You avoid failed starts because endpoint logic, menus, process boundaries, and real tests are brought together consciously.
Links