This is an old revision of the document!


Return to Logistics Module

SAHANA Logistics Management Modules Design Requirements version 3

Revision History: 2011-02-23 - posted by Michael Howden: Trying to bring these requirements into alignment with the current logistics developments in Sahana Eden (and visa versa).

Please share any input on the “discussion” (top left) tab for this page.

Logistics Applications

The Logistics functionality of Sahana is separated among a number of different applications:

Separating the logistics functionality into different applications allows deployment to be more easily configured to enable/disable different functionality.

SAHANA Logistics Management Modules Design Requirements version 2

Revision History: 10/12/09 - posted by Michael Howden: These requirements represent the changes agreed upon in the 2009-09-15 Meeting. The changes are mainly the standardization of the language used, and a better categorization of the various functions into modules. The some of the information from the first version of the requirement still needs to transferred to this later version, so developer so refer to both versions, and contact sahana-maindev@lists.sourceforge.net in case of confusion.

Logistics Modules

The Logistics functionality of Sahana is separated among a number of different modules:

We need to be able to configure how each Use Case (process) is accessed and string Use Cases together in a configurable way to create custom work flows for different organizations.
We also need to be able to configure the labels and structures of the menus for different deployments in different contexts.

SAHANA Logistics Management Modules Design Requirements version 1

Revision History: 02/13/09 - posted by Mark Prutsalis: These requirements as posted were initially drafted in 2004 and subsequent to input and suggestions and comments received from Sahana PMC and Board Members, as well as representatives from a couple of international NGOs, were updated last in 2006.

The Sahana Logistics Management Modules include four distinct but inter-related applications – and several supporting applications and library/catalogue content. Additional optional functionality for the tracking of medical goods is required to assure that the Sahana Logistics Management System will be useful for use in pandemic response activities, as well as other disaster response activities where management of medical goods (drugs, supplies and equipment) is requested.

The main Sahana Logistics Management Modules, Supporting Applications, and libraries are:

Main Sahana Logistics Modules:

Intake System: to record the receipt of items within the Sahana managed system

Inventory (Warehouse) System: to track stock levels of goods at storage locations (warehouses)

Commodity Tracking System: to manage and track the movement of goods between locations

Supply Chain Tracking System: to manage and track orders of goods

Supporting Applications:

Logistics Resources: to manage available assets to move goods (trucks, aircraft, vessels)

Sites: to record information about warehouses, airports and other points of entry, and distribution centers [This should become the Sites Registry for all location information within the Sahana library system – including the existing Camp Registry]

People: to record information about individuals related to sites, resources, or goods (this may already exist within Sahana’s base functionality.

Organizations: to record information about organizations involved in the response (government and non-governmental actors, charities, private corporations, etc.) – may be linked to or use the organization registry to support the content requirements in part or in entirety.

Library Content:

A reference library of items, categories/subcategories and medical designations according to international standards (WHO essential drugs list categories).

EVERY PIECE OF DATA SHOULD HAVE A COMMENTS FIELD AND A WAY TO LINK/ATTACH A DIGITAL PHOTO. (i.e. for Commodity Items, Sites, Logistics Resources, People, etc

Intake System:

The intake system is a core piece of functionality that will be used in any modular deployment of the Sahana Logistics Management System. It is used to record the receipt of goods/items at a location using Sahana to manage logistics. It records essential information about goods entering the Sahana-managed system. This will typically be at an airport, port, or other point of entry in a country responding to an emergency. It may also be at a warehouse or distribution center for relief items forward in the operational area of relief operations.

Upon entering the intake system – the user needs to set/identify which Point of Entry (POE) or location he/she will be entering data for. (Once set, it eliminates having to enter this information for every item entered into the system). This should be designed as a lookup to the Sites database – which would include contact & georeferencing information about all POEs and other locations used by the Sahana Logistics Management system.

The user should also be able to record shipments in transit as being received and processed through the intake system (all data transfers over and date/time is recorded, along with how the goods are then handled (stored, dispensed, transit, or shipped forward again). Also, the user should be able to record into the intake system orders tracked through the Supply Chain Tracking System in this manner as well.

The next step will be to enter the essential information about each item received. This should be limited to the following fields of data:

1. Air Way Bill (AWB)/Bill of Lading (BOL)/other tracking number for the shipment

2. Product Name/Description

3. Category/Subcategory (LINK TO LIBRARY LOOKUP MASTER LIST)

4. Sender/Donor/Consignor

5. Recipient/Consignee (POSSIBLE BUT NOT REQUIRED LINK TO PERSONS AND/OR REGISTERED ORGANIZATIONS DB)

6. Designated for: (Specific project, population, village or other earmarking of the donation).

7. Quantity/AWB

8. Shortage/Damage

9. Net Quantity Received [Line 7 minus line 8 – this is used as quantity going forward.

10. Unit of Measure (descriptor: Packing Type/Unit Size)

11. Specifications (additional quanitity quanitifyer – i.e. “4mx5m”

12. Unit Size [Default to 1 – allow users to change it]

13. Weight (set unit of measure flag – KG or LBS)

14. Date (POSSIBLE TO LINK TO AUTO-FIELD – but can override to change)

15. Time (POSSIBLE TO LINK TO AUTO-FIELD – but can override to change)

16. Comments

17. Attachments

Note: DONOR information should include a linked drill down that would allow users to enter NAME, TITLE, and CONTACT INFORMATION (address, numbers, e-mail) that would remain linked to the record until/unless aggregated – such that donor reporting information can be maintained.

At this point – the user needs to identify what they want to do with these items. There should be four options:

1. TRANSFER TO WAREHOUSE/INVENTORY SYSTEM – this would be used at a location with a storage warehouse on site and where items received are not being immediately shipped forward. The items should be placed in a transit state to be processed when the INVENTORY SYSTEM is opened for this site.

2. PLACE IN TRANSIT / TEMPORARY STOCK – this would be used at a location without a storage warehouse on site or where items received are being shipped forward in the short term – though not immediately. This occurs often at airports where large aircraft are unloaded and goods are temporarily stocked on the tarmac until trucks can be brought in to move the goods forward to warehouses or distribution center within a day or two. If goods are being placed in temporary stock – the data entry person should be able to add a STORAGE LOCATION field – in order to make retrieval of the items easier at time of shipment. In addition, it is also possible that they may wish to aggregate items at this time. The aggregation option should be allowed only for items with identical names, units of measure and consignees. If these conditions exist, the data entry person should be asked whether they want to aggregate these items with those matching items already in temporary stock. [Note – if it is important to track goods by DONOR as well – this may need to be added to the aggregation algorithm as an option.]

3. SHIP FORWARD – this would be used where items are immediately loaded onto a truck or other vehicle and shipped forward to another location. The following data should be entered:

  • CONSIGNEE – LINK TO #5 ABOVE BUT ALLOWS USER TO CHANGE IT
  • DESTINATION – LINK TO SITES DB
  • VEHICLE # - LINK TO LOGISTICS RESOURCES DB

4. DISBURSED – this would be used where items received are delivered to the consignee and therefore leave the tracking system. In order to disburse the item, the following items should be recorded. Items may be disbursed directly upon entering the intake system or from TRANSIT/TEMPORARY STOCK

  • CONSIGNEE – LINK TO #5 ABOVE BUT ALLOWS USER TO CHANGE IT
  • NAME OF PERSON RECEIVING ITEMS (as opposed to organization) – LINK TO PEOPLE DATABASE WITH OVERRIDE CAPABILITY.
  • DATE AND TIME OF DISBURSEMENT.

We are now done with the item. The user should be presented with the option to enter another item from the same AWB/BOL/Tracking number or to enter a new one.

The user should also be able to print a shipping ticket/manifest for each Vehicle # entered.

This would be a report in the form of a manifest designed in the attached document: sample_shipping_ticket.doc

Inventory (Warehouse) System:

Upon entering the inventory system, the first step would be to identify and set the location/site which is being managed – then to process any items transferred from the Intake System, Commodity Tracking System, or Supply Chain Management System. This would involve the following steps:

1. ADJUST QUANTITY AND UNIT OF MEASURE – during intake, items may be recorded in bulk fashion (by pallet) or total weight – which is often not the most useful way to track goods. When being entered into an inventory system – it is often more useful to break down those larger units of measure into more useful product units (i.e. into individual items or boxes). For example 25 MT of tents may become 1500 four-person tents. The system should allow for conversion into unit size in kilograms/pounds or in unit/numbers.

2. KITTING and DE-KITTING – users should be able to define a kit that is made up of individual items from stock. This would allow, for example, for creation of a family ration of rice, pulses, and oils from bulk stock. It would also allow dekitting – the breaking up of a single stock item identified as a kit – into its component parts – for example, an “emergency health kit” might be broken down and separated into its individual medications and medical supplies and equipment. Note that the system should not be required to know what makes up a kit in order to de-kit it.

3. AGGREGATE OPTION – again, an algorithm should be run that looks for identically named items with identical units of measure (run after the adjustment above), identical consignee and possibly identical donors/senders. If these conditions exist, the data entry person should be presented with the option to aggregate. Ideally, these conditions should be user options (i.e. aggregate by… followed by a series of check boxes…) The user should be able to confirm the aggregation before it is finalized, or go back to the original separate line items.

4. ASSIGN STORAGE LOCATION – three additional fields of data should be entered to indicate where the items are being stored:

  • BUILDING
  • ROOM/LOCATION
  • BIN #

The inventory system should allow the data entry person to edit any and all fields of data (taken from the intake system.

The inventory system should also allow the setting of minimum stock levels/reorder levels and send alerts to users logged into the system for that location/site when stock levels drop below the set threshold.

The inventory system should also allow data entry users to add stock direct to the inventory – using the same 10 data entry fields as the intake system but with the three added location fields added such that it becomes a one-step process.

To remove items from the inventory – there should be only two options:

1. LINK TO COMMODITY TRACKING SYSTEM – this will be described separately under that section

2. DISPENSE ITEMS DIRECTLY – this would be used for warehouses that distribute items outside of the system directly (either to support an adjoining hospital or distribution center or for NGOs who collect items). To Dispense Items, first the following information should be collected:

  • DATE/TIME (auto with override)
  • DISPENSED TO ORGANIZATION/NAME/CONTACT (link to persons db or Organizations registered db or manual entry)
  • ADD ITEM – then link to inventory – select item and define QTY being dispensed.

The option to add additional items to the same dispensation should be presented to avoid having to repeatedly enter dispensed to information when multiple items are being dispensed at the same time. When complete, the option to CONFIRM AND DISPENSE should be presented. When selected, the inventory should be updated with the reduced quantity figures.

DISPOSAL OPTION FUNCTIONALITY – Sometimes items in stock need to be disposed of because they are expired or otherwise spoiled goods or other items not needed or desired to be tracked anymore. Disposal will similarly remove or reduce stock of items. The following data points should be collected for items selected for disposal:

1. HOW DISPOSED

2. REASON FOR DISPOSAL

3. WHO RESPONSIBLE (link to persons DB with override)

4. CONFIRMED DISPOSED (Y/N Flag)

5. COMMENTS

Commodity Tracking System:

The Commodity Tracking System is used to track and manage the shipment of items throughout the theatre of relief operations and for items to be managed by the Sahana system. It links to all other modules of the Logistics Management System as the means to move and track items between sites/locations and to record distributions of items outside of the system.

The first step would be for the user to identify the site or location which is being managed by the user – this could be a shipping site – a transit site – or a receiving site.

These are the three main options to be presented to the user: SHIP, TRANSIT, & RECEIVE.

SHIP: This is used to record the shipment of items from stock. Its functionality is similar to that used by the intake system to ship items immediately upon receipt. The first step would be to define the basic information about the shipment:

1. DATE/TIME (Auto with override)

2. DESTINATION (LINK TO SITES DB with override)

3. CARRIER # (LINK TO LOGISTICS RESOURCE DB with override)

4. SHIPMENT #/MANIFEST # (auto-generated unique number by Sahana used to track all items on the same shipment).

An ADD ITEM functionality should now allow to user to select the items for shipment from available stock – this can come from one of two sources – TRANSIT/TEMPORARY STOCK or INVENTORY. Both inventories may exist at a single location – if so, the user should specify from which to ship. If only one stock inventory source exists for a given location, the system should simply call up that one. Note – if user has linked to Commodity Tracking from Inventory System, the system should know at this step to call up the Inventory of available stock from the inventory system – not transit/temporary stock.

When the shipment is completed, the user should be able to print the shipment manifest – this would be identical to the one printed from the Intake System (see above).

Shipments may be to sites being managed within the Sahana system (such as other warehouses) or distributions outside of the system – either to distribution centers who will directly distribute the items – or NGOs or UN agencies who will be using the items for their own operations and not using Sahana to further track or manage the movement or distribution of these items.

TRANSIT – The TRANSIT functionality is used to record shipments passing transit points in the theatre of operations. It would be used by any location where carriers and items are checked and then allowed to proceed on to their final destination without a change in carrier information.

The user would be presented with a list of shipments currently in transit (shipped but not yet marked as received). The user should be able to select a shipment and view its records (all items on the manifest – carrier info, sending location info, receiving location info, and all items on the shipment). They should be able to mark a checkbox with arrival and departure time and date fields, as well as a name field (link to people database with override) to indicate the shipment has arrived and departed the transit/checkpoint and the name of the person confirming the information.

If the shipment can not be found from the list of shipments currently in transit, the user should also be able to enter shipments received in transit without a matching record. This is useful to capture shipments that do not originate from within the system. This should bring the user to the INTAKE system to begin the process of tracking shipments from within Sahana. They would use the INTAKE and SHIP FORWARD functionality from that module to complete the process of tracking shipments in transit.

The user should also be presented with the option to RE-ROUTE a shipment. This would change its final destination whilst keeping the entire shipment together and intact (i.e. a truck gets rerouted from Village A to Village B by a transit point. If a truck is offloaded and the shipment split up into separate end destinations – the user should rather use the RECEIVE and SHIP FORWARD option – see below.).

RECEIVE - The RECEIVE functionality is used to record shipments arriving at their destination in the theatre of operations. It would be used by any location where carriers and items are received as the end-point or final destination (until reshipped)..

The user would be presented with a list of shipments currently in transit (shipped but not yet marked as received) destined for their location. The user should be able to select a shipment and view its records (all items on the manifest – carrier info, sending location info, receiving location info, and all items on the shipment). They should be able to mark a checkbox with arrival time and date fields, as well as a name field (link to people database with override) to indicate the shipment has arrived and the name of the person confirming the receipt of the shipment.

If the shipment can not be found from the list of shipments currently in transit, the user should also be able to enter shipments received in transit without a matching record or search for shipments destined for other destinations (it’s possible a shipment gets rerouted whilst in transit that is not recorded by the system). This is useful to capture shipments that do not originate from within the system. This should again bring the user to the INTAKE system to begin the process of tracking shipments from within Sahana. They would use the INTAKE and SHIP FORWARD functionality from that module to complete the process of tracking shipments in transit.

Shipments once marked as received would be treated as items entered from the intake system – they can be stored into inventory; placed in temporary storage, disbursed to the consignee or shipped forward again (to another destination as part of a separately tracked shipent.

Supply Chain Tracking System

The Supply Chain Tracking System is used to track items ordered or expected from outside of the theatre of operations (and outside the commodity tracking of the Sahana Logistics Management System.

There should be a link to the Supply Chain Tracking System from the INVENTORY module – when items fall below their set stock level – the user should be able to enter re-order information.

The Supply Chain Tracking System works similar to the INTAKE system in that it begins the entry process for items in the system. The main menu of the Supply Chain Tracking System should allow the users the following options:

  • ENTER NEW ORDER
  • UPDATE ORDER INFORMATION
  • RECEIVE ORDER

ENTER NEW ORDER: The following fields of data would be recorded:

1. Product Name/Description

2. Category/Subcategory (LINK TO LIBRARY LOOKUP MASTER LIST)

3. Sender/Donor/Consignor

4. Vendor/Supplier

5. Recipient/Consignee (POSSIBLE BUT NOT REQUIRED LINK TO PERSONS AND/OR REGISTERED ORGANIZATIONS DB)

6. Quantity

7. Unit of Measure

8. Weight (set unit of measure flag – KG or LBS)

9. Cost

10. Date Ordered (POSSIBLE TO LINK TO AUTO-FIELD – but can override to change)

11. Date Shipped (could be blank/unknown at time of entry)

12. Air Way Bill (AWB)/Bill of Lading (BOL)/other tracking number for the shipment (if known – could be blank)

13. ETA (DATE)

14. Location item is being shipped – Link to SITES database with override allowed

15. COMMENTS

16. ATTACHMENTS

UPDATE ORDER INFORMATION: This would allow the user to search through the list of orders and update/edit any of the information. The system would allow for all fields to be updated – but should maintain a history of the changes made such that reports can be run against the data for reconciliation purposes.

RECEIVE ORDER: This would allow the user to search through the list of orders and mark an order as having been received – this would immediately link the user to the INTAKE system – where the data fields would be transferred over.

SUPPORTING MODULES/DATABASES:

These modules should all be designed with basic add, view, edit, sort functionality:

LOGISTICS RESOURCES:

The LOGISTICS RESOURCES MODULE/DATABASE is used to manage the available assets to move goods (trucks, aircraft, vessels). It would record the following items of data for each resource:

  • TYPE/RESOURCE (i.e. truck, plane, helicopter, boat, barge, box car)
  • CARRIER/RESOURCE # (id # - plate # - tail # - box car #, etc)
  • OPERATED BY (Owner of resource – usually an organization – link to orgs db)
  • CONTACT NAME: Link to persons db with related contact info
  • CAPACITY (weight/volume limit)
  • RANGE (distance before refueling)
  • BASE – where the resource is based – link to SITES DB
  • AVAILABILITY - only available resources should be deployable as part of the Commodity Tracking system.
  • COMMENTS
  • ATTACHMENTS

This module would be used to provide a database of available logistical resources (which can be used as is by emergency managers).

It should also provide functionality to transfer a logistics resource to another BASE – when this is done – the item should be flagged as unavailable/in transit until a user at the new base confirms its arrival and availability.

SITES MODULE/DATABASE:

The Sites Module/Database is used to record information about important locations in the theatre of operations. This would include warehouses, airports, and other points of entry, and distribution centers, logistics bases, fuel depots, etc.

The Sites database would include the following data fields:

  • NAME
  • TYPE OF SITE (warehouse, airport, railhead, etc.)
  • GEOREFERENCING INFO (GPS coordinates) – link to mapping system
  • ADDRESS INFORMATION (Street, City, Province, State, as used by Sahana)
  • OWNER/OPERATOR – link to orgs db
  • CONTACT – link to people db
  • COMMENTS
  • ATTACHMENTS

The Sites DB should also display any resources assigned to the site (as its base). The Sites DB should be considered for integration with the Camp Registry system for consolidation of location data into a single table.

PEOPLE MODULE/DATABASE:

The PEOPLE module is used to record information about individuals related to sites, resources, or goods (this may already exist within Sahana’s base functionality). The People database would include the following data fields:

  • NAME
  • ORGANIZATION – link to org db
  • LOCATION – link to site db
  • ADDRESS INFO
  • CONTACT NUMBERS (tel, mobile, home, other)
  • E-MAIL (at least two fields)
  • COMMENT
  • ATTACHMENTS

The PEOPLE module should also show (when viewed) any resources or sites or commodities that have been linked to the individual.

ORGANIZATION MODULE/DB

This referred to module should probably just use the registered organizations database from within the existing Sahana functionality. It is used to track all governmental and non-governmental organizations working in the theatre of operations. Users should be able to manually enter an organization (and related data) not found in the database when using the Sahana Logistics system – such new entry should not be flagged as “registered” organizations within the context of the functionality of the organizations registry and should be left out of any reporting done on registered organizations from that module.

MEDICAL/PANDEMIC MODULES:

In order to make the Sahana Logistics Management System work appropriately for medical goods (often in high demand and especially useful for pandemic preparedness and response), additional data fields need to be captured.

  • DOSAGE (e.g. 100 MG)
  • DOSAGE FORM (e.g. CAPSULES)
  • PACKAGING (e.g. BOTTLES/100)
  • EXPIRATION
  • GENERIC NAME
  • STORAGE REQUIREMENTS (e.g. REFRIGERATED, UNDER xx DEGREES)

LIBRARY ENTRIES

These are all user-customizable but the following tables are recommended starting points for the library system with one exception.

In order to assure compliance with WHO drug categorization standards, the numbered drug groups and categories should be part of Sahana’s core library.

WHO Essential Drugs List Categories

For example, the attached contains the WHO Essential Drugs List categories that should be preloaded into Sahana Logistics Module as part of a reference library. The entire catalog of essential medicines (i.e. drug names and standard dosages) could also be preloaded as an option. Other catalogues of emergency supplies could also be prepopulated for ease of reference and entry:

WHO Essential Medicines List (15th edition, March 2007: 08_english_indexfinal_eml15.pdf

Medical Categories for Sahana Logistics Modules (includes WHO drug categories): medicalcategories.xls

Medical and non-Medical categories for Sahana Logistics Modules are in this file: categories2.xls

Mark Prutsalis 2009/02/13 20:43

Comments

  • Bar Codes I suggest supporting bar code readers, especially for inputting of AWB numbers. A there seem to be some relatively good PHP libraries around on the web. Can do some research if req. :-)Tim McNamara 2009/03/29 16:33
  • Revision I've tried to summarize your requirements in preparation to code them up - awaiting comments/suggestions/recommendations/agreement. I feel that some of the “Menus” could be simplified, and we could simplify the design considerably by compiling some of the functions together. This is also a design which I am much more familiar with, and I feel that it better matches how the system would be used in the field by NGOs.

I hope I haven't lost any of the features from the original specifications.

# Sub-Module Process Description Tables User
1 Intake System Intake Receiving item(s) (from outside the system) into the warehouse Shipment, Item, ItemCatalog WH Staff
2 Intake System Intake -TRANSFER TO WAREHOUSE SYSTEM Record where in the WH the item is stored Item WH Staff
3 Intake System Intake - PLACE IN TRANSIT / TEMPORARY STOCK Record where in the WH the item is stored Item WH Staff
4 Intake System Intake - SHIP FORWARD Goes to process 13 Item, Shipment WH Staff
5 Intake System Intake - DISBURSED Goes to process 11 Item, Shipment WH Staff
6 Inventory (WH) System ADJUST QUANTITY AND UNIT OF MEASURE Item, Item Catalog WH Staff
7 Inventory (WH) System KITTING and DE-KITTING Grouping Items into Kits or Upgrouping Kits into Items Item, Kit, KitItems WH Staff
8 Inventory (WH) System AGGREGATE OPTION Group separate records of the same items together Item WH Staff
9 Inventory (WH) System ASSIGN STORAGE LOCATION Record where in the WH the item is stored Item WH Staff
10 Inventory (WH) System LINK TO COMMODITY TRACKING SYSTEM
11 Inventory (WH) System DISPENSE ITEMS DIRECTLY Sending item(s) out from the warehouse Item, Shipment, Distribution WH Staff
12 Inventory (WH) System DISPOSAL OPTION Removing item(s) from the warehouse for disposal. Item, Shipment, (Disposal) WH Staff
13 Commodity Tracking System SHIP Sending item(s) out from the warehouse Item, Shipment, (Distribution) WH Staff
14 Commodity Tracking System TRANSIT Record shipment between sending & receiving Item, Shipment Field/Transport Staff
15 Commodity Tracking System RECEIVE Receiving item(s) into the distribution location or WH Item, Shipment, (Distribution) WH Staff
16 Supply Chain Tracking System ENTER NEW ORDER Entering a new shipment into the system Item, ItemCatalog, Shipment All
17 Supply Chain Tracking System UPDATE ORDER INFORMATION Editting an shipment in the system Item, ItemCatalog, Shipment All
18 Supply Chain Tracking System RECEIVE ORDER Receiving item(s) into the warehouse Item, Shipment WH Staff

# Old # Sub-Module Process Description Tables User
1 1-5,15,18 Inventory Receive Receiving items into the warehouse regardless of weather they already exist within the system. Item, Shipment, ItemCatalog Inventory Staff
2 4,5,11,12,13 Dispatch Ship items out of the warehouse for transit, distribution (directly or remotely) or disposal Item, Shipment, (Distribution), (Disposal) Inventory Staff
3 2,3,6,9 Inventory → Management Adjust Item Adjust Quantity, Unit, Storage Location, Item (from Catalog) Item, Item Catalog Inventory Staff
4 7 Kitting & De-Kitting Grouping Items into Kits or Upgrouping Kits into Items Item, Kit, KitItems Inventory Staff
5 8 Aggregate Option Group separate records of the same items together Item Inventory Staff
6 16 Shipment New Shipment Entering a new shipment into the system (which can be received by a Inventory) Item, ItemCatalog, Shipment All
7 new Request Inventory Items Request specific items to be shipped from Inventory InventoryRequest All
8 14 Shipment Transit Record shipment between sending & receiving Item, Shipment,TransitLog Field/Transport Staff
9 15 Shipment Received Shipment received at final destination for distribution (out of system) Item, Shipment, Distribution Field
10 Inventory → Reports Inventory Legder / Site Summary Lists all the items currently at a site. For a Inventory this will be the Ledger, for a site theis will be all the items distributed here. Items All
11 Inventory → Reports Item Details Lists the details for an Item, and all shipments and transit tracking for that item Item, Shipment, (Distribution), (Disposal),(TransitLog) All
12 Inventory → Reports Inventory Movement Report Lists all the shipments received and dispatched from a site Item, Shipment, (Distribution), (Disposal),(TransitLog) All
Shipment → Reports Shipment Tracking Lists all active shipments which have not been received Item, Shipment, (Distribution), (Disposal),(TransitLog) All

QR Code
QR Code req:logistics_module_draft_requirements_specification (generated for current page)