Warehouse

An inventory tracking microservice

---

NOTE: This micro service is not fully written yet, and includes references to database records, processes, and workflows that are not yet implemented in here.

This repository contains the code that System76 uses to manage it's warehouse of computer parts. It is responsible for:

• Creating POs with vendors to receive new parts
• Manage receiving new parts from vendors
• Manage kitting and the relationship between what we have in inventory and what is requested from the e-commerce orders.
• Calculating and tracking the demand for different SKUs in our system (available, back ordered, etc)

Communication

This micro service works very closely with (and is dependent on) the Assembly service. The assembly service is responsible for tracking build details. They have a relationship like so:

Assembly ------------------------------------------------------------> Warehouse

This is a gRPC request from Assembly to Warehouse to determine the
`Warehouse.Schema.Component` quantity available. This is used to determine if a
`Assembly.Schemas.Build` has all of the needed parts in stock to build. A
similar RabbitMQ message is broadcasted when that quantity changes.

Assembly <------------------------------------------------------------ Warehouse

This is a gRPC request from Warehouse to Assembly to determine the demand of
`Warehouse.Schema.Component`. This allows Warehouse to determine the back order
status of a `Warehouse.Schema.Sku` and the quantity we need to order. A similar
RabbitMQ message is broadcasted when this quantity changes.

Schemas

This micro service as a couple of schemas it uses, but two stand out as the cornerstones.

        component_1             component_2              <- `Warehouse.Schemas.Component`
       /           \           /           \
      /             \         /             \            <- `Warehouse.Schemas.Kit`
     /               \       /               \
sku_1                 sku_two                 sku_two    <- `Warehouse.Schemas.Sku`

The Warehouse.Schemas.Component schema connects our e-ecommerce platform and assembly system to inventory. Anything that gets sold is a component. When you purchase a computer, every component selected (and some hidden components), are added to a build. These components are represented as a very basic, customer facing names like NVIDIA RTX 3080.

The Warehouse.Schemas.Sku schema is our lower level inventory system. This is a much more specific product that we buy from vendors, like MSI GeForce RTX 3080 GAMING X TRIO 10GB, or G3080GXT10.

The Warehouse.Schemas.Kit schema is how we combine the other two schemas. Every Warehouse.Schemas.Component can be fulfilled by any selected Warehouse.Schemas.Sku, and most Warehouse.Schemas.Skus can be used by multiple Warehouse.Schemas.Components. This comes into play with more complex configurations like memory. A pseudo example of this:

%Component{id: 1, name: "32 GB DDR4 @ 3200 MHz Desktop Memory"}

%Kit{component_id: 1, sku_id: 1, quantity: 4}
%Sku{sku_id: 1, name: "Kingston 8 GB DDR4 at 3200 MHz"}

%Kit{component_id: 1, sku_id: 2, quantity: 4}
%Sku{sku_id: 2, name: "Crucial 16 GB DDR4 at 3200 MHz"}

%Kit{component_id: 1, sku_id: 3, quantity: 2}
%Sku{sku_id: 3, name: "Kingston 16 GB DDR4 at 3200 MHz"}

Development Setup

First, make sure you are running the dependency services with docker-compose:

docker-compose up

Dependencies are managed via mix. In the repo, run:

mix deps.get

Then run this to test the project:

mix test

Contributing

This project makes use of https://pre-commit.com/ to ensure code quality before pushing it to Git. While this is not a requirement, it's encouraged to have pre-commit installed with pip install pre-commit, and the in this project root, run:

pre-commit install