A New Way of Managing Goods: The Entity Management System and its Rules, Description, and Benefits

Entity Systems has developed a new method of managing goods within and between warehouses.  It is called the Entity Management System and has a huge potential to change how ESG and Sustainability information is created and managed.  The method can replace the Inventory paradigm and product serialization, and enables greater stock visibility, improves returns processes, and increases the metrics available for decision makers.  It can handle a number of current and upcoming sustainability requirements, including the DSCSA, EU Falsified Medicines Directive, the EU Digital Product Passport, the EU Farm to Fork program, and SEC Carbon Emissions Scope 3 reporting.

ABSTRACT

Goods are normally modelled in an information system according to the ‘Inventory’ model of reality.  Each individual unit is tallied according to its type (such as its Stock Keeping Unit – SKU), with the sum of these tallies being the total amount of goods in a specified location.  Here a new model is proposed where any ‘thing’ in the real supply chain world is given a proper name and modelled with a corresponding folder in an information system.  These can be items or containers, like a garment being sold, a soft drink, a box, a pallet, a truck, a warehouse.  These are all termed ‘Entities’.  The folders representing these Entities are nested within one another in a manner analogous to the real world.   The classification and additional information about each Entity becomes an attribute of the Entity, this information is not contained within its name.   

Adopting these changes has a number of benefits for the company using the system, and the supply chain as a whole.  As each unit of product is received, it is individually tracked and thus the velocity of each unit through the facility is known, and statistics can be assembled on this data.  All the current traceability requirements in typical supply chains can be met, such as Country of Origin, Batch/Lot traceability and serialization requirements.  Unlike data stored in the Inventory model, adding more attributes to an item is much easier, as it is simply added to file(s) in the folder representing the item and strict data mapping is not required.  This additional data can be sustainability / ESG information, like more information about the provenance of an item, the emissions attributed to an item, repair manuals or end of life information.  Another bonus is that as each Entity can be labelled with its own name, the necessity for barcodes issued by a central agency (GS1) is no longer necessary at the retail level.

This work describes the conceptual framework of the Entity Management System and how it can be applied in a Warehousing / Distribution Environment or a Transportation Environment.  This is based on the work of applying an Entity Management System in a small e-shop warehouse.  The concept lends itself well to issues that are facing the supply chain today, a desire for more visibility of operations by businesses, and providing more sustainability information as increasingly requested by consumers, regulators, and investors.

PART 1: INTRODUCTION

This paper will begin with a short description of how the current Inventory paradigm functions, to set the stage for the second part which will describe the Entity Management System (EMS) in detail.  The rules of the EMS, its components and how it classifies goods are described.  Then, to bring these concepts a little closer to reality, a detailed description of how the EMS can be implemented in both a warehouse and a transportation company is described.  After the functionality of the system is established, some of the differences between the Inventory paradigm and an EMS will be highlighted.  An understanding of the requirements of traceability is necessary as well, and so current and upcoming traceability requirements in the supply chain, concentrating on the European context are described.  A summary of how the EMS can meet some sustainability requirements is also outlined.

1 How Inventory Management Works

The Stock Keeping Unit (SKU) is this standard way of classifying goods that are of interest to a company.  All transactions, including sales and financial transactions are recorded according to the ‘SKU’, and the quantities of units assigned to that SKU. 

1.1 The History of Inventory

2. What is a Warehouse Management System

A Warehouse Management System (WMS) is an application that allows for workers in a Facility to record movements of goods, directs them to move goods if necessary, provides reporting information, and can communicate with other company software to report on the status of stock.

The specific actions that a WMS manages:

• Receive and Putaway goods
• Manage locations of goods
• Direct workers to fill and ship orders
• Maintain a record of goods on hand
• Do this in real time, manage all processes in the warehouse and communicate with other company systems[1]

While both Inventory Management Systems and Warehouse Management Systems are concerned with the goods that are in a company’s possession, a Warehouse Management System is more concerned with the goods at the operational level, while the Inventory Management System has a holistic view of the goods that are on their way into the Facility, what in in the Facility, and what has been sold. 

PART 2: THE ENTITY MANAGEMENT CONCEPT – RULES AND KEY PROCESSES

Simply, an Entity Management System will be able to do everything that an Inventory Management System is capable of, plus have the capability of tracking every Entity, individually. 

An EMS is capable of managing a record of all goods within a business with the same capabilities as an Inventory Management System of tracking, identifying, and storing information about all the possessions within a business.  However, additionally, the EMS is capable of tracking each of these items individually in a way that greatly reduces errors about the accuracy of the business’ goods.

The EMS can claim to:

• Provide an easy, universal method of identifying and tracking items, cartons, and other discrete, sellable entities individually
• Allow for information about each unique Entity to be transferred as easily between organizations as the Entities themselves are physically moved
• Store information about the Entities in a way that reflects their real-world status in relation to other Entities (for instance: items in cartons on pallets in a storage rack in a warehouse)
• Can be used to report on and monitor a company’s assets and activities

Using this process can be useful for any party that possesses goods in the supply chain and then passes them on to someone else.  The Entity Management System can form the basis of a complete Warehouse Management System, with hundreds of users and multiple types of containers (e.g. pallets, totes, cartons, etc.) being located, ordered, processed and tracked.  All of these actions in the warehouse can be fulfilled by the EMS and all these actions take place within the 4 walls of the warehouse.  The EMS can receive any type of inbound good, receive it, store it, receive an order, assemble it, and ship it.  But do all of this while maintaining information about the item, for the final customer.

3. Structure and Components of an Entity Management System

In the same way that an Inventory Management System has concepts of Stock Keeping Units, line items and inventory buckets to maintain its model of reality, the EMS has its own concepts that help maintain a coherent data model of the physical world.  This section will briefly introduce and define each of the necessary components of the model behind the EMS.

3.1 Defining and Naming Entities within an Entity Management System

An Entity in an Entity Management System is any item or container comprised of one or multiple items that is produced and further handled together.  This is a very broad definition, but Entities are in fact much easier to understand than the concept of a ‘product’.  For instance, Entities can be Items that are offered for sale as the unique item that a consumer can buy.  Entities can also be containers, which are made up of items and / or other containers that are packed or assembled together. 

Each Entity that is identified within an EMS must have a name.  This name must be a ‘proper name’, and as such it does not include the classification of the Entity.  So, the name of the Entity cannot be its Stock Keeping Unit plus a number, it must be a name that does not have any particular meaning.  This separation of the name of the Entity from its classification is the second key component of the EMS.

Entities must have a name that is unique.  For the purposes of an EMS, this means that each Entity must be unique in relation to that particular EMS.  Entities that do not move between different EMS’ can have a code that is locally unique, but not necessarily universally unique.  Entities that are expected to be moved and transferred to different businesses need to be universally unique.  For example, a shelf location (which is an Entity) in a warehouse can be named ‘A01’ as it will never leave the warehouse, and this name can be used in multiple distinct warehouses without any issue, as long as it is unique in each warehouse.

3.2 Utilizing Universally Unique Identifiers for Entities

Universally Unique Identifiers (UUIDs) can be used for assigning unique names to the Entities that will travel between businesses.[2] 

Dwelling on how unique a UUID actually is, and whether it is truly unique is not necessary.  Most UUIDs will be ‘unique enough’ to avoid naming collisions between different businesses, especially when utilizing the unique MAC address of the generating machine as part of the hashing program that creates the UUID.  In the rare event of a duplicate, this duplication would be identified during the receiving process and remedied operationally by renaming the duplicate Entity.  If this happens, a lottery ticket should be immediately purchased by the person who found the duplicate Entity.

In addition to UUIDs being used as identifiers, other universally unique names can be used, including Decentralized Identifiers (DIDs) whose origin can be verified[3].

Also, it is only through the use of UUIDs that it is practical to use an Entity Management System.  Creating unique codes without computing power would be impossible on a larger scale and it is this ability that makes an Entity Management System a feasible alternative to an Inventory Management System.

3.3 Folders representing Entities in a Hierarchy

The traditional Inventory Management System maintains different types of inventories within tables.  Each row in a designated table holds a unique type of product, a Stock Keeping Unit.  When a unit of product is sold or otherwise removed from the system, then the quantity of that SKU must be reduced by the appropriate amount.  Conversely, when units are added to the system, then a count is added.  When the Inventory Management System is applied to computers, then it lends itself nicely to the use of databases.  Commonly, a database table is created to hold some of this Inventory, and appropriate adjustments are made through various programs which can be in written in a variety of computing languages and often interact with the database tables using the ubiquitous SQL language.

The EMS sits on a fundamentally different principal.  The reader will likely be aware of the file system on their computer.  You can save a file, within a folder, and have this folder organized within other folders based on your need for organization (or not).  Imagining a physical system of boxes and items within boxes is quite similar.  There are boxes that sit on a shelf and these boxes have items within them.  In the same way, you can have a virtual representation of the Items (folders in your computer) within boxes (represented by a higher level of folders), on locations (represented by an even higher level of folders).  This would be a level of detail that is not very necessary for the Mesopotamian accountant but is appropriate for an ecommerce retailer who receives 30% of the goods that they ship out back as returns. 

The difficulties of a hierarchical database system, or nested database system are well documented[4].  For example, using a nested set model can overcome some of these difficulties but are inherently complex[5].  Meanwhile a file/folder system is easy to understand and holds the additional advantage at the structure of the data organization gives the user information about the physical reality of the Items and Cartons themselves.  In the physical supply chain world, items, boxes and other containers are almost always organized in a hierarchical manner, rather than in piles of organized wheat as in the past, or for some bulk goods.  Modeling all Entities in a system using a flexible hierarchy data system like a file / folder system can function for the purpose of maintaining records of stock.

3.4 Entity Management’s Model of Reality

3.5 Companies as Functional Entities

The term ‘Entity Management’ does exist and generally refers to business entities and the processes and documents defining those legal ‘Entities’.  For example, this Capterra page references software that can used for managing legal Entities.  Each business is at the same time an ‘Entity’ as defined above.  To distinguish between the legal ‘Entities’ and the definition of a business ‘Entity’ used in this document, the term ‘Functional Entity’ will be used.  Functional Entities are distinct businesses and can be recorded as such within an EMS.  These could be vendors that provide goods, carriers, or platforms where goods are sold.  These Functional Entities need to have a unique name in the EMS and associated information kept about them, like addresses or other characteristics. 

Functional Entities can also have a unique URL (i.e. domain or subdomain) that uniquely identifies the Functional Entity.  This is not a mandatory requirement but can help to uniquely identify the business among others.

3.6 Classification of Entities into Entity Type

In order to work with Entities in or between facilities they must be characterized into Entity Types.  Entity Types are groups of Entities that share taxonomies of classifications.  So let’s take a small warehouse as an example, which fulfills products for two distinct, unrelated companies.  This warehouse would use an EMS, which would classify Company ‘A’s goods into Entity Type ‘ItemA’.  Company ‘B’s goods are classified as ‘ItemB’.  The warehouse has its own boxes which can be used to pack both company’s orders, and are classified as Entity Type ‘Cartons’, which go on Entity Type ‘Pallets’, which are grouped into Entity Type ‘Shipments’, which go on Entity Type ‘Trucks’.  Each Entity Type has its own set of taxonomies, which is not shared with other Entity Types.  So ‘ItemA’ Entities can be classified according to Company A’s requirements, like Product SKU, Color, Size; while Company B’s requirements will be separate from them.

Entity Types which we do not typically associate with having a classification can have one added if needed.  For example Cartons can have taxonomies based on requirements of the warehouse, for instance a ‘Carton Type’ taxonomy, or ‘Carton Height’ taxonomy. Some common Entity Types that are likely to be used in warehousing or transportation are:

• Items
• Cartons
• Pallets
• Shipments
• Users
• Locations
• Vehicles

3.7 Using Inventory when it makes sense

There may be instances were designating an Entity just isn’t possible because of the end sale of loose goods.  In this case, the Entity itself can have an inventory, as it can be composed of several sub-units.   An example of such an item may be a box of with several weight units of fruit. In this example, sub-items may be pieces of fruit or weight units of fruit.  At the place of the final sale, or during re-sales, the item may be consumed in several steps, with the Entity Inventory being consumed.

3.8 How an analogous ‘4 Wall Inventory’ is maintained

Inventory management systems usually have a strict definition of what is inside the four walls of a facility.  They may have more than one ‘bucket’ or ‘table’ that contains what is ultimately inside a physical building, but there is a single version of the truth of what is in one place, and this rule is useful for purposes of allocating stock within a warehouse, and for generally knowing what assets are being held. 

In the same way, the EMS will manage this requirement by having one folder that holds the truth of what is within the warehouse.  So all stock that is in legal possession of the facility is located in this one folder that holds the model of the physical world.  There may be other folders outside of this ‘possession’ folder that hold records that are items that are expected to be received, or have been shipped, but the ‘possession’ folder will hold the truth of what is within the facility.

3.9 Labelling Entities within and between Systems

There are 3 options for labelling any Entity, and the decision of which to use, or which combination to use is determined by the decision makers for the business.  The label may have the form of, for example, printed text, a 1D barcode, a 2D barcode or an RFID tag.  These labels are used within the EMS to move Entities from one Entity to another.  The three options for labelling are to:

1. Use the unique entity code itself on each of the Entities in its possession
2. Use the URL of the Functional Entity plus the Unique Entity Code
3. Use a taxonomy of the Entity type (e.g. a Stock Keeping Unit / EAN code)

Choosing between the three options depends on the goals of the organization.  If using a 1D barcode, then option 2 will likely not work because the text will be too long to encode.  If using a 2D barcode, than any of the three options are possible.  Any of the three options are possible with an RFID tag.

There are pros and cons of using each of the three labelling methods. 

	Pros	Cons
Unique Entity Code	Can easily transfer the Entity between different functional entities and still refer to it.	Final Consumer needs to navigate to website first, then to the Entity page
URL + Unique Entity Code	Final consumer can easily find information about the Entity with one click	– Cannot use 1D Barcodes – text too long – When transferring to different downstream Entity they must relabel
SKU / EAN	Easy to integrate with legacy systems as this is how Inventory Management Systems work	– Easier to make mistakes – Programs and processes are more complicated within a facility

Regardless of how the Entities are labelled when assembled to be shipped or transferred to the downstream party in the supply chain, the informational model exists which can always provide the additional information about the Entity which is not supplied in a traditional Inventory Management System.  For instance, this additional information can be added to a customer invoice in regards to the specific Entity (or each piece within each line item).  

3.10 Entities within a Bill of Materials

An Entity can also act as a component within another Entity and be ‘consumed’ into that Entity.     This is an Entity that will be used within the facility for processing and won’t be sold further through the supply chain.  When a Component Entity is processed and used within another Entity, then the information about the provenance of the ‘component’ can be added to other Entity, for the capability of fully tracking goods throughout the supply chain.    While out of scope of this work, components can be seen as the instances of goods that are included in a Bill of Materials. 

4 Moving Goods into and out of an Entity Management System

4.1 Folder Structure for Receiving and Sending

Various actors in the supply chain (Facilities) have different requirements.  The requirements of a Truck are going to be quite different from that of a Warehouse.  But the fundamental concepts of receiving something into an Entity’s possession, perhaps reorganizing it, and then sending it out again are the same.  Typically, the items within a shipment will not be re-organized during the truck’s trip so the goods that are taken into possession are the same as those which leave the truck.  So for a truck ‘Facility’, the three folders suffice to maintain a clear distinction between Shipments to be picked up, Shipments on the truck, and Shipments delivered. 

A Warehouse is different, as the goods that are received are taken apart, organized, assembled into orders and then shipped out again.  For this reason, a meticulous record must be kept of the condition of the shipments when received, and when set.  Otherwise, information about the condition of the goods when received and sent will be lost.  A process exists for how to maintain this record during the receiving process, and this will be described.  To maintain these records, evidence must exist of which goods were received (the ‘Evidence’ folder) and which were expected to be received but were not (the ‘Shortage’ folder).  Additionally, outbound shipments are archived in the ‘Expedited’ folder.   As seen in the diagram, these three folders must be contained in an Archive separately from the three core folders.  This is because the Entities within the three core (‘Entities’) folders cannot be duplicated, their uniqueness must be maintained within the ‘Entities’ folder.

Finally, the Facility folder structure can be modified to reflect operational realities, including having an ‘Expected’ folder at a different hierarchical level.  For instance, in a transportation company, the ‘Expected’ folder could exist at the level of the Transportation Company Facility, and then again at the level of the Truck Facility.  In this way the company dispatchers prepare the Shipments that are ordered by their customers and then move these Shipments into the Truck Expected folder to indicate to the Truck that they have been dispatched to pick up that Shipment.

4.2 Converting from an Inventory to an Entity Model

Moving goods into and out of an EMS requires the goods to fit into the EMS informational model.  Because the EMS models information at a more detailed level than all other Inventory systems today, this is an easy process to undertake (for a computer program).

Essentially, the line items within an invoice / bill of lading / CMR can be transformed into the individual folders within the EMS, and they will be nested hierarchically in an analogous manner to their physical storage.  This is how the process needs to work in Facilities that handle the contents of shipments, like warehouses.  For those that do not need to handle the contents, the ‘Item’ folders are not necessary, and the shipment folder can simply contain a copy of the Bill of Lading.

4.3 The Receiving Process

For warehouses, the receiving process starts with the information being transformed into folder structure as described in the previous section.  After this has taken place, the goods can be received into the warehouse by moving the folders from the ‘Expected’ organizational folder to the ‘Possession’ organizational folder to indicate that they are now within the 4 walls of the Facility.  The shipment is verified and archived for record keeping purposes.  The overall process is as follows:

4.4 The Sending Process

The Outbound method is simpler than the inbound, the containers are consolidated on a shipping location, a shipment and shipping documents are created and then this shipment is scanned out of the Possession folder into the Sent folder to indicate that the shipment was sent.    Additionally, a copy of the Shipment folder is pasted into the ‘Expedited’ folder in the Archive.  This last step is done if returns are being handled in the system.

5 Managing Orders in an Entity Management System

Normally, the complexity of the Inventory Management paradigm becomes apparent when allocating inventory.  Allocation of inventory to orders creates all sorts of complications in an Inventory Management System, especially when considering multiple locations in a supply chain, considering whether stock is actually available, substituting one piece of inventory for another, and the idea of reserving inventory that is not yet available for a particular customer.  One of the biggest advantages of the Entity Management System is the elimination of this complexity.  In an EMS, each individual unit is modeled by its folder and this individual units, whether in the ‘Possession’ or ‘Expected’ folder is allocated to an order. 

5.1 Example of Order Input

The orders themselves in an EMS are similar to a typical structure in an Inventory Management System.  There is a database record of the order created, with information about the customer, payment, carrier choice, and any other information that is relevant to that order.  However, the detail of the order is different in an EMS, as the Unique Identifier and relevant Taxonomy of each individual piece allocated for the order is listed. 

An example of how this works in practice is as follows; first, the user creates the order by selecting the customer and whether they will be selecting Entities by a particular taxonomy, or by the Entities themselves.

A blank order header is created after this and the user can either select by a taxonomy, or by the individual Entity.

After selecting the Entities for the order, they will be allocated, and each individual Entity is targeted to be shipped to the customer.  At this point, an order header exists that contains information about the unique order, and an associated table contains information about each unique Entity that is associated with that order.

6 Managing Returns in an Entity Management System

The returns process is a frequent area of confusion and inefficiency within a classical Inventory Management System.  Another benefit of utilizing an EMS is the depth of record keeping that is enabled in the area of returns.  Entities that have been shipped to customers from an EMS will have a UUID associated with them, so this UUID will be reused on the Entity’s return to the warehouse.  Also, during the process of assessing the return’s quality, the EMS enables the operation to simply re-assign a different product code if the Entity can no longer be sold as a ‘new’ Entity. 

6.1 Using an ‘Expedited’ archive folder supports managing Returns

6.2 Maintaining and adding information to Entities during the Returns process

The process of returning an Entity and processing it is depicted in the Figure below.  After the Entity has been shipped to the customer, it is found within the EMS in the ‘Sent’ folder.  This indicates that it has left the Facility.  A copy of this Entity folder has also been made into the ‘Archive / Expedited’ folder to maintain a history that the Entity has been moved.  Then the Entity is moved into the ‘Expected’ folder which indicates that a return shipment has been created.  It is then ready to be received into the Facility (for a second time).  After being received, the Entity is inspected and if it is found not to have the same level of quality as when sent, then it can be re-classified and assigned a new product classification.  However, no change of labelling is required for this to take place.  The Receipt can be verified, and the Entity made allocatable to new orders after this process, and then the process continues in the same manner as the first time that the Entity was shipped.

Throughout this process information about the vendor, dates of receipt and shipment, customer and any other information is maintained within a file in the Entity History.

PART 3: DESCRIPTION OF IMPLEMENTATIONS

The EMS can be implemented to manage stock that is within a business that deals with sellable units, like consumer or business goods.  Or it can be implemented in a business that manages transportation of goods.  Both implementations are described in this Part in more detail, especially to link the informational model to the application of this model in the real world.

7 Description of an Entity Management System as Implemented in a Warehouse

One implementation of an Entity Management System can work as the Inventory Management System and Warehouse Management System within a company that manages goods by receiving, storing, and then filling orders and shipping goods.  This can be a fulfilment centre / distribution centre / warehouse.  In this way, the EMS becomes the informational framework that keeps records of all the stock in the company.

7.1 Warehouse System – Informational System

The Facility’s organizational folders can be seen in Figure 17.  These are the Entities 17-2, Archive 17-3, Expected 17-4, Possession 17-5, Sent 17-6, Shortage 17-7, Evidence 17-8, and Expedited 17-9 folders.  These eight folders do not represent Entities themselves, however they organize the Entities contained within them.

The Entities folder 17-2 contains records of Entities expected to be in the Facility, those currently in the Facility, and those that have left.  Importantly, there are no duplicates of Entities within the Entities folder, and these are the ‘digital twin’ representation of the real-world entities.  All allocation of Entities to customers is done while the containers or items are located within the ‘Entities’ folder 17-2 or its subfolders.    Found within the Entities 17-2 folder are two more organizational folders, the ‘Expected’ folder 17-4, and the ‘Possession’ folder 17-5.

All containers and items which are expected to be received into the Facility will be created or moved into the Expected folder 17-4.  The format of the Entity folders should be as described previously in this document.  For example, within the Expected folder 17-4 there can be a Shipment 17-10 named ‘DFB09EC4-599A-4188-A346-8FB2E0FF16DB’.  This Shipment contains a Carton, represented by a folder 17-16, which can be named ‘EE9A74AE-8DF8-4979-8590-9B0CABE40EC0’.  It is expected to be received and it contains 3 items, which are represented by folders 17-20, 17-21 and 17-22. Locations, Shipments, and Cartons are all different Entity Types as described previously.

Information about the expected Entities’ origins or carbon footprint can be added to the file describing the Entity which is saved within its respective folder.  At the moment when the physical containers are received into the Facility’s possession, the folders representing the contents of the shipment are moved from the Expected folder 17-4 to the Possession folder 17-5, or directly to the specific folder representing the location (an Entity Type) within the Possession folder, in this example Location A1 17-11.  The Shipment folder is left in the Expected folder 17-4, while only the Cartons and Items are moved into the Possession folder 17-5.

The Possession folder 17-5 is the only compulsory organizational folder in the Entity, and when all the Carton and Item folders within the Possession folder 17-5 are counted, then these are all the goods that are controlled by the Entity at that moment in time.

The Archive folder 17-3 serves to keep a record of the Entities that have been received into the Facility, and the Entities that have been shipped, in the same folder structure in which they were received or shipped, respectively.  It is likely that the Entities will appear in both the Inbound and Outbound folders after being received, processed, and shipped.  Therefore, unlike the Entities folder 17-2, the Archive folder 17-3 will contain Entities that are duplicates of others that may exist in the Entity folder 17-2.  Within the Archive folder, the Evidence folder 17-8 holds a copy of the Shipment, Carton and Item folders and files as they were received or created in the Expected folder 17-4.  The Shortage folder 17-7 holds a copy of the Entity folders and files as they were created in Expected folder 17-4 but were not received into the Possession folder 17-5.

For example, Shipment 2FE99FC3-B75C-45C6-9FB6-3B6BCA926E39 17-14 was received into the Entity in the past because its folder is located within the Evidence folder 17-8, and Carton folders 3EDC68FF-E5F5-4891-8B9C-F4637D697198 17-14 and 17-17 are located in both the Inbound Evidence 17-8 and the Possession folder 17-5, respectively.  Additionally, the same Shipment 2FE99FC3-B75C-45C6-9FB6-3B6BCA926E39 17-13 is specified in the Shortage folder 17-7 and contains the Item C5E9C60A-61E7-49F9-B810-5440C8CA2F89 17-19, which means that this Item 17-9 was expected to be received but was not.  By utilizing the different organizational folders, the Facility can identify and record which containers and items were received, are available, and were expected to be received but were not.

Finally, when Cartons and Items are shipped out of the Facility, they are first copied to the Expedited folder 17-9, and then moved to Sent folder 17-6.  From Sent folder 17-6, Entities can be made accessible to other Facilities that request information about them and could be downloaded as a zipped folder.  The example of this is Shipment 429C8EED-3D40-464D-86A9-0024D1BE0824, a copy of which can be found in both the Sent folder 17-6 and the Expedited folder 17-9, as folders 17-12 and 17-15 respectively.

7.2 Warehouse System in the Physical World

The model described in Figure 17 depicts the entire folder structure that can be encountered in a typically Entity Management System.  However, it is the model of reality found within the detail of the Possession folder which shows how the EMS will work operationally Figure 18.

The Possession folder 18-10 contains the Entities that are under control of the Facility.  Within this folder, the folders representing Entities are organized to be analogous to their real-world physical relationships.  Figure 18 depicts how these relationships are represented.  The physical reality 18-1 is a warehouse 18-3 that contains three locations: 1A (18-4), 1B, and 1C.  On location 1A 18-4, a Carton 18-5 can be found, which contains two widgets 18-6.  The folder structure representing these elements is an informational model 18-2.  The folders representing the contents of the entire warehouse are found within the folder representation of the warehouse, specifically the Possession organizational folder 18-10.  There are three folders representing Entities within the Possessions folder.  These Entities are locations such as the Location-1A folder 18-11.  Within the folder 18-11 representing Location 1A, there is a folder 18-12 representing the Carton Entity.  Within the Carton folder 18-12 there are two folders 18-13 which represent the items.  Within each Entity’s folder, there is a file 18-14 that describes the Entity history, the classification of the container or item (its taxonomy), and any other information that the Facility wishes to specify about the Entity.  The name of the file 18-14 is just the Entity’s Unique Identifier, while the folder name is prepended with the Entity type, such as ‘Location’ (for 18-11) or ‘Carton’ (for 18-12), or ‘Item’ (for 18-13).  In this way, the structure of what is being represented is much clearer to the user, and the classification of the Entity can be easily ascertained.  Additionally, each Facility’s implementation can define a system of rules where some Entity Types cannot be contained within others, so that the real-world reality is not accidentally modified by persons using the system.  For example, rules can be created that an Item cannot be located on a Pallet but must be placed in a Carton.  Other examples include: A Location cannot be placed anywhere except the Possession location; or a Pallet cannot be placed in a Carton.  During Entity operational moves, these rules can be validated before the program allows for a move to take place.

The contents of the file designating the container or item can be a file that contains key/value pairs that contain detailed information about the Entity.  Importantly, there can be information about the Entity’s taxonomy, that is how it has been classified.  This is done for allocation of the Entity to customer orders, and for reporting purposes by to ascertain the amount of Entities that are currently in various locations in the Facility.  There can be information about the Entity history, for instance who handled the Entity in the past, the environment or carbon impact of the Entity and anything else that the Facility wishes to share about the Entity.

8 Description of an Entity Management System as Implemented in a Transportation Company

The same concepts found in one Facility of an Entity Management System can be applied to any transportation-based business, be it a Truckload operation, Less Than Truckload / Groupage, Courier or postal service.  For these applications, the internal workings of the Entity Management System are not the focus, as they do not take apart and reassemble the components of Shipments (Entities).  Transport companies need to focus on the transfer of information into, and out of each Facility.  For example, an EMS can be used by an independent truck driver, who would have a basic version of an entire EMS, which would be able to pickup a delivery, drive with the order to the destination (the shipment Entity in their possession folder) and release this shipment from their possession (the delivery).  The figure below shows the types of industry players that could conceivably standardize their operations by adopting EMS to manage their businesses and communications with other parties in the supply chain.

8.1 Transportation System – Informational System

Figure 20: Example Informational System in a Transport Company depicts the Entity folder structure in a transportation company that operates two trucks that can pick up and deliver shipments. 

One significant difference in this system as compared to the warehouse system is that most of the organizational folders are not located at the level of the Facility 20-1 but are located within the folder structure of the folders 20-2 and 20-3 representing the trucks.  The trucks are an Entity Type.  Nested within the Truck’s folder the organizational folders that we will recall from the previous example, the Expected 20-5, Possession 20-6, and Sent 20-7 folders.  Notice that there are no Archive, Evidence, Shortage or Expedited folders.  These archive folders are useful in cases when the contents of the Entities (the Shipments) are taken apart within the Facility and re-packaged for customer orders.  This does not typically happen within a truck.  Also, there is an additional Expected folder 20-9 that is nested at the level of the Facility.  This is because the transport company will receive requests for movements that their trucks must perform these requests must be stored somewhere before they are assigned to a particular truck to perform.  When a dispatcher in the trucking company decides that Truck 2 20-3 will be the truck that will perform the work required to deliver Shipment E1C59B71-D4D0-4452-BC8C-4476EF826433 20-10, represented by folder 20-9, then the dispatcher will move this Shipment folder to the Truck’s Expected folder 20-8.  Then, when Truck 2 picks up the Shipment from the Shipper, the Shipment will be moved into Truck 2’s Possession folder 20-9.  More often than not, a transport company does not have detail about the contents of a Shipment, and that is ok.  For instance, the Shipment can be described with nested folders like 20-12, with a Shipment folder, Carton folders 20-13 belonging to this Shipment, and the Item folders 20-14 contained within the Carton folders. Alternately, the Shipment folder, like represented in folder 20-15 can contain a packing list which is provided by the shipper and contains only some information about the contents of the shipment.

8.2 Transportation Embodiment in the Physical World

The physical reality of the transport company 21-6 can be depicted as an office 21-3 and two trucks 21-4 and 21-5. The Facility’s records 21-6, which can be analogous to the office 21-3 contain all the folders representing Entities for this Facility.  Truck 1’s folders 21-7 are located within the Facility records 21-6.  Within each Truck folder, the organizational Possession folder 21-9 is located, as well as the Expected and Sent folders (not shown in Figure).  The Truck 1 folder 21-7 contains one Shipment folder 21-10, which consists of a single Pallet folder 21-11, in which are two item folders 21-12 and 21-13.

PART 4: COMPARING INVENTORY AND ENTITY MANAGEMENT SYSTEMS

Now that we have an understanding of how the Entity Management Model works, we can compare in detail the differences between Inventory and Entity Management Systems.

9 Summary of Differences between Inventory and Entity Management Systems

The following table outlines the major differences, and advantages, of the Entity Management System when compared with an Inventory System.  However, this section begins with the observation that both systems are in fact models of the reality of the supply chain.

	Inventory Management	Entity Management
Purpose	Models the reality of stock within a business	Models the reality of stock within a business
Naming	Goods are named according to their classification	Each Entity (referent) is given a Proper Name
Preventing Collisions between Identifiers	Receive identifiers from one organization – GS1 organization	Uses Universally Unique Identifiers
Information storage	Relational Database – Tables holding counts of a unique product	Individual files containing classification and other information about each item
Counting Goods	Counting and Maintaining ‘Buckets of Inventory’	All entities within the ‘Entities’ folder can be counted
Location of stock	Held in additional field in table representing containers or locations (or multiple tables)	Shown by the location of the folder in the file structure
Transferring Goods between parties	Creating a list of the items / boxes and their quantities	The folder containing all containers and items within it is copied and transferred

9.1 Inventory is a Model of Reality

Current writings, industry discourse, academic texts that are concerned with Inventory all omit an important truth.  Inventory is a model of reality, not a representation of reality itself.  Meaning that Inventory is not the reality of the physical items that exist in a supply chain, it is a representation of those physical items in a model.  Similarly, a model of today’s weather will not be the same as actual weather that you experience.  This is an important point as current textbooks and methodologies do not explicitly mention, or even allude to the fact that the stock in a Facility is being modeled by the Inventory concept.  

In the same way, the Entity Management System is also an abstraction of reality, but it models reality with the file and folder concept.  By recognizing that the existing paradigm is a model, and that companies can simply choose a new way to organize their goods, allows for a lot more flexibility in choosing how to store information about their goods.

9.2 Goods are currently ‘nameless’

A key innovation of the Entity system is that it names Entities uniquely.  John Stuart Mill defines Proper Names as “a word that answers the purpose of showing what thing it is that we are talking about but not of telling anything about it.”[6]

From this definition we can see that in the inventory paradigm, proper names are not used to define and label stock.  A SKU refers to any number of goods, it is a classification of stock.  Indeed, the urge to name goods by their characteristics is so strong that even when Inventory systems do track individual items (mostly in the pharmaceutical industry), the label of the item includes its characteristics and only suffixed with an integer is unique only for the particular product (serialization process).  An example of this is the GS1-128 Barcode that is used in the Pharmaceutical Industry.  The GS1-128 standard includes the ability to label stock with a barcode that contains data about the item.

The Entity Management System takes the intellectual leap of naming items uniquely, and then storing the classification of the items as an attribute of the record of the item.  By separating the item name from its classification, the system becomes simpler and more capable.  For instance, benefits of this change include:

• The ability to receive items without knowing their classification and classify them after they are stored.
• No need to re-label items that have been returned if their quality is different from the first time they were sent.
• Sell and re-sell items down the supply chain and no one has to re-name them, even if they do change the classification for those items.
• Maintain a record of the provenance and CO2 emissions of the individual item.  This can be used for ESG purposes and be communicated to the final consumer.

9.3 Recording Stock Locations

9.4 Entity Management Model Enables Easy Transfer of Information between Parties

The transfer of goods between parties today usually involves the transfer of the goods themselves, plus an acknowledgement of the condition and quantity of goods transferred.  Often, a packing list is printed on a piece of paper and checked off by the two parties.  Finally, a transfer of ownership and / or liability is done with a Bill of Lading / CMR and usually both parties sign this document. 

The creation of this document is usually done on a customized basis by the inventory program of the sender, and the items and their quantities can be listed, or the containers that the items are contained within are listed.  The complexity of this step, and the difficulties of standardizing this process should not be underestimated.  For instance, if you have 5 pallets, each with 20 boxes, and each box has about 10 units of inventory, for a total of 1143 units, how do you itemize this list?  It depends on the industry and relationship between the sender and receiver. 

With an Entity Management system, the preparation of documents for transferring becomes extremely simple, and more importantly, standardized.  The 5 pallet folders, which each contain 20 box folders, which each contain folders depicting the amount of items that are contained within the particular box.  These folders can be moved from the sender to the receiver computer, and with this transfer of folders, all the information about the origin of the goods, and any other information that the sender wishes to pass down the supply chain is transferred. 

10 New Metrics Enabled by Entity Management

The EMS allows for a number of new metrics that which can allow for deeper analysis of the operations of a business.  The possibility of drilling down in data to the sold Entity and connecting this Entity to the inbound shipment and vendor opens up a variety of possibilities of insights into the operations and sales in the business.  Additionally, the unique property of an EMS, assigning each Entity a proper name, allows for new metrics to be developed in the area of Returns.  Also, because an EMS is a more detailed model of stock than the inventory model, data can always be aggregated, and current metrics calculated.

To examine the metrics that are enabled by the EMS, we can use the example of a hypothetical distribution company.  The company has records of 100 Entities, from 3 different vendors, received over 6 inbound shipments over the course of a year.  These 100 Entities are ‘shipped’ randomly between 1 and 180 days from their receipt.  The products are sold with a 60% markup from the purchase price from 2 of the vendors, and the third vendor sells the same products at a higher price.  This is a highly simplified company but we can use this data to illustrate the potential of EMS driven metrics. 

Link to Example Data

10.1 Measuring the Velocity of Stock

How quickly does stock move through a company?  Inventory Turnover is one current metric that simplifies the speed at which inventory is purchased and sold.  It is used to show the strength of sales of a company, and its value differs based on the industry and types of goods. 

Equation Source[1]

The Inventory Turnover ratio can be elaborated upon by in an EMS by using the ‘dwell times’ of Entities in an EMS.  Because the EMS monitors each Entity separately, we can calculate the ‘Dwell Time’ of each individual Entity, and then calculate statistics based on this distribution of dwell times. 

These individual Dwell Times can be combined to summarize the volume of stock that is in a Facility.  This can be visualized in a chart similar to a Gantt chart where the dwell times of each item are shown together in a chart over a time period.  In Figure 24: Depictions of Dwell Times, the different colours indicate the vendor of the goods. 

Now that we can calculate the amount of time each individual Entity is in the facility, we can handle this as a distribution of data and calculate various statistics on the amount of time spent in the facility by all Entities, and compare this to other attributes of those Entities, like the cost, margin earned, vendor, etc.  Statistics on the example data provided can be seen in Figure 25: Example Descriptive Statistic of Dwell Times.

In addition to having statistics on the average amount of time that Entities are in the Facility, we can also determine which Entities are in the Facility for longer than normal (for instance, longer than 3 standard deviations), and then take action to identify why these Entities are still in the Facility.  Also, having this metric offers a new opportunity for 3PLs to charge for their services in a new way, and billing for the dwell time for storage charges.

The sum of the value of Inventory that is held is used as a metric of how much Inventory there is in the business.  This is a snapshot of Inventory at one time, typically at the end of the month.  In contrast, the Dwell time of all Entities over the course of a period of time can be easily quantified using the sum of the Dwell Days in a Facility.  This sum of the time that is spent by Entities within a Facility and can be compared to the Cost of Goods statistic, as depicted in Figure 26: Comparison of Cost of Goods Inventory and Dwell Days.  The total Dwell days can be seen to be a more accurate statistic than the Cost of Goods as it reflects amount of goods in the Facility over all days, not just an averaged end of month statistic.

10.2 Profit per Item

It is common for both purchase and sale prices of goods to vary, and to vary over the time period within which those same goods are purchased and resold.  The dynamic nature of prices means that Inventory systems use estimates and averages to determine both the Cost of Goods and the profit earned on each item sold. 

Theoretically, if a strict First-in-First-Out policy is followed then the cost of the products sold at a particular time could be determined.  But as tracking individual Entities is not possible in most Inventory systems, it is also not usually possible to attribute the purchase of a particular Entity from a vendor to a particular sale to a customer.  This lack of visibility in the history of the Entity means that the actual cost of goods sold during a period is in fact the average of the costs of the goods purchased in some time period. 

With an EMS, a lot of clarity can be gained on the profitability of a particular Entity.  For instance, Table 3: Breakdown of Cost and Margin earned by Vendor shows the breakdown of cost and margin earned through the sales of goods by vendor.  These statistics are not possible to compile in an Inventory system.

Vendor	Sum of Cost	Sum of Margin	% Margin
Bruknapp Clothing	€ 659	€ 395,4	60%
Premium Clothing Mfg.	€ 430	€ 146	34%
Reliable Manufacturing	€ 591	€ 354,6	60%

Additionally, the impact of the ‘more expensive’ vendor on overall profitability can be seen in Figure 27: Impact of Purchase Price on Margin Earned.  After the receipt of the shipment from the more expensive vendor in August, the impact is seen until the end of the year in the percentage margin figures. 

Other areas in the Facility where the detailed visibility into profitability could be useful is to attribute costs of operations on the item, to that particular Entity.  This is especially relevant in an omni-channel warehouse where orders are filled for wholesalers, retailers, and direct ecommerce in the same facility.  But there are different handling costs for each type of channel.  Tracking the costs of operations on each Entity can show the true differences in channel profitability. 

10.3 Returns Statistics and Total Costs

After this type of information is added to the history of the cost and profitability of the Entity, it can be added to the statistics that describe the sale of all Entities in the Facility.  The opportunities for digging deeper into these statistics to improve profitability is exciting.  Suppose that returns are higher from some vendors than others, or after being processed in a particular facility, or at a particular time of day.  The history of these Entities can be cross-referenced with any number of other attributes of the Entity, and this could greatly speed up how processes in a business can be improved. 

11 Stock Accuracy is Drastically Improved

The structure of the EMS information system dramatically improves the accuracy of record-keeping.  There are several reasons why ‘Inventory’ inaccuracies will be minimized:

• Math errors can no longer lead to losing Inventory (like scanning an Entity twice)
• Standardized manner of handling allocating goods before they are received
• Negative Inventory is not possible
• Pre-packaged Inventory / sale of ‘sets’ handled in a far superior manner

Working with databases can lead to math errors impacting the accuracy of stock counts.  For example, a crash of a program that removes stock from one location in a warehouse (like a physical shelf) and moves it onto another location (like a cart that a worker is pushing) can cause the worker to perform the same action twice, leading to more Inventory being in the shelf location physically than there is in the computer system.  These types of errors are usually fixed in systems, but often a ‘check’ of a physical location involves scanning the SKU barcodes of the same product, to count how many such items exist in the location.  There are methods to increase the accuracies of these ‘cycle counts’ but they can still be incorrect.  An EMS, as it keeps track of every Entity as a unique code, does not have these issues.  The users in the Facility are forced to scan the unique code of each item, which should resolve these issues.

It is common for some inventory systems to allow for ‘negative’ Inventory so that stock can be back ordered from vendors and then immediately resold.  This allows for a lot of potential mistakes (if the order is cancelled, partially cancelled, inbound goods don’t arrive as expected, etc.)  ‘Negative’ Inventory can also occur during operational errors in a distribution facility. 

The EMS allows for goods that are ordered to be allocated before they arrive into the Facility, so that the potential for negative Inventory is minimized, and by its very nature of describing the stock as files instead of numbers in a table, it is not possible to have a ‘negative’ file or folder.

Pre-packaged goods ‘pre-packs’ that can be sold either as a ‘set’ or as the individual items contained within the ‘set’ are often hard to describe in Inventory systems.  This is because both the ‘set’ and the items within the set must be described as a different product, as they have a different price.  However, when the ‘set’ is sold, then the inventory must be reduced from the individual product as well.  But how are the costs and margins calculated?  Every different permutation of this problem must be thought out in an Inventory system and resolved. 

In an EMS, this is not an issue.  The ‘set’ will have one folder allocated to it, with a sales price associated with the ‘set’.  In the EMS folder structure, each individual bottle will have its own folder, with its own price.  These folders representing the individual bottles are nested within a folder representing the ‘set’.  When the ‘set’ is sold in the EMS, then the files representing the bottles are removed as well, reducing the ‘Inventory’.   When all individual bottles are sold from a particular pack, then the folder representing the ‘set’ is empty and can be deleted.  Both prices and ‘Inventory’ is kept up to date easily.

12 Using Entity Management to Manage Stores

Currently, goods sold in retail stores, including online, require a product identifier which is guaranteed to be unique for that product.  The reason these codes are guaranteed to be unique is because the manufacturers of goods are compelled to buy these unique codes from the GS1 organization[7] which sells blocks of unique codes to manufacturers.  Selling goods in a retail store or on a major platform like Amazon requires most goods sold to have a barcode purchased from GS1.  If every manufacturer buys these codes from one organization, then they will always be unique and duplicate codes (the same code issued by two different manufacturers) cannot happen. 

An EMS allows for codes to be generated within an organization that can be used for point-of-sale purposes within that organization, and in downstream organizations.  In effect the EMS can replace the need for purchased barcodes from the GS1 organization.  The Entity Management System can be used for Stores Management.

There are two different potential methods that can be used to utilize an EMS for Point-of-Sale (POS) transactions. 

1. Use the EMS for the POS transaction and assign the retail price within the EMS
2. Existing