Basic stock management is the on-going accounting of medical commodities, stock, that is with someone and/or at somewhere (e.g. # of vials of a particular vaccine in my clinic's refrigerator) over time.  This document attempts to establish common abstractions and terminology, define the outer edges and relate it back to existing OpenLMIS concepts.

Many of the concepts and ideas presented here borrow heavily from Martin Fowler's writings on Accounting.

Existing OpenLMIS concepts are often used with a capital letter for recognition here.  e.g. Facility in OpenLMIS is a concept, and not necessarily what a country or public health professional considers a facility.

First cut on Stock Management Class Interfaces

Where

Stock is accounted for on a stock card by Product.  A stock card is located at a place, e.g. a rural health clinic, a national warehouse, a particular refrigerator within a regional hospital's storeroom.  In theory it could also be with a person such as a delivery truck driver in route or a field coordinator out making rounds topping up other stocking locations.  For now stock cards should be tied back to an OpenLMIS Facility. i.e. a place.  In the case of a physical building, such as a hospital, having multiple administrative units or even buildings, each that has stock, each unit or building would be entered into OpenLMIS as its own Facility which allows for the accounting of stock through stock cards.  e.g. a large hospital might also serve as a regional vaccine warehouse, the hospital's stock room would be a Facility, and the regional vaccine warehouse would also be a Facility.  In this way the regional vaccine warehouse could transfer stock to the hospital's stock room as well as other facilities served in the district.

Locating stock at a Facility gives us the following:

• may know the population served by that Facility, and in the example above a regional vaccine warehouse might serve a broader population than the hospital it physically co-resides with.
• will know the Geographic Zone (and therefore level hierarchy) it exists in, and we may know it's latitude and longitude.
• will know which programs are supported at the Facility (and by extension which Products are within those Programs (push and pull)
• will know which products are approved for that Facility (through Facility Type) by Program, and by that association we will know max months of stock and we may know min months of stock and emergency order point. (pull)

To determine if a Facility is managing stock (or having it managed) we look at:

• if the Facility is configured to manage stock (see open questions)

What

Stock cards are not only located somewhere, but they are also by Product.  So if I have vaccines BCG and Polio, I have one stock card for BCG and one stock card for Polio.  In OpenLMIS, vaccines, and all other commodities are modeled using Product.  Furthermore a Product is supplied though one or more Program(s).  So we might have a Vaccine Program and an Essential Medicines Program.  While clearly each Program would mostly supply different products, as an example lets say that cotton balls are supplied through both programs for use in injections, in this case we'd have one Product, cotton balls, and stock management of cotton balls would be for the Product cotton balls and not cotton balls for the Vaccine Program and cotton balls for the Essential Medicines Program.

In addition to accounting by a Product, certain products such as vaccines may account for stock through additional dimensions such as lot/batch and/or expiration date.  In this case the entries to a stock card may distinguish quantities received and issued by further dimensions.  e.g. Issued 10 vials of BCG of lot #10, or Issued 10 vials of BCG with expiration date June 20, 2015.

When accounting for stock, we account by a Product's dispensing unit.  This matches existing stock reporting available through the R&R and elsewhere and enables re-order calculations to utilize concepts such as Average Monthly Consumption or Ideal Stock Amount.  For most products, accounting by dispensing unit comes naturally (e.g. a pack of 100 bandages might be dispensed individually while a pack/bottle of pain-killers might be dispensed as pills given in pairs).  For others however, such as a vial of a vaccine, accounting of stock for certain reasons may make more sense by pack size.  e.g. a vial of BCG modeled using a pack-size of 20 dispensing units would want to be tracked by pack-size when a vial is delivered, transferred, etc through stock management.  However if our stock management was asked to account for open-vial wastage of BCG we'd like that accounting of stock to be by dispensing unit in order to determine the fractional components of a vial that was utilized and that which was wasted.  It's therefore useful to think of the reason stock is being accounted for when determining which unit of a Product should be used: such as order fulfillment & inventory could be by pack-size while usage and spoilage could be by dispensing-units for vaccine Products whereas all antibiotics might always be entered in terms of pack-size.

To determine if stock for a Product is managed at a Facility we can look to see if:

• the Product is configured for stock management
• the Product is available to the Facility by an active Program supported (Push and Pull)
• the Product is available to the Facility by Facility Approved Products (Pull)

When

Stock is managed both as part of larger processes (R&R, Distributions) as well as potentially a daily book keeping activity.  When stock is managed as part of a logistics process it tends to take the form of reporting on the beginning balance of that Product.  e.g. an R&R may be configured to have a person do an inventory of current stock as part of submitting a request for more or as part of a distribution process a field coordinator may record the same beginning balance as they attempt to top the facility up to its Ideal Stock Amount.  In this sense stock management could be seen as occurring as part of a Schedule's Processing Period by Program.  When stock is managed as part of fulfilling an order or as part of daily operations however it may make less sense to consider it apart of a Program Schedule.  i.e. the act of requesting stock and approving the request or a field coordinator making a distribution is based on Program Schedule.  Daily stock management at a Facility, transfers to other facilities or the end result of a stock requisition - fulfilling the order are at best tangentially related to a Program's Schedule.  Stock management therefore should support management of stock outside of any Program Schedule (e.g. Vaccines at service delivery points monthly, essential medicines quarterly).

Stock management therefore is an accounting that should support asynchronous operation (e.g. I manage my health clinic's store room independently of the larger health system on a daily basis).  Because of this it makes sense to think of events that occur to my stock of a product as always incorporating at least two date-times:

• Date stocking event occurred.  e.g. the date I used 2 vials of the vaccine BCG or the date I received 200 vials of BCG.
• Date stocking event was noticed.  e.g. I used 2 vials of BCG on June 1st but I didn't tell the central system about this until I synchronized on June 3rd.

Using at least these two dates supports an inherent understanding that the date stock is accounted for, may not be known by a larger system until some later date, much in the way that when you send a check to someone that the date on the check is the date the check was written, a date you account for, and later someone will deposit that check into their account, a date that the bank will account for.  Additionally having these two dates allows us to ask the following questions:

1. What's my stock quantity as of <date or date-time>
2. What's my stock quantity as of <date or date-time> as reported on <date or date-time>

The first question is the most common inquiry to be made about my stock on hand.  However the answer to this question may change as my larger system records/notices events.  Taking the check example further, I might write two checks on June 1st, lets say the first is for $10 deposited June 3rd and the second for $20 deposited on June 10th.  In answering the question what's my balance as of June 1st, my checkbook might show my balance minus the two checks I wrote:  balance - $30.  My bank however won't know about those checks until they're deposited at some later date.  From the perspective of my bank then, my balance on June 1st will disagree with the balance of my checkbook on June 1st.  If my bank had a policy that stated that the date I wrote the check is the date my balance is accounted for, when I ask the bank what my balance as of June 1st is on June 1st, it will answer without the debits from the two checks.  On June 3rd however when my first check is used the bank would answer, per the theoretical policy above, that my balance as of June 1st was less the first check, balance minus $10.  It would then be useful to have the second question answered:  what was the balance of my account as of June 1st as reported on June 1st as it would accurately reflect what my system, the bank, knew as of June 1st.

Who

With existing OpenLMIS concepts answering the question of who (User) can manage stock at a Facility for a Product is supported through two separate structures:

• Pull systems support home and supervised facilities through a Supervisory Node structure.  At the bottom of such a structure is one more more Requisition Groups which tie one or more Facilities to a Program and Schedule.  Adding an "Active Stock Management" right to a role a user has assigned through either a home facility or supervisory role would give the User the ability to actively manage stock for the associated Program(s) for Facilities in the Requisition Group.
• Push systems support management of Facilities through Delivery Zones.  Adding an "Active Stock Management" right to a role a user has and associating it with a Program and Delivery Zone would allow that user to actively manage stock at every Facility in that Delivery Zone for that Program.

Why - ish

The final of the 5 W's, it can be assumed that at every interaction a person would have in managing stock, it's good practice to allow them to provide a why for their actions.

Design Abstractions

Stocking Events

A stocking event is the origin of accounting for stock.  Three types of events are immediately apparent:

1. Credit or Debit:  this is the most basic type of event, it describes either adding or subtracting stock from my stock card.  It may be used to cover real-world events such as a clinician using 2 vials of BCG (debit), or a Rotary Member of good intent donating 1 vial of Polio (Credit).  Within this event there might be more descriptors that describe the Credit or Debit that occurred.  e.g. a debit of 2 vials of BCG might come with the descriptor that the vaccines expired and were thrown away, or they might describe them as being used for giving inoculations.  Similar descriptors could be in use for Credits, however it's important to note that a Credit or Debit is not used for transfers (issuing or receiving stock) or for adjusting my recorded balance to match my actual balance.
2. Transfer:  this type of event is useful for situations where stock is issued from one Facility and received by another.  e.g. my district vaccine store might issue 2 vials of BCG to my village's clinic.  This event would lead to multiple entries to both facilities stock cards, subtractions from my district vaccine store and additions to my village's clinic.  Depending on business processes in use, when these occur, or if a person needs to receive them at the clinic before they are officially added to the inventory, would be aspects of when these entries are created or what statuses they might have (e.g. pending until signed for).
3. Balance Adjustment:  this is a common though quite different type of event.  While Credit or Debit and Transfer events both result in likely straightforward entries to one or more stock cards (I used X quantity of Y Product), a Balance Adjustment makes a declaration about the current stock on hand of a particular product at a specific date and time.  Entries to the stock card would then be made to arrive at the declared balance.  This is useful for supporting facilities performing inventories and is in use in both Push and Pull processes whenever a "beginning balance" is asked for.  In a distributed system this is also useful as different locations may not all have the same entries in their stock cards.  e.g. the central system may think my rural clinic's balance is 100 vials of BCG as a issue of stock (transfer) was recently made to me.  I at my clinic however may have not synced with the central system yet and may not have physically received those vials of BCG and want to declare that my balance as of June 10th 2015 10:15 CAT is 80 vials of BCG.  Any pending transfer of stock to my clinic might result in a different balance than originally planned.  Balance Adjustments are common wherever current processes ask for beginning balance of stock as part of a resupply process.  They are however "lossy" in that what occurred to that stock to result in that balance is not known.

In addition to the types of stocking events above, we can also say that all events have at least two dates:

1. the date the event occurred.  This is not the date the event was recorded, or the date the event was synchronized.  It is ideally the date the event actually occurred.  e.g. I used 2 vials of BCG to give inoculations today, but I might forget to record or synchronize it until tomorrow.
2. the date the event is processed.  This is the date that the event is transmitted and processed by the central system.  It allows us to understand that our events are not always seen and processed by a central system in chronological order.

To add: adjustment events - the why and what types of events allow adjustments and when

Accounts (Stock Cards and Budgets)

As Fowler mentions, Accounts are containers for Accounting Entries.  In OpenLMIS w/Stock Management we currently have at least two types of Accounts:  Stock Card and Budget.

There are a couple typical questions made to Accounts:

• what's my available balance today?
• what's my available balance as of this date and time?
• what was my available balance as of this date and time as reported on this date and time in the past?
• what are your entries?
• what are your entries as of this date and time?
• what are your entries as of this date and time as reported by this date and time in the past?

Stock Card Account

The stock card account holds line items / entries in terms of positive or negative quantities against a particular Product x "AccountType" where AccountType could describe some combination of:  Lot/Batch, Expiration Date.  This distinction by "AccountType" ensures that credits or debits against an Account are of the same type.  e.g. If I credit 2 vials of the vaccine BCG of Lot A I must do that to the Account that holds entries of BCG of Lot A and not the account that holds BCG of Lot B.

Budget Account

This section needs further thought when Stock Management might interact with existing Budget capabilities.  In short however a likely use case for creating entries to a Budget account would occur when a transfer of stock occurred between two facilities and the freight cost of sending that stock would like to be tracked against "someones" Budget.  This section isn't going to completed until the need is of higher priority.

Accounting Entries (Stock Card Line Items...  Budgets?)

Stock Card entries or line items describe specific credits or debits made against an account.  In addition to a positive or negative value, these entries should include:

• type - Lot, Expiry
• link back to originating event