Portal/ Mobile interface

[agritheory]

Actions

• Material Transfer
• Manufacture
• Repack
• Send to Subcontractor
• Material Transfer for Manufacture
• Material Consumption for Manufacture
• Receive (Purchase Receipt)
• Ship (Delivery Note)

Components already in progress here

[agritheory]

Splitting some of the workflows here into separate tickets by the user's responsibility.

Shipping and Receiving

• Purchase Order => Purchase Receipt
• Sales Return / RMA
• Send to Subcontractor
• Pack and Ship

Stocking

• Material Transfer / Material Transfer for Manufacture
• Stock Reconciliation

Manufacturing

• Material Transfer for Manufacture
• Manufacture
• Repack
• Material Consumption for Manufacture

[agritheory]

There are three general patterns for directing the user about what actions need to be taken. These concepts are valuable for building the listview(s) for each core responsibility of BEAM. They can be further filtered by warehouse and/or workstation.

1. Items have arrived and need to be processed
   1. A package from a supplier has arrived and it needs to be received
   2. A package from a subcontractor(supplier) has arrived and it needs to be received
   3. A package from a customer has arrived and it needs to be processed as a return
2. Items have entered a warehouse that need to be shipped
   1. Typical of manufacturing processes, when done, the items should be placed in a finished goods warehouse to indicate their readiness
   2. In a case where items need to be send to a subcontractor, use the configured workflow for creating shipping documents
3. A newly submitted document has identified items that need to be moved or shipped and are already in the appropriate warehouse
   1. Sales Order has been submitted that indicates that items are ready to be shipped
   2. A Material Request for Manufacture or a Material Request for Transfer has been created (often by a Production Plan) that asks items to be moved from one warehouse to another (usually their default or putaway warehouse to WIP)

---

The status and ordering/ prioritizing of these actions from internal activities (2 and 3) reminds me of one of the more interesting use cases for Redis: a leaderboard. They've built a Django-based example with a frontend. I think this would be a reasonable way to communicate to the various users what needs to be done and where. This would probably be best implemented by updating the leaderboard from enqueued dochooks on Bin, Sales Order and Material Request. The only state that would need to be managed for the document would be when something is manually reprioritized, which can be a regular whitelisted function that save the new ordered value and pushes to the clients. If one of the "action signals" gets a "start" action from the user, that value can also be updated and the pushed to the subscribers of the leaderboard. The client side of the leaderboard can be filter out "active" documents.

[crabinak]

@agritheory Here is a link to the wireframe in Figma. If that does not work, I also have a PDF attached.

BEAM Work Station Wireframe.pdf

Let me know if this is close to what we discussed or if I misinterpreted. The idea here is that work orders open the split layout for job cards and work timers. Clicking job cards will bring up the job instructions as well as retain the timer.

[hpema]

I see the design is mostly focused on work order layout. Would like to also see the design around inventory movement flows. Also @agritheory , should we add a slight shadow on the cards? I would like to see what that looks like,

[agritheory]

@hpema Wireframes don't typically have a box shadow or other styling, it's more of a "locating" reference. The other point about this being about the Work Order flow is a good one. Curt and I didn't cover that in the brief we had about this, but we probably want to add it. It is possible but not always (usually?) appropriate to let the Work Order drive the material transfer and consumption. Once we have a way to add that, I think we'll also want to run through the spec/outline and think about how each step goes wrong and we recover from it.

@crabinak I really like the thoughtfulness and clarity of the pages 3 and 4 of the design, it's a nice improvement on what I had imagined. The list view I have a feeling we'll change but I don't know exactly how yet - likely some filters - but I think it will be more of a refinement once we have have an interface that we can manipulate. The login page will probably get a message than tells operators they'll be able to scan in if that's enabled, but is otherwise the kind of straightforward design we're looking for.