Shop Floor Mobile Interface: A Simplified POS-style Dispatch Tool

[sancho11]

Hello InvenTree Community!

First, thank you for the incredible work on InvenTree.

The Context:

I am currently implementing InvenTree for a large warehouse scenario. Unlike a supermarket, we manage internal dispatching where materials and equipment are issued to other departments for specific projects. While the backend management is excellent, we are facing significant friction at the "point of dispatch."

The Problem:

We face specific challenges deploying the standard InvenTree interface to warehouse floor workers:

Complexity:

The standard web/app interface is feature-rich but overwhelming for non-technical staff. The cognitive load of navigating Parts/Stocks/Locations leads to confusion and resistance.

Human Error:

Without a forced verification step, workers often pick look-alike parts. We need to eliminate dispatch errors.

Hardware Constraints:

We need a mobile-first solution (phones/handheld scanners) as installing desktop stations is not feasible.

Granular Tracking:

We need to track not just what left the shelf, but who requested it, for which project, and tracking asset condition upon return (BI data for durability/handling).

The Proposed Solution:

I am planning to build (and open source) a simplified "Point of Sale" (POS) style application that acts as a frontend wrapper for the InvenTree API.

The workflow would be streamlined for "Dummies/Foolproof" operation:

• Request Queue: View open "Orders" (Internal requests).
• Pick & Verify: User scans the barcode of the item. The app verifies it against the order. If it’s a "Mix" (Assembly/Build), it guides the picking of components.
• Dispatch: Simple "Complete Transaction" button that handles the backend stock moves, assigns the user/project, and logs the timestamp.

My Questions for the Community:

• Existing Tools: Does a "Kiosk" or "Shop Floor" view like this already exist in the ecosystem? I want to avoid reinventing the wheel.
• Architecture: Would you recommend building this as a standalone mobile app (Flutter/React Native) talking to the API, or is there a way to achieve this via a custom InvenTree Plugin that serves a simplified mobile view?
• Contribution: If I build this, is there interest in bringing this under the official InvenTree umbrella or listing it as a supported community tool?

I am eager to contribute this back to the community so others with large warehouse needs can benefit.

Looking forward to your feedback!

[SchrodingersGat]

@sancho11 sounds interesting!

Out of interest have you tried the existing inventree mobile app? It may not meet all your needs, but perhaps there is a way of extending the functionality there?

Alternatively, there would be nothing preventing such a custom app being developed using the API. The existing UI plugin ecosystem also allows for custom implementations - although the web interface is not mobile friendly.

Both the existing mobile app (written in flutter) and the web interface (React) are built entirely using the existing API.

I would be interested in seeing some mockups of the specific functionality you are considering.

[sancho11]

Thanks for the response! Yes, I have tested the official app. I agree that the foundational features (barcode scanning, parts view) are excellent.

However, based on my testing, I believe a dedicated "Shop Floor" interface is still necessary. This comes down to two main factors: Workflow Friction and Target Audience.

1. Observations on Current Mobile Capabilities: While the app is feature-rich, I ran into some roadblocks during my testing. Please correct me if I missed a setting, but.

• Build Orders: I wasn't able to find a flow to execute Build Orders directly from the mobile interface.
• Finalizing Sales: It seems that while I can process parts of an order, the final step (finalizing) appears to require the desktop web view.
  Even if these features are technically accessible, the current path to reach them feels a bit complex for a fast-paced warehouse floor.

2. The Need for a "POS" Workflow: The current app feels designed for Inventory Management (detailed control), whereas my use case requires Dispatch Execution (speed and simplicity).

• Current Flow: Create order → Assign parts → Allocate materials → Create shipment → Assign materials to shipment → Check shipment → Send → Finalize.
• Required "POS" Flow: Open assigned queue → Scan item to verify → Click "Done."

3. The User Persona: We are targeting Dispatchers and Mechanics, not Inventory Managers.

• Dispatcher: Needs to check assigned orders, verify physical materials match the request, and close the ticket immediately.
• Requester (e.g., Mechanic): Needs to request a "Truck Oil Change" (BOM) without needing to understand the underlying ERP logic.

My goal isn't to replace the current app, but to create a simplified "wrapper" for these specific, high-volume tasks to reduce the cognitive load on non-technical staff.

[sancho11]

Proposed Mockup / Concept Flow

To visualize the solution, I am proposing a "Dual-Interface" approach. The logic relies on hiding the complex API calls (Allocations → Moves → Shipments) behind a simplified UI.

1. The Requester View (The "Internal Store")

Target Audience: Mechanics, Engineers, Staff.

UI Metaphor: E-commerce Shopping Cart (e.g., Amazon/Shopify).

The Workflow:

    Catalog Navigation: Users browse a read-only view of "Salable/Issue-able" stock categories relevant to them (filtering out raw materials or admin-only stock).

    Contextual Cart: Upon checkout, the user selects the Project/Cost Center (e.g., "Repair Job #102").

    Asset vs. Consumable Logic:

        Consumables (e.g., Oil, Screws): Processed as a standard consumption order.

        Trackable Assets (e.g., Special Tools, Scanners): The system flags these. The order remains "Open/Leased" in the backend until the item is scanned back in (Check-in/Check-out logic).

2. The Dispatcher View (The "Kitchen Display")

Target Audience: Warehouse Floor Staff.

UI Metaphor: Fast Food "Kitchen Display System" (KDS) or Kanban Board.

The Workflow:

    Order Queue: A live dashboard showing incoming requests from the "Store."

    Smart Grouping:

        Simple Picks: Direct fetch instructions (Location X → Item Y).

        Build Orders: If a requester asks for a "Maintenance Kit" (which is a BOM), the view expands to show the component pick list required to assemble that kit on the fly.

    One-Tap Execution: The user scans the items to verify. Once verified, a single "Complete" button triggers the full chain of backend events (Allocation, Build Completion, Stock Movement) instantly.

3. The Backend "Magic" (Invisible to User)

The app acts as an orchestrator. A single click on the frontend handles the heavy lifting via the API:

Auto-allocating stock from the optimal location.

Generating the Build Order (if a BOM is involved).

Creating the Sales Order/Shipment.

Finalizing the transaction to update inventory levels.

[matmair]

A lot of the flows and capabilities that you are describing are not present in inventrees design. Have you evaluated the scope and target audience of the system before selecting it?
We do not have lending/issuing stuff; we do not have cost centers; we do not have checking or checkout logic

This solution is mainly focused on manufacturing and selling electronics to b2b clients, this not a generalized wms and erp like odoo - please be aware of that before spending time on shoehorning things in that are contrary to the design goals. You will need to build a bunch of backend logic to achieve what you are describing here.

[sancho11]

Thanks for the push to evaluate Odoo. It was a valuable exercise to audit the alternatives, but after a deep dive, I have decided to proceed with InvenTree. Here is my reasoning:

1. The "Open Core" Constraint I spent significant time evaluating Odoo based on your suggestion. While it covers the feature gaps (like cost centers), Point of Sell, their "Open Core" model is a blocker for us. The fact that the native mobile app and advanced modules are proprietary limits our ability to fully audit and control our stack.

I also researched ERPNext as a fully open-source alternative. However, I found that both Odoo and ERPNext are architecturally designed as "Finance-First" systems.

2. Operational vs. Financial Focus My immediate (and hope long term) priority is the physical reality of our production line, not the financial layer. In ERPs, inventory movements are often tightly coupled with accounting logic (General Ledgers, Journal Entries, etc.). For our warehouse staff, this adds significant configuration overhead.

InvenTree, by contrast, is "Operations-First." It excels at the granular tracking of parts and locations without requiring a financial backend to function. I prefer a modular tool that I can extend, rather than a comprehensive ERP that I have to strip down.

3. The Path Forward I take your warning about "shoehorning" seriously. I understand that by choosing InvenTree, I am signing up to build the missing backend logic (for lending/dispatching) and the custom frontend myself.

I am willing to take on that work because building on InvenTree’s transparent Python/Django foundation is the most efficient path for our specific needs.

Thanks again for the honest feedback, it helped me clarify exactly why InvenTree is the right choice for us.

[sancho11]

I’ve started working on this in a branch of my inventree-app fork. As we discussed, I’m convinced this can be solved mostly on the frontend, so I’m going to try my best not to touch the backend unless it's strictly necessary.

I really want to thank you again for this project. It’s exactly what I’ve been looking for, and I know for a fact it’s going to significantly improve how we handle things in our warehouse. It's a game-changer for us!

Regarding the future: I’m more than happy to see this become an official mode or a parallel project under the InvenTree umbrella. I’ll be honest: I’m moving as fast as I can to solve our immediate needs, and I’m worried I won't be able to provide long-term support once it's running. That’s actually why I want to make it visible now; I’d love for this to 'live' and grow within the community even if I can't be the one maintaining it forever.

Thanks for the support!