Inventory Management

[mosesmbadi]

THIS DOCUMENT IS UNDER ACTIVE DEVELOPMENT

IM - Inventory Management
PO - Purchase Order
II- Incoming Item
RN - Requisition Note
RI - Requisition Item

Given the complexity of IM, it is prudent we have guiding document, this note serves that purpose.
First things first, these is the data we need to keep track of;

Field	Description
Items	The items being managed.
Lot No	Unique identifier for batches of items.
Departmental Quantities	Quantities allocated to specific departments.
Main Inventory Quantity	Quantity available in the main store inventory.
Purchased Item	Indicates whether the item was purchased.

First things first, we have the Item table. This serves as a container for items attribute. Data contained here is that which doesn't change often.

Data Flow
A user/staff will create a requisition note. The note will have the items they're requesting, quantity and approval status. The individual RI will have to be approved by the department head and the procurement officer. Once approved, the system will create a PO grouped by supplier for the requisition items. The PO is what is sent to the suppliers to supply the items. Once the items are supplied and delivered, they're called IncomingItem. Incoming Items will be handled by IncomigItem table. Records created here will trigger the Inventory update and the GoodsReceipt note model will be updated.

graph TD
    A[User/Staff creates Requisition Note] --> B[Requisition Note]
    B --> C[Approval - Department Head]
    C --> D[Approval -  Procurement Officer]
    D --> E[PO grouped by supplier]
    E --> F[PO sent to suppliers for fulfillment]
    F --> G[Supplied items received as Incoming Items]
    G --> H[Incoming Items stored in IncomingItem table]
    H --> I[Inventory updated]
    H --> J[Goods Receipt Note]
    H --> K[SupplierAccount]

Loading

Packed and Subpacked
Packed and sub-packed will be stored in the Item table but should be visible and editable when recording an incoming item. A crate of eggs will have 30 eggs, a pack of cigarettes will have 12 pieces inside, but their visibility when recording incoming item is so as to provide the flexibility to update if there are changes.

You have 1 pack(box) of 20 syringes inside packed will be 1 and sub-packed will be 20. If you have 60 syringes in stock (quantities_at_hand). That means you have 3 packs (boxes). Procurement document should then show 3 boxes..

You have one chair. Packed is 1 sub-packed is 1. If you have three chairs in stock (quantities_at_hand). That means you have 3 chairs. Procurement will order 3 chairs.

Throughout the system, our BaseUnitOfMeasure is the sub-packed i.e whenever quantity is mentioned, we're referring to sub-packed, multiplied by packed.

One solution is to use a converter that can be called to get those three properties.
So if I have 30 items in stock under quantities_at_hand, I'll need to have the packed and subpacked to determine how many packs and how many pieces under each pack. Packs here is used universally to represent boxes, crates, e.t.c. In that case the default packed and sub-packed is 1 and 1. This is because, an item such us a chair comes with no collections, it's just one chair. If I have 20 chairs in stock, and packed is 1 and sub-packed is 1, that means I have 20 chairs and that's it. However if I have 120 gloves in stock and their packed is 1 and sub-packed is 12, that means I have 10 boxes/packs of gloves.

A BETTER APPROACH: Packed will always be 1. Yah, I know. Doesn't make sense. But what if packed be the UnitofMeasure, such us box, crate, pack. We can now store the number of pieces inside a box, crate or a pack as the sub-packed.

Sale and Purchase Price
Since these are more of an Inventory Item itself properties and not attributes of an Item, they will be stored in the inventory table. From there, they can be updated when recording an incoming item. Like Packed and Subpacked, they will be fetched and displayed while also allowing the user to edit in-case of changes in price.

Goods Receipt Note
Goods receipt note is an internal document that serves the purpose of it's name. In simple, it's the PurchaseOrder, with its items, plus some extra fields; quantity received, lot number, expiry date for every item, and for the document itself: goods receipt number, amount, PO number, date received, invoice number, delivery note number, received by, verified by. Most of these information is already in the IncomingItem therefore we can only add an extra table to store information related to the note itself and not the individual items.

GoodsReceiptNote

Field	Description
PO_Number	Purchase Order Number
DeliveryNote_Number	Delivery Note Number
Received_By	User who received the goods
SupplierInvoice	Supplier Invoice ID

[roseMunyiri]

Okay so we have the this: IncomingItemsReceiptNote and this GoodsReceiptNote. The idea is that should actually be one model right? As Robert mention it should have:

• PO number
• good_receipt_no (generated automatically when note is saved)
• total amount of all incoming items in the receipt note
• delivery_note_number (keyed in)
• supplier_invoice (keyed in)
• date received (manual input)
• All the incoming items associated with the receipt note: (item_code, item_description, quantity_ordered, quantity_received, purchase_price, total_amount(purchase_price * quantity_received)

[mosesmbadi]

I have updated the doc with the GoodReceiptNote implementation