GM-X ERP for Blockchain - The SHIPMENT subsystem

By Tony Marston

22nd August 2007
Amended 7th April 2024

Introduction

1. Shipments

2. Outbound Packages

3. Inbound Packages

4. Drop Shipments

5. Shipment Status

6. Dispatch Events

7. Advance Shipment Notice (ASN)

8. Returned Material Authorisation (RMA)

9. Initial Values

Amendment History

Introduction

After orders have been taken the goods have to be sent to their destinations. Enough information needs to be maintained during this process so that the following questions can be answered:

• What is being shipped?
• When will it be shipped?
• From where is it being shipped?
• To where is it being shipped?
• What is the current status of the shipment?
• What inventory receipts and issuances occurred at what times and at what locations?
• Was the entire order shipped, or only part of it?
• What carrier was used in the shipment?
• What route did the shipment take?

A shipment is basically a movement of goods from one party to another party. It contains the items from a single order, but an order may require several shipments if items are dispatched on different days or from different locations. A shipment contains one or more packages, and each package contains quantities of one or more items.

Shipments fall into one of the following categories:

1. Outbound - from the organisation to an external location:
   • Customer shipments - goods being sent to a customer.
   • Supplier Returns - goods being returned to a supplier.
   • Outbound Transfers - goods being transferred to another facility within the same organisation.
2. Inbound - from an external location into the organisation:
   • Customer Returns - goods being returned by a customer.
   • Supplier Receipts - goods being received from a supplier.
   • Inbound Transfers - goods being transferred from another facility within the same organisation.
3. Drop Shipment - this is where the shipment moves from one external party to another external party, typically used by a distributor to ship products directly from a supplier to a customer without having those products held in the organisation's inventory.

When an outbound shipment leaves the premises, usually by vehicle, this is known as a dispatch event. Each dispatch event may contain any number of shipments.

Shipments

Each shipment has a sending party with a sending address and optional contact details, plus a receiving party with a receiving address and optional contact details.

Figure 1 - Shipments

SHIPMENT table

This holds the details of all shipments, both outbound and inbound. A shipment is a collection of one or more packages for a single customer for a single order. An order may have several shipments if different items are shipped at different times.

The sender identity and source address are held for those circumstances where an enterprise deals with shipments from subsidiary organisations, or from several addresses. If one or both of these values are fixed it is possible to define them as initial values within the MENU system so that they will be filled in automatically.

PACKAGE table

Each shipment consists of one or more packages which have their own identity numbers. The package contents are dealt with slightly differently depending on whether the package is outbound or inbound.

SHIPMENT_ROLE_TYPE table

This identifies the types of role that a party may have when dealing with a shipment.

SHIPMENT_ROLE table

This identifies the parties who play a role in a shipment.

Outbound Packages

An outbound package contains quantities of one or more products which are normally issued from inventory, but which may have been moved directly from an inbound shipment without the need to go through inventory. Items from an incoming supplier's shipment which are rejected can be returned to that supplier without being received into inventory.

Figure 2 - Outbound Packages

PACKAGE_OUT_CONTENT table

This holds the details of every product contained within an outbound package. There may be more than one product in a package, and there may also be quantities of the same product distributed among several packages if the total quantity is too large for a single package. The product is identified either by the ITEM_ISSUANCE or the PACKAGE_IN_CONTENT record.

PACKAGE_STATUS_HIST table

This keeps a history of all changes in the delivery status for an outbound package. This is in addition to the status of the shipment as a shipment may contain more than one package, and individual packages may suffer different fates (such as being lost or damaged).

Inbound Packages

An inbound package contains quantities of one or more items which are either sent in from a supplier, returned by a customer, or transferred from an external location. Details of individual items are held on the PACKAGE_IN_CONTENT table.

Figure 3 - Inbound Packages

PACKAGE_IN_CONTENT table

This holds the details of every product contained within an inbound package. There may be more than one product in a package, and there may also be quantities of the same product distributed among several packages if the total quantity is too large for a single package.

As the items are removed from their packages they are normally inspected, and quantities can be marked as either accepted or rejected. Rejected items can be immediately transferred to an outbound shipment for return to the supplier, while accepted quantities can be booked into inventory.

The order_id and order_item_seq_no are normally only provided when the item from the supplier is for a specific sales order item. This will enable the item to be immediately moved to an outbound shipment for the relevant customer.

PACKAGE_IN_FEATURE table

This holds the details of the optional features associated with an item contained within an inbound package.

PACKAGE_IN_FEATURE_CUSTOMISATION table

This table holds all the customised values for a feature which apply to an inventory item. Some features within a feature category may be able to be customised, such as engraving options for jewellery will need the text which is to be engraved.

REJECTION_REASON table

This holds the reasons for which items received from external sources may be rejected and returned instead of being booked into inventory.

Here are some examples:

• Damaged
• Wrong quantity
• Wrong product

RECEIPT_ROLE_TYPE table

This identifies the types of role that a party may have when receiving items from incoming shipments.

Here are some examples:

• Signing for the receipt
• Inspecting the goods being received
• Storing receipt within inventory
• Receiving Manager

ITEM_RECEIPT_ROLE table

This identifies the parties who play a role in the receipt of items from incoming shipments.

Drop Shipments

This is where the shipment moves from one external party to another external party, typically used by an organisation to ship products directly from a supplier to a customer without having those products held in the organisation's inventory.

Each shipment goes to a single supplier, and instead of containing packages of items it contains the order details for one or more items.

Figure 4 - Drop Shipments

DROP_SHIPMENT_ITEM table

This identifies the items which a supplier will ship direct to the customer. The customer details are supplied on the ORDER_HEADER.

Shipment Status

A shipment will be in different states at different points in time, and instead of just recording the current state it may be more useful to maintain a history of each change in state.

Figure 5 - Shipment Status

SHIPMENT_STATUS_HIST table

This keeps a history of all changes in status for a shipment. The entry with the highest sequence number is the latest.

Dispatch Events

When an outbound shipment leaves the premises, usually by vehicle, this is known as a dispatch event. Several shipments may leave in the same vehicle, and that vehicle may have to visit several locations in order to deliver all those shipments.

All the packages within a shipment must leave the premises in the same dispatch event. If packages need to be split across multiple dispatch events then they must be treated as separate shipments.

If an organisation uses its own vehicles for shipments then it may be useful to keep a record of those vehicles and the journeys that they make. It is also possible to record the mileage and fuel usage for each dispatch event, which may then be used to calculate the cost of the delivery.

Figure 6 - Dispatch Events

DISPATCH_EVENT table

This identifies every instance when shipments leave the premises to be delivered to their destination. The destination may be the customer's address, or it may be some sort of transfer facility.

When a DISPATCH_EVENT is associated with a VEHICLE, that VEHICLE has the ‘Weight distance (i.e., freight transport)’ activity_type value, and the actual_weight_gcw of the DISPATCH_EVENT is zero or NULL, the system will calculate actual_weight_gcw using the following formula:

    actual_weight_net + actual_weight_tare = actual_weight_gcw

SHIPMENT_DISPATCH_EVENT table

This identifies which shipments were part of the same dispatch event.

PACKAGE_DISPATCH_EVENT table

This identifies which packages were part of the same dispatch event. It can also record when the package was delivered, or the reason for the delivery being rejected.

SHIPMENT_METHOD_TYPE table

This identifies the different ways in which items can be shipped.

Here are some examples:

• Truck
• Ground
• Air
• Rail
• Cargo Ship

CARRIER_SHIPMENT_METHOD table

This identifies which shipment methods are used by which carriers.

VEHICLE_TYPE table

This identifies the different types of vehicle that the organisation may use for shipments.

Here are some examples:

• Bicycle
• Two Ton Truck
• Ten Ton Truck
• Armoured Car

VEHICLE table

This identifies the different vehicles that the organisation may use for shipments. An individual vehicle may be used in an number of different dispatch events.

Advance Shipment Notifications (ASNs)

When a purchase order is raised on a supplier nothing else happens within this system until the goods arrive as part of a supplier receipt. However, it is possible for a supplier to access this system via a Supplier Portal in order to perform the following:

• Acknowledge receipt of the purchase order.
• Update the status of each item on the purchase order. This information will also be available when the associated sales order is queried.
• Prepare a shipment to the requesting organisation. Each shipment will have one or more packages, and each package will contain one or more items.

The supplier-generated shipment record is known as an Advance Shipment Notice/Notification (ASN) which can be used as source data when the organisation actually receives the shipment. This will save having to key in the shipment details manually.

Figure 7 - Supplier Portal

SPLR_SHIPMENT (ASN) table

The supplier can generate one of these when preparing a shipment of goods back to the receiving organisation in response to a purchase order. After creating an ASN record the supplier can create one or more package records, then for each package he can identify the items that are contained within that package.

Note that the supplier may have his own shipment numbering system which is independent of the number sequence used by this application. This number can be entered so that it can be tallied with the identification on the supplier's documentation.

When the shipment is actually received by the customer this document can be used to create a Supplier Receipt.

SPLR_PACKAGE (ASN) table

Each ASN will contain one or more packages, and each package will contain one or more items.

Note that the supplier may have his own package numbering system which is independent of the number sequence used by this application.

SPLR_PACKAGE_CONTENT (ASN) table

Once a package as been created it will be possible to log which items have been included in that package. Only those purchase order items which have been marked as "Awaiting Dispatch by Supplier" will be eligible.

Returned Material Authorisations (RMA)

Sometimes after receiving an item a customer may wish to return it, either because it is the wrong product, does not work, is broken, or there is something else wrong with it. It is usual practice for the customer to contact the organisation's customer services department beforehand in order to report the problem and request an RMA number. Sometimes the organisation may arrange to collect the item free of charge, or provide a freepost address so that the customer does not have to pay to return the item. Some organisations will not accept returns unless they quote a valid RMA number. It may also be company policy to send the customer a pre-formatted label which has to be attached to the product before it can be returned.

It is also possible to generate a Credit Note for the returned item.

Figure 8 - Returned Material Authorisation

RETURN_MATL_AUTH_HDR table

This identifies the RMA number and RMA date for items which are to be returned for a sales order. The items are specified on the RETURN_MATL_AUTH_ITEM table.

RETURN_MATL_AUTH_ITEM table

This identifies the items from a sales order which are to be returned, along with the quantities and reason.

RETURN_MATL_AUTH_STATUS_HIST table

This keeps a history of all changes in the status for an RMA.

Initial Values

There may be cases where a transaction requires user input and a particular value or values remains constant for all instances of that transaction. In order to avoid having to manually input the same value(s) each time the transaction is run it is possible to define each of those values in the database and have those values automatically included in the user input. For maximum flexibility the following tables in the MENU database are used:

Here are some typical cases:

Date created: 22nd August 2007

Amendment history:

Copyright © 1999-2024 by Geoprise Technologies Licensing, All Rights Reserved.