Add hooks for new assembly and warehouse service to listen on

[btkostner]

We are integrating two new systems, assembly and warehouse. Both need to know what happens in the outside world in order to update their internal data. This information will be handled async with rabbitmq and bottle messages.

Sub tasks:

• [x] https://github.com/system76/bottle/issues/69
• [x] https://github.com/system76/bottle/issues/70
• [x] ~https://github.com/system76/bottle/issues/71~
• [x] ~https://github.com/system76/bottle/issues/72~
• [x] ~https://github.com/system76/bottle/issues/73~
• [x] https://github.com/system76/bottle/issues/75
• [x] https://github.com/system76/bottle/issues/74

[btkostner]

Some high level overview and discussion

Services

Fulfillment service

• includes all possible builds, even ones for Sager
• only holds 2 statuses. Awaiting to be built, and already built

Assembly

• has no database
• has 3 statuses. Awaiting to be built, pickable, and in assembly
• needs to export quantity of each component needed

Startup process and keeping "picked" status in databaseless system: 1) grpc list all non built builds for location 2) starts process for each build 3) fetch inventory parts attached to build number (calculate if it's picked or not) 4) fetch inventory quantities for each component needed (calculate if it's pickable or not) 5) a build is picked, event is emitted 6) uses build_id on event to mark build process as picked. Saved in memory but not saved in any database

Warehouse

• stores inventory parts and skus
• handles kitting
• exports supply data based on components instead of individual skus
• needs to export list of parts assigned to build id
• needs to export required quantities of sku (genserver tracking for sku quantities?)
• needs to export available kit for component (sku, description, and location with highest quantity)
• will be focus of kitting rewrite to support AND / OR logic

Part picking web interface: 1) load build details including all component_ids and quantities needed 2) makes request for each component_id to grab available kit information (warehouse grpc) 3) part picker can then pick any item 4) item is scanned and async looked up for sku information 5) if item is in list of skus, mark as green, otherwise do nothing 6) scan location to move parts to 7) if all skus are accounted for, submit request. If not, show warning but still allow sending request if confirmed

Events

New Build Created

1) Order is placed 2) Order is created message emitted (TODO: fulfillment service) 3) Fulfillment service breaks down order into builds 4) Build is created message emitted (What we need now)

Fields:

• Build ID
• Order ID
• Supplier / fuilfillment collection. This would be different between Sager, System76 in Denver, and if we ever opened up another warehouse that could fulfill builds. We can probably get away with just doing a string in the database like "System76 Carson"
• Product model
• List of components on that build
  • the marketing name (catalog in Joshua, description in shopify)
  • the SKU (component sku text in Joshua, inventory sku in shopify)
  • quantity

Build Updated

1) Order is updated 2) Order is updated message emitted (TODO: fulfillment service) 3) Fulfillment service diffs new builds vs current builds, creating, deleting, and updated the list of builds 4) Build is updated message emitted (What we need now)

Fields are same as above. Only diff tracking we really need is the list of components

Build Deleted

Same steps as above except if a build has been deleted due to the diff, we emit this message.

Same fields as above. Really only care about the build ID.

Build built

1) Build built event from Tribble through Hal emitted 2) Listened to from multiple services

• Assembly service removes the build process
• Warehouse moves all parts assigned to build to shipped location

Inventory purchase order parts received

This one has multiple receivers that have not all been written yet, so it includes future planning.

1) Lcars scans all parts for a PO. We do some front end checking to ensure everything looks right before making the single HTTP call (TODO: update receiving interface to Lcars) 2) We emit an event about purchase order parts being received (what we need now) 3) Warehouse adds all of the parts from the message into inventory, recalculates component quantities, and emits part quantity update events.

Fields:

• Purchase order ID
• ID of the location they were received at
• List of parts included
  • the sku id they correspond to
  • the uuid attached to them
  • serial number (optional)
  • the line item on the PO they are for
  • price we paid for them (probably removed in the future and handled server side)

Inventory parts picked

This one has multiple receivers.

1) Lcars picks parts for an order 2) We emit an event about inventory parts being picked (what we need now) 3)

• Warehouse assigns build id to parts, and sets location of parts
• Assembly sets build to picked status

Fields:

• Build ID parts were picked for
• Location the parts were picked to
• List of parts picked
  • id of part

Inventory part changed

This one is useful for when an item gets RMAed or manually set to a build (via samwise). A couple of different things can happen here.

1) Lcars user RMAs a part 2) Part updated event emitted 3) Warehouse sees new RMA data. Removes it from the build, updates location, updates RMA data

1) Samwise updates a part build id 2) Part updated event emitted 3) Warehouse sees new build ID and assigns build id to part. It's no longer usable in other builds. The draw back here being we don't have a new location, so it will show up in the old location til manually moved or until the build is shipped.

Fields:

• Part ID
• List of changes (same as other bottle messages)

Component kit change

This one is pretty simple and just emits when a kit has changed for a component. Needed for warehouse to recalculate component availability levels.

Fields:

• Component ID (eventually sku string)
• JSON of new kitting

[btkostner]

Looking at this we have 2 possible prerequisites to get these events working:

1) Inventory purchase order received

This is currently handled with a new part create endpoint and then a purchase order close endpoint in many requests. Possible work around is to fake an "Inventory purchase order received" event for every part http request. We can then update the code to send all at once when we port the PO receiving logic to Lcars.

2) Parts picked

This is handled as a part update endpoint for every part picked on a build. This can possibly be worked around by doing a "parts picked" event for every request that edits the location and build_id.

Just to be clear, the reason these two events exist vs just a regular "part updated" event is because it handles parts in bulk.

[btkostner]

Inventory purchase order received event can be ignored for now. Hal is already broadcasting a part created event, that we just need to integrate into warehouse.

Later down the road, we will be replacing that event with a full PO received event to make this communication more efficient for the http client.

Part created handling was fixed in warehouse https://github.com/system76/warehouse/commit/2a2d03f0096ab5bc8c4604936616c94f63be64f4 Part created events emitted in Hal https://github.com/system76/hal/pull/614

[btkostner]

Alright, the PartUpdated event is now in production. This is also being used to tell if a part is picked or not, so we can delay the actual PartPicked event.

Shows all green in production :heavy_check_mark:

[btkostner]

At this point, all build events have been implemented in hal and assembly service.