Inventory Management System

Overview

The Inventory Management System or IMS controls the stock of the products sold by the Commerce. It provides the Commerce manager with mechanisms to report on the quantity of units coming in of each of the products and handle removing them when they are sold, as well as offering different forms of stock control to manage the way reserve or stock provisions are handled.

These mechanisms offer different ways of working with orders where, for example, items are temporarily out of stock or awaiting delivery. With these the Commerce can, in practice, handle orders as pending (backorder) or as advance sales (pre-order). They can also implement a backordering strategy (a way of selling inventory not available to the Commerce) where an out-of-stock product will be available soon and users are encouraged to purchase by informing them of this date, or where a product has to be ordered from the supplier or made to order and users are encouraged to purchase by stating the waiting time involved.

This system is especially relevant in B2B contexts, where the quantities purchased may be large and the availability of units need to be reported in comprehensive detail. Where items are out of stock, the quantities and delivery dates of future incoming stock need to be reported and monitored to avoid selling more units than expected, i.e. to avoid overbooking-type situations.

The system also provides the tools to manage reserves automatically. Like this, incoming stock for these reserves is allocated automatically and orders can be fulfilled without any need for the Commerce manager to take action.

Stock

The stock is the number of units of a particular product. The Inventory Management System handles stock control, but as products are located in warehouses (see Warehouses and Logistic Centers), it is in the warehouses where stocks of each product are reported and where the items are withdrawn when an order is fulfilled.

In general, there are two ways of reporting on stock, depending on whether a product has options or not. If a product has no options, stock will be the number of units of this article. If a product has options to choose from, this means that the end product as sent out has certain features. For example, a T-shirt is a product, but it may come in different sizes and colors (options). The specific size and color combination, i.e. the combination of the option values, will determine the right article to be sent and therefore the article that must be in stock. If the T-shirt comes in 3 colors (3 values for the color option) and 3 sizes (3 values for the size option), the Commerce must provide for stock of all the size and color combinations (a total of 9 variants or combinations).

It can also happen that the product has options, but these do not combine, i.e. the end product is not a different article; or from a stock point of view, no different stock is needed. Usually, this type of non-combinable option is that where the nature of the article does not change, for example, an extended warranty (the values would be the different numbers of years' extension), or an option that allows choice of whether the product includes assembly or not. For these non-combinable options there is no need to break down stock; it is enough to assign stocks to the main product.

As the system is flexible, situations of poor practices can arise; e.g. a product can have size and color options, but not distinguish the final articles by specific sizes and colors. In this case, stock of the generic product is provided for, without aiming at a specific combination. This kind of management is valid —the system allows it— but it can cause problems if a specific combination runs out: the system might say that there is stock because other sizes and colors are left, but an order containing a particular size and color combination for the product cannot then be fulfilled because this combination has run out.

Life Cycle of an Order

An order has a clearly defined life cycle. The order management system or OMS controls this cycle and the associated actions. The cycle involves passing through different situations. This is discussed in some detail below, from the point of view of stock.

Shopping Cart

The shopping cart symbolizes an order that is in progress. When a product is added to it, the system checks whether there is enough stock. In a process where no reserves are involved, if there is stock, stock is added; if there is not enough stock, the system returns an error message. The stock the system reads is that of the product at that time, bearing in mind that when a product is added to the cart, stock is neither deducted nor reserved. Stock removal, i.e. the process of deducting units from the stock in the warehouses — it should be remembered that the warehouses contain the stock of the products — in the quantities shown as purchased of each of the products in an order, is carried out subsequently.

However, when it is requested to add a certain quantity of a product to the cart, the system conducts a simulated stock removal to check whether the product can be added in the quantity requested. If there is enough stock, the system adds the product in the quantity requested. If there is not enough stock, the system returns an error message. If there is no stock but the product allows for reservation (as described below), the system returns a message indicating that the product has been added to the cart but, as there is not enough stock, some units have remained in reserve. If through the simulation the system determines that to fulfill the quantity requested it is necessary to extract units that are in the form of a provision, it returns a message indicating that the product can be added to the cart, but the delivery date will have to be delayed. This is described in detail below.

The following can therefore happen: user A adds a product to the shopping cart with no problem because at the moment they do so there is stock. At the same time, this stock is removed because of another order completed by user B; when user A wants to complete their order, the system returns an error message and they cannot make their purchase. This might seem to be a problem, but doing it in this way avoids other more serious disadvantages. For example, imagine that the system removes stock every time products are added to the shopping cart. User A adds a product and causes it to run out. User B wants to buy the same product, but when they see that there are none in stock, they go to the competition instead. User A did not in fact want to buy it at that time (they might do so another day). Result: The Commerce loses a sale because B has gone somewhere else, the stock of this product is "suspended" until A decides whether to complete their purchase or not; if A empties their cart and the stock is returned, the Commerce may already have restocked and perhaps spent money unnecessarily, and so on.

To avoid this, there is a system to block stock in the cart for a few minutes. However, this is only recommended when the volume of sales is very high, e.g. during certain campaigns where a large number of sales per minute is expected.

If the Commerce is implementing backordering strategies for any of its products, the user will see that these products can be purchased in reserve, together with the date on which they will be delivered. This means that even if there is no stock at the time when the purchase is made, they will be available in the near future; the user can complete their purchase to make sure they will have the product delivered to them, even if this is later.

There may be several reasons for using a backordering strategy:

  • The Commerce has products with limited availability in terms of quantity and time, i.e. it receives a limited number of units every so often. If users order products and stock runs out, the Commerce may need to announce that it will have stock (it can even announce the quantity) by a given date in the near future so that users can buy in the form of reserving products to make sure they will get them. These orders are generally called "pending orders" or "backorders".
    This system can also work for other similar cases: for example, a Commerce can enable purchasing by reserving either always or for some products only, without specifying an actual date because it guarantees that they will always be available and if stocks run out they will be replaced within a short time.

  • The Commerce offers products that are not yet on sale or of which it does not yet have any actual stock. It may need to announce that on a future date the product will be on sale in limited quantities and users can pre-order to make sure they get the product. These orders of products in reserve are generally called pre-orders.

  • The Commerce offers products that are available on demand, either because they have to be manufactured or because they are ordered from the supplier when a customer places an order. Though these orders are not strictly considered "in reserve" (the system does not consider them in this way), the user will see a date showing that the product will be delivered after a certain delay. These orders are therefore sometimes considered, for logistical purposes at least, to be in reserve.

The configurations necessary to implement all these strategies will be described below. The result is that the user knows the product is not available (for whatever reason) and they are buying it in reserve.

Completing the Purchase

The shopping process continues with the choice of delivery type. If this is home delivery, it means selecting the means by which the shipment or shipments in the order are to be delivered, and choosing the form of payment. These steps finally determine the price of the order and it can be completed. This process of completing the order turns the shopping cart into an order. However, as the order is not yet paid for, the system does not remove the stock; this way, shopping cart situations like the one described above (orders being rejected or not finally paid for) are avoided.

Order Statuses

By definition, a completed order is an order pending confirmation by the payment gateway. It is defined like this because until there is proof of payment, the system must consider the order as pending payment. This situation might last a few minutes (the time it takes to process the payment and get a response from the gateway in question) or it might last longer, especially if there is any problem with the gateway.

In fact, orders pending confirmation by the payment gateway are assigned the status of "Pend. Payment Gateway". Order statuses reflect the situations the order is currently in. The system has some statuses reserved for specific purposes, but the Commerce manager can create whatever statuses they need. Various order statuses exist, but these are the ones that might be most closely related to stock:

  • Pend. Payment Gateway

  • Denied

  • Incoming

  • Deleted

Pend. Payment Gateway

Orders with the status of Pend. Payment Gateway are those which have been completed, but are awaiting payment. An alternative way of defining them is to say they are completed orders whose method of payment is an online payment gateway (with a connection). An online payment gateway is a service provided by some banks and other companies to handle the sending and receipt of payments via Internet. The advantage of these methods is that the Commerce gets an almost immediate response from the gateway informing it whether the transaction has been accepted or refused. If it is accepted, this tells the Commerce the order has been paid for; if it is refused, this means the gateway supplier has encountered a problem that stops it approving the transaction.

While it is not frequent, it can happen that a payment is made correctly through an online gateway but, for whatever reason (communication failure, very long response time, etc.), the Commerce is not notified of the result. It is also possible that the user might have interrupted payment voluntarily, stopping the gateway from sending any notification (this situation is more frequent). The consequence of all this is that the system does not know whether the order is paid for or not, and so it cannot move it from the status of Pend. Payment Gateway. It is highly advisable for the Commerce manager to review these orders to identify any problems and, above all, to deal with those that are correct.

As pointed out above, the system cannot remove stock for these orders because it lacks proof of payment.

Denied

Orders with Denied status are those explicitly rejected by the payment gateway provider. As they are grouped under one status, the manager can deal with them as they see fit. By definition, these orders are not valid and, logically, the system does not remove the stock listed in them.

Incoming

When the payment gateway notifies the Commerce that the payment has been accepted, the system changes the order status to indicate that it can now be processed. The status that indicates this is Incoming. Once the order has this status, the actions programmed by the manager are taken (this process can be triggered by any status). There is one action that is taken automatically, without needing any configuration: removal of stock. When the order has Incoming status, the system has confirmation of payment and can now deduct stock. The only status in which stock can be removed is Incoming, and it is important to bear this in mind. The reason for this has already been mentioned: this is the only status that guarantees that the order has been completed in full and paid for.

Orders with an offline method of payment (no connection) are those where payment is made afterwards. These orders go into the status of Pend. Payment Gateway very briefly, and then into Incoming status. This is because even though payment has not been made, it cannot be considered unpaid and must be treated in the same way as online payments with confirmation of payment. In practice, therefore, offline payments can be considered to always go into Incoming status.

When the system removes stock for an Incoming order (this is described in greater detail below), two situations can arise: that there is enough stock of all the products in the order, or that there are not enough units to fulfill all or part of the order. The former case is a normal situation; the second can arise for two reasons:

  • The user has purchased the product in reserve.

  • The user purchases the product in the usual way, but when the system tries to remove the stock it finds there is not enough. This happens when there are not many units left, for example, just one. At the time of making the purchase there were stocks, but another user bought the same product a few moments before. While the latter user is paying, the former sees that there is still stock and completes their purchase. The unit is deducted while the second user is confirming payment, so that when the first user completes payment a moment later the system detects that there is no longer stock. This is quite unusual and only occurs in Commerces with high volumes of sales per minute. While it is not a common situation, it can happen and therefore mention must be made of it.

In both cases the order must be specially marked to indicate that there is not enough stock and avoid, for example, notifying that the shipment has been sent before it can in fact be prepared and sent. The system marks it as an order with products in reserve, i.e. there is not enough stock of all the products requested, of some of them or of part of the quantity requested.

Shipment of orders including products affected by reserves cannot be processed until the system verifies that all the products and quantities can be supplied. If the Commerce has multi-shipment enabled (see Multi-Shipment System), the delivery will be divided into different shipments because of the delivery dates arising from the reserves (if the reserves are of this type, as discussed below). It is therefore to be expected that there will be shipments including products in reserve. If the Commerce does not have multi-shipment enabled, this means there will be a single shipment which, for the reason given above, cannot be processed until the system is able to withdraw all the stock requested, i.e. it cannot be processed until the stock lacking is replenished.

If the shipment cannot be processed this means its status cannot be changed, so it will remain as pending until the system verifies that there is enough stock to be able to send it. Shipments can also have reserved status, in the same way as orders.

Deleted

Orders can be deleted. In this process, the order is assigned a special status called "Deleted" and the stock already withdrawn is returned.

Configuration

The Inventory Management System is in two main blocks: on the one hand, stock management and, on the other, reserve management.

Stock Management

In general terms, stock management can be enabled or disabled. If it is disabled, the Commerce does not remove stock, even if it has been assigned to some product (it is ignored). This feature can be customized at product level, so that stock management can be disabled for specific products; this can be useful when products are not stocked (e.g. services) and there is no need to add or deduct stock.

It can sometimes be necessary to show the availability of the product in the presentation layer; it can be shown in numerical format (the number of units) or in text format (description of availability). If text format is used, it must be defined in terms of a series of ranges. An example of a definition of availability could be: if there are more than 10 units available, the system must show In Stock; if there are between 5 and 10, its must show Low Stock; and if there are between 1 and 4, it must show Last Units. Due to the fact that as many definitions of availability as required can be created, each product can be linked to the one it is to use, but in order not to have to do this explicitly, a default availability can be set in general.

A Commerce might wish to hide sold-out products in the presentation layer because it cannot sell them. This is why the Show Products Out of Stock feature exists; when it is enabled, all products are shown; if it is disabled, the product will be visible while stocks last, but once sold out, it will be hidden.

As well as managing stock and availability, which can be customized, the On Demand feature can be enabled for individual products. This feature requires another complementary one, Time Necessary On Demand, which specifies the number of days needed to prepare the product. The concept of products on demand includes products that have to be manufactured or ordered from the supplier as required.

If a user purchases a product with the On Demand feature enabled, two things can happen: that it is in stock and the purchase is normal (there can be stock of on-demand products) or that there is not enough stock to meet the request. In this case, the system will return the delay in days as configured, and this can be shown to the user to inform them of the situation.

On-demand products have a specific requirement: it must be possible to sell them normally, regardless of whether they are in stock or not. Orders containing on-demand products are completed in the usual way, but, as with products in reserve, the system needs to mark them in such a way as to be able to identify them and avoid, for example, sending notification of shipment before they are available. In this case, the system marks these orders as "order including on-demand products". Unlike orders including products in reserve, shipments of orders including on-demand products can be processed because they do not need the missing stock to be replenished. Stock of these products is optional, i.e. if there is stock it is withdrawn; if not, it is ignored.

Thanks to the special marking to distinguish orders including on-demand products, the Commerce manager can filter them conveniently in the BackOffice, identify the products in question and see how many units they need to have made or ordered so to fulfill the order. Because of their special nature, handling of these orders cannot be automated, so they will have to be dealt with through specific actions by the manager: they must order or have made what is needed and, once they receive it, they will have to process the order manually.

Reserve Management

Implementing a backordering strategy, taking this to mean the process of selling inventory the Commerce does not have available, requires tools to allow sales of this kind to be managed. Reserve management allows the system to work with products in reserve, i.e. with products that are not in stock, and also allows these to be configured easily.

If reserve management is enabled, the Commerce will have the option of purchase under reserve of its products enabled. As reserve management can be customized for individual products, it can be disabled for certain products. It should be pointed out that, in the event that reserves are enabled, it must also be possible to show products that have run out of stock. Otherwise, users will not be able to purchase them because they are not visible.

By their nature, orders including products in reserve need special attention: as some of their products are not in stock, it is necessary to identify and monitor which orders these are, which are the products that are not in stock and how many units are needed. Reserve management includes all these tasks. First, orders including products in reserve are specially marked so that Commerce managers can filter them conveniently in the BackOffice.

These orders require stock in order to be processed, so once stock has been added, the system must be told to review orders with products in reserve to see whether they can be processed or whether units are still lacking. This review, which consists of running a simulated stock removal to see whether there is enough stock to fulfill the order, can be carried out in 3 ways:

  • Manually, for a single order: The Commerce manager indicates that the stock for a specific order should be reviewed. If the review shows that the order can be fulfilled, the actual stock will be removed, the order will no longer be marked as "order with products in reserve" and can go on being processed. If not —if any units are still lacking— the order will remain marked as "order with products in reserve".

  • Manually, for a group of orders: The Commerce manager indicates that a previously selected group of orders should be reviewed. As before, if the review indicates that there are orders that can be fulfilled, the relevant stock will be removed, and these orders will no longer be marked as "orders with products in reserve". The rest will continue to be marked as before.

  • Automatically: The system automatically carries out the review in the background as programmed of all orders it sees are marked as "orders with products in reserve". This tool is enabled or disabled using the reserve configuration.

This review process (manual or automatic) can work in two ways:

  • Removing Stock Only if the Order is Complete: This mode reviews whether the order is complete, i.e. whether all the units reserved in it can be supplied from the stock existing at the time of the revision. If they can, the stock is removed, and the order is no longer marked as "order with products in reserve". If they cannot, the order continues to be marked as before. This mode is similar to the manual method for a group of orders, with the difference that the system carries it out.

  • Using Stock Gradually: This mode reviews whether the order is complete. If it is, it works like the previous mode. If not, it removes only the units it can and leaves the others in reserve (see Stock Removal).

For example, imagine an order contains 3 products: P1, P2 and P3. Of these, P1 and P2 have no stock problems, but P3 is a product in reserve. 10 units of P3 have been purchased. The Commerce has restocked and added 7 units of P3. If the first mode is used, the system assesses whether there is enough stock. When it finds that units of P3 are lacking (there are 7, but 10 are needed), it does nothing and leaves P3 with 10 units in reserve. If the second mode is used, the system removes all the stock it can: 7 units, in this case. The system therefore leaves P3 with 3 units (10 - 7) in reserve.

The manual review process for various orders or the automatic one, which also reviews more than one, needs to know what order to check them in, bearing in mind that stock is assigned to the first orders reviewed. The criterion for ordering is the date the order was placed, and it can be configured so that they are sorted from oldest to most recent or from most recent to oldest.

Types of Stock

Strictly speaking, there is only one type of stock, which is the stock of a particular product. However, from a logistical point of view, stock can be classified as 3 types according to the way it is dealt with:

  • Normal stock: This is stock coming into the warehouse in the usual way. The Commerce has it physically on a shelf in the warehouse, so it can be supplied immediately.

  • Stock provision: This is stock that has not yet arrived, but has a specific delivery date and quantity, i.e. when it will arrive and in what quantity are known. This is stock the Commerce does not yet physically have, but it knows that on a specific date it will have it and, for practical purposes, it is as if it had it. Stock provisions are formally considered as stock, with the difference that instead of being deliverable immediately (like normal stock), it is supplied later, on the reception date configured.
    While there is a stock provision, units can be sold. Once the date arrives, the provision is no longer current. Therefore, stock provisions make it possible to sell units until their stock runs out or until the date arrives.

  • Reserve provision: This is stock used when there is a backordering strategy. This is stock in reserve that has not yet been received, but which is expected to arrive on a particular date in a certain quantity. The stock in reserve provisions determines the number of units that can be reserved. It is important to point out that this stock has a reception date even though it is in reserve. This date allows strategies such as preordering and backordering. The reasons for these reserves are slightly different, but in practice they mean reserving a certain quantity with a reception date in the future.
    While there is a stock for the provision, units can be reserved. Once the date arrives, the provision is no longer current. Therefore, reserve provisions allow units to be reserved until their stock runs out or until the date arrives.
    Another important detail is that, due to their nature as a reserve, the system cannot consider reserve provisions as reliable stock that is sure to arrive on the date set (unlike stock provisions, which are not considered units in reserve). In many cases, reserve provisions arrive on the date set, and in the quantities specified, as it should be if the Commerce is to give reliable delivery dates. However, the system considers the quantities and dates to be approximate.

Both stock provisions and reserve provisions are stock the Commerce does not yet have, but the purposes of these stock types are different. In the case of stock provisions, the Commerce considers them normal stock that has not yet arrived; or, to put it another way, stock that instead of being supplied immediately will be supplied on a date in the future. This is why the system does not consider the orders for products that take their stock from stock provisions as orders for products in reserve, but as absolutely normal orders.

On the other hand, in the case of a reserve provision, the Commerce considers it as stock that has not come in yet, but interprets it as the number of units that can be reserved of this product, either to avoid more being sold than is expected to be received or to limit the number of reserves than can be made for a product. These reserved products and the units in the provision must be marked as being in reserve; in this way, they can be identified and handled in a specific way alongside all the other orders including products in reserve.

In management terms, therefore, there are two kinds of reserves : reserves with a date (reserve provision) and reserves indicating that the product can be sold as a product in reserve (it is not currently in stock, but will be in the future), but has no specific reception date. This distinction must be configured at product level using the following modes:

  • Disabled: The product does not allow reserves of any kind. When stock runs out, the product cannot be sold (the system does not allow it to be added to the shopping cart).

  • With Reserve Provision: Once normal stock runs out, units of the product can be sold as units in reserve, but the maximum reserve is the amount entered in the provision. Once all the units in the provision have been reserved, the product cannot be sold (the system does not allow it to be added to the shopping cart).

  • No Reserve Provision: Once normal stock runs out, units of the product can be sold as units in reserve with no limit on quantity. Product that allow No Reserve Provision mode are those the Commerce wants to sell in reserve, without any restriction on quantity and without imposing a reception date. The Commerce is committed to replenishing this stock because it knows it will be getting more, but it is unwilling or unable to say when or how much will arrive.

  • Both, With and Without Provision: Once normal stock runs out, units of the product can be sold as units in reserve and only in the quantity entered in the provision. Once all the units in the provision have been reserved, units of the product can be sold as units in reserve, with no limit. This means the system first uses reserve provisions (the reserves for which the Commerce knows how many units it will receive and when) and then, once these have run out, allows the product to be sold without any limit as reserved units without a specific date. In this case, once the reserve for which the Commerce knows how much it will receive and when has run out, the Commerce is committed to replenish the stock to cover the rest of the units because it knows it can get more, but is unwilling or unable to say when it will arrive or in what quantity.

Both stock provision and reserve provision refer to the near future, i.e. the product cannot be supplied at the moment, but this must wait until it is received. This means that an order including a product with a provision of any kind will involve a delay in delivery. The system gives this delivery date and it is therefore highly advisable to show it in the presentation layer: this way, the user knows how long it will be delayed (or when the product will go on sale in the case of an advance sale).

This delayed delivery date is one of the reasons for splitting shipments (see Multi-Shipment System). If multi-shipment is enabled, the order will be split into as many shipments as there are delivery dates (in this case determined by the different dates of the provisions). If the Commerce does not have multi-shipment enabled, the order will be sent in a single shipment, the delivery date of which will be the furthest from the current date of all the dates of provisions involved.

As stock and reserve provisions expect stock on specific dates, the IMS includes an automated mechanism in the background to check stock of these types regularly. The following processes are run:

  • If there are stock provisions not standing at 0 (i.e. there are provisions that have stock left unused) with a past date (i.e. the date of the provision is earlier than the date on which this check is made), the stock of these provisions becomes normal stock. The system therefore considers that the stock in the provision has now arrived and so turns it into normal stock.
    If there are provisions with zero stock with a past date, they are deleted.

  • Unlike stock provisions, reserve provisions, due to their nature as a reserve, cannot be considered reliable stock that will definitely come in. Therefore, all reserve provisions with a past date are deleted. As the system cannot use reserve provisions not consumed (not yet at zero) with a past date, nor can it consider them stock that has arrived, it interprets that it must clean up by deleting them.

Recording Incoming Stock

The incoming stock process establishes which warehouses contain stock of a particular product, i.e. the stock points directly to a warehouse. Stock can then only be removed from the lines recorded as received. If more warehouses are then created, new lines of stock can be added that point to these warehouses.

It has been mentioned above that stock information is given depending on whether a product has options set or not. Let us look at some examples.

If a product has combinable options, stock is topped up in terms of combinations of option values. Example: Product1 has size and color options, and size (S, M, XL) and color (Black, White) combinations, so stock would be topped up for each combination, as follows:

  • Product1 - S - White

  • Product1 - S - Black

  • Product1 - M - White

  • Product1 - M - Black

  • Product1 - XL - White

  • Product1 - XL - Black

If it has no options or they are not combinable, stock is topped up in terms of the product, for example:

  • Product1

In each of these lines stock can be added from whichever warehouse is required. For example, if Product1 is stocked at W1 and W2, the following records can be created:

  • W1 - Product1 - S - White: 10 units

  • W1 - Product1 - S - Black: 8 units

  • W1 - Product1 - M - White: 15 units

  • W1 - Product1 - M - Black: 7 units

  • W1 - Product1 - XL - White: 4 units

  • W1 - Product1 - XL - Black: 10 units

  • W2 - Product1 - S - White: 10 units

  • W2 - Product1 - S - Black: 10 units

  • W2 - Product1 - M - White: 12 units

  • W2 - Product1 - M - Black: 16 units

  • W2 - Product1 - XL - White: 3 units

  • W2 - Product1 - XL - Black: 0 units

If new values are created for these combinations for a product, new lines of stock can be created. However, if new combinable options are created, as each line of stock must be a full combination, all existing lines of stock will have to be deleted and entered again including the combinations of these new options.

If Product1 had no combinable options, these records could be created:

  • W1 - Product1: 10 units

  • W2 - Product1: 5 units

As it must also be possible to report on stock provisions and reserve provisions, such provisions can be reported for each of these lines. Let us take a complex case where the Commerce works with provisions of both kinds (if it only works with one of them, only one of the lines will be needed):

  • W1 - Product1 - S - White: 10 units

    • Stock provision for W1 - Product1 - S - White for dd-mm-yyyy: 7 units

    • Reserve provision for W1 - Product1 - S - White for dd-mm-yyyy: 5 units

  • W1 - Product1 - S - Black: 8 units

    • Stock provision for W1 - Product1 - S - Black for dd-mm-yyyy: 3 units

    • Reserve provision for W1 - Product1 - S - Black for dd-mm-yyyy: 3 units

  • W1 - Product1 - M - White: 15 units

    • Reserve provision for W1 - Product1 - M - White for dd-mm-yyyy: 3 units

  • W1 - Product1 - M - Black: 7 units

    • Stock provision for W1 - Product1 - M - Black for dd-mm-yyyy: 2 units

    • Reserve provision for W1 - Product1 - M - Black for dd-mm-yyyy: 3 units

  • W1 - Product1 - XL - White: 4 units

    • Stock provision for W1 - Product1 - XL - White for dd-mm-yyyy: 4 units

    • Reserve provision for W1 - Product1 - XL - White for dd-mm-yyyy: 4 units

  • W1 - Product1 - XL - Black: 10 units

    • Stock provision for W1 - Product1 - XL - Black for dd-mm-yyyy: 2 units

    • Reserve provision for W1 - Product1 - XL - Black for dd-mm-yyyy: 2 units

  • W2 - Product1 - S - White: 10 units

    • Stock provision for W2 - Product1 - S - White for dd-mm-yyyy: 2 units

  • W2 - Product1 - S - Black: 10 units

    • Stock provision for W2 - Product1 - S - Black for dd-mm-yyyy: 4 units

    • Reserve provision for W2 - Product1 - S - Black for dd-mm-yyyy: 2 units

  • W2 - Product1 - M - White: 12 units

  • W2 - Product1 - M - Black: 16 units

  • W2 - Product1 - XL - White: 3 units

  • W2 - Product1 - XL - Black: 0 units

    • Stock provision for W2 - Product1 - XL - Black for dd-mm-yyyy: 2 units

If Product1 had no combinable options, these records could be created:

  • W1 - Product1: 10 units

    • Stock provision for W1 - Product1 for dd-mm-yyyy: 2 units

    • Stock provision for W1 - Product1 for dd-mm-yyyy: 1 unit

  • W2 - Product1: 5 units

    • Stock provision for W2 - Product1 for dd-mm-yyyy: 1 unit

    • Stock provision for W2 - Product1 for dd-mm-yyyy: 1 unit

It is not obligatory to have stock or reserve provisions for all combinations and/or all warehouses; in general, this will depend on each situation. The provision lines depend on the specific stock line created for a combination: If no stock line exists for a combination, provisions cannot be created. For example, a product has a combination that is not in stock because the Commerce has never had it, but 10 units are expected to arrive soon. The Commerce wants to place them on advance sale and therefore needs to create reserve provision of 10 units for a forthcoming date. To do this, it must first create the stock line for the combination, leave it at zero and then create the reserve provision.

Likewise, as many provision lines as necessary can be created for a combination. For example, these stock records could be created for W1 - Product1 - S - White:

  • W1 - Product1 - S - White: 10 units

    • Stock provision for W1 - Product1 - S - White for AA-mm-yyyy: 3 units

    • Stock provision for W1 - Product1 - S - White for BB-mm-yyyy: 2 units

    • Stock provision for W1 - Product1 - S - White for CC-mm-yyyy: 1 unit

    • Reserve provision for W1 - Product1 - S - White for EE-mm-yyyy: 4 units

    • Reserve provision for W1 - Product1 - S - White for FF-mm-yyyy: 5 units

This means the combination W1 - Product1 - S - White has a stock provision of 3 units expected for AA-mm-yyyy, a stock provision of 2 units expected for BB-mm-yyyy and a stock provision of 1 units expected for CC-mm-yyyy. It also has a reserve provision of 4 units expected for EE-mm-yyyy and a reserve provision of 5 units for FF-mm-yyyy.

Stock Removal

Once new stock has been recorded, the system now knows which warehouses have this product available, whether there are provisions and what date these provisions will arrive on. To proceed with removal it must be remembered that there is a relationship between channel and warehouse (see Multi-Channel System). Channels must have warehouses linked to them, which means only the warehouses for the assigned channel can supply stock for orders placed through this channel. As the warehouse has an area of influence determined by the logistic center, if this area is not compatible with the channel area, the warehouse is disqualified for the channel and cannot supply stock.

The relationship between channel and warehouse has a priority which determines the order in which stock comes out (the order is always from the lowest to the highest value specified in the Priority property). Therefore, among all the warehouses in the channel, the system will first take stock from the warehouse set as the first (e.g. with priority 1). If there is not enough stock in this warehouse, the system will look in the one set as the second (e.g. with priority 2), and so on. If not all the stock can be supplied because there is not enough stock between all the warehouses, the product will go into reserve, if this is enabled (the items that cannot be supplied are left in reserve); if it is not enabled, the order cannot be fulfilled with the product quantity requested.

If there are provisions, first normal stock is removed, then stock provisions are used up and, finally, reserve provisions. Normal stock or stock provisions are used up (by deduction) and, if units are left in reserve because there is not enough stock, those removed are kept blocked in the order. These units can no longer be returned to the warehouse for possible use in another order. This ensures that when stock is subsequently replenished to fulfill reserves (this may be days later), the order still has all the units removed from the warehouse and it can be shipped in full. If these units were not blocked for this order, any other order could "steal" them, which would make it harder to fulfill the first order due to lack of stock and would lead to confusion in shipments.

As reserve provision stock are the units that can be reserved of a hypothetical incoming delivery of merchandise on a future date, when this stock is used up, no units are actually removed, but deducted from the stock configured in the provision in order to keep a check on the number of units reserved. This way, when all the provision stock is deducted (it reaches zero), no more reserves can be made (unless reservation without provision is enabled).

When there is a reservation this is because there is no stock at the time when the user places the order. The stock that comes in subsequently will allow the reserved units to be replaced with actual units: a unit of the stock that has come in will be deducted for each unit reserved. When all the units reserved have been replaced by normal units (they have been deducted from normal stock), the order will cease to be considered an order with products in reserve. Therefore, with reserve provisions there are two kinds of removal: one that deducts units of stock as configured in the provision in order to monitor the number of units in reserve, and another than removes real stock, where a unit of normal stock is deducted for every unit reserved. The date of the reserve provision is useful to provide information about the date stock is expected to arrive (and, where relevant, to cause the order to be split into different shipments) and to determine the date reservations expire, but it plays no part in removal.

If the order is marked as "order with products in reserve" and stock removal is in "Only Remove Stock if the Order is Complete" mode, the system checks whether there is enough stock to cover the units in reserve. If there is not enough stock, the order remains the same. If enough stock has come in, stock is removed for the order and it is left marked as an "order with products in reserve".

If the order is marked as "order with products in reserve" and stock withdrawal is in "Consume Stock Gradually" mode, the system deletes all the units it can from the incoming stock, and the other units are left in reserve. This process is repeated until the system has deducted all the units from the incoming stock. When there are no units left in reserve, the order ceases to be marked as "order with products in reserve".

Another important detail is that reserve provisions are linked to a specific line of combination and warehouse. This means that the system waits for stock to come in for this specific combination and warehouse. If new stock comes in for this combination, but in another warehouse, stock removal will not allow reserved units to be replaced by the new stock because the system understands that this stock is not what it was waiting for. Normal reserves (without a provision) are only tied to the combination (because this is what is reserved), but not to the warehouse. This means that stock coming into any warehouse can be used to replace normal reserved units with units of new stock.

Example

Product1 with size and color options, and size (S, M, XL) and color (Black, White) combinations, is in stock in two warehouses, W1 and W2, which belong to the same logistic center (for simplicity). The stock lines have been created as follows:

  • W1 - Product1 - S - White: 10 units

  • W1 - Product1 - S - Black: 8 units

  • W1 - Product1 - M - White: 15 units

  • W1 - Product1 - M - Black: 7 units

  • W1 - Product1 - XL - White: 4 units

  • W1 - Product1 - XL - Black: 10 units

  • W2 - Product1 - S - White: 10 units

  • W2 - Product1 - S - Black: 10 units

  • W2 - Product1 - M - White: 12 units

  • W2 - Product1 - M - Black: 16 units

  • W2 - Product1 - XL - White: 3 units

  • W2 - Product1 - XL - Black: 0 units

If you have an order of withdrawal whereby W1 provides first (priority 1), then W2 (priority 2), the system will first use up the stock in W1 of each combination and then, when it can no longer take stock in this combination, it will do so from W2.

If 15 units of Product1 - S - White are ordered, 10 units will be taken from W1 and 5 units from W2 in this combination.

If there are only stocks for White in W1 and only for Black in W2:

  • W1 - Product1 - S - White: 10 units

  • W2 - Product1 - S - Black: 10 units

  • W1 - Product1 - M - White: 10 units

  • W2 - Product1 - M - Black: 10 units

  • W1 - Product1 - XL - White: 10 units

  • W2 - Product1 - XL - Black: 10 units

Because White is only supplied by W1 and Black by W2, once a combination runs out it can no longer be supplied. For example, if 15 units of Product1 - S - White are ordered, only 10 units can be supplied; the other 5 units are left in reserve, if Product1 has this feature enabled. Otherwise, the order cannot be fulfilled due to lack of stock.

Imagine stock and reserve provisions are created. For simplicity, we will focus only on the combination Product1 - S - White:

  • W1 - Product1 - S - White: 3 units

    • Stock provision for W1 - Product1 - S - White for 10-mm-yyyy: 2 units

    • Reserve provision for W1 - Product1 - S - White for 18-mm-yyyy: 2 units

  • W2 - Product1 - S - White: 2 units

    • Stock provision for W1 - Product1 - S - White for 12-mm-yyyy: 2 units

    • Reserve provision for W1 - Product1 - S - White for 19-mm-yyyy: 3 units

If, during the shopping process, the customer adds 15 units to the cart, the system proceeds as follows:

  1. It removes stock from W1 and subtracts these units from the quantity ordered. As the quantity ordered exceeds the stock in the warehouse, the system extracts it all: 15 - 3 = 12 units.

  2. As units are left pending, the system now extracts them from W2. As the quantity pending exceeds the stock in this warehouse, the system extracts it all: 12 - 2 = 10 units.

  3. Once normal stock has run out, there are pending units remaining. We now move on to stock provisions, starting with the highest priority warehouse; in this case it is W1, which has a provision for 10-mm-yyyy.
    As the quantity pending exceeds the stock in this warehouse, the system extracts it all: 10 - 2 = 8 units.

  4. As there are still units pending, we move on to W2, which has a stock provision for 12-mm-yyyy. As the quantity pending exceeds the stock in this warehouse, the system removes it all: 8 - 2 = 6 units.
    If Product1 does not have reserves enabled, the system will return an error message saying that there is not enough stock.

    Supposing Product1 does have reserves enabled in "With Reserve Provision" mode:

    1. Once the stock provisions have run out, as the product allows for reserves, the system takes stock from the reserve provisions, starting with the highest priority warehouse, W1, which has a provision for 18-mm-yyyy.
      As the quantity pending exceeds the stock in this warehouse, it is all extracted: 6 - 2 = 4 units.

    2. As there are still units pending, we move on to W2, which has a reserve provision for 19-mm-yyyy. As the quantity pending exceeds the stock in this warehouse, the system removes it all: 4 - 3 = 1 unit.
      As reserves without any provision are not permitted, the system will return an error message saying that there is not enough stock.

      Supposing Product1 does have reserves enabled in "Both, With and Without Provision" mode:

      1. As there is still a quantity pending, the system places it in reserve: 1 unit. The system reports that the product has been added, but that there are units in reserve with delayed delivery dates; specifically, and due to provisions, there are delivery dates for 10-mm-yyyy, 12-mm-yyyy, 18-mm-yyyy and 19-mm-yyyy.

      2. If the Commerce has multi-shipment enabled, 1 shipment is generated due to the origin, i.e. the logistic center, and another 4 due to the delayed delivery dates, specifically with delivery dates of 10-mm-yyyy, 12-mm-yyyy, 18-mm-yyyy and 19-mm-yyyy.
        If the Commerce does not have multi-shipment enabled, 1 shipment is generated for 19-mm-yyyy, which is the delivery date furthest from the current date.

      3. The order is allowed to be completed.

The final result is that, if Product1 allows reserves with and without provision, it can be added to the shopping cart in the quantity requested. This allows the order to be completed normally. When the order is paid for and its status changes to Incoming, the actual removal will take place. As there are reserves involved in this case, the system proceeds as follows:

  1. It removes stock from W1 and deducts it from the quantity ordered. As the quantity ordered exceeds the stock in the warehouse, it is all extracted: 15 - 3 = 12 units.
    The system records that 3 units have been extracted in stock line W1 - Product1 - S - White. W1 is left with zero units.

  2. As units are left pending, the system now extracts them from W2. As the quantity pending exceeds the stock in this warehouse, it is all extracted: 12 - 2 = 10 units.
    The system records that 2 units have been extracted in stock line W2 - Product1 - S - White. W2 is left with zero units.

  3. Once normal stock has run out, there are pending units remaining. We now move on to stock provisions, starting with the highest priority warehouse; in this case it is W1, which has a provision for 10-mm-yyyy.
    As the quantity pending exceeds the stock in this warehouse, it is all extracted: 10 - 2 = 8 units.
    The system records that 2 units have been extracted in stock provision line W1 - Product1 - S - White for 10-mm-yyyy. The provision is left at 0 units.

  4. As there are still units pending, we move on to W2, which has a stock provision for 12-mm-yyyy. As the quantity pending exceeds the stock in this warehouse, it is all extracted: 8 - 2 = 6 units.
    The system records that 2 units have been extracted in stock line W2 - Product1 - S - White for 12-mm-yyyy. The provision is left at 0 units.

  5. Once the stock provisions have run out, as the product allows for reserves, the system extracts stock from the reserve provisions, starting with the highest priority warehouse, W1, which has a provision for 18-mm-yyyy.
    As the quantity pending exceeds the stock in this warehouse, it is all extracted: 6 - 2 = 4 units.
    The system records that 2 units in reserve have been extracted in reserve provision line W1 - Product1 - S - White for 18-mm-yyyy. The provision is left at 0 units.

  6. As there are still units pending, we move on to W2, which has a reserve provision for 19-mm-yyyy. As the quantity pending exceeds the stock in this warehouse, it is all extracted: 4 - 3 = 1 unit.
    The system records that 3 units in reserve have been extracted in reserve provision line W2 - Product1 - S - White for 19-mm-yyyy. The provision is left at 0 units.

  7. As there is still a quantity pending, the system records that there is 1 unit in reserve for W1 - Product1 - S - White.

  8. The system detects that there are 6 units in reserve: 2 for W1 - Product1 - S - White for 18-mm-yyyy, 3 for W2 - Product1 - S - White for 19-mm-yyyy and 1 unit with a normal reservation. It marks the order as "order including products in reserve".

  9. If the Commerce has multi-shipment enabled, 1 shipment is generated due to the origin, i.e., the logistic center, and another 4 due to the delayed delivery dates, specifically with delivery dates of 10-mm-yyyy, 12-mm-yyyy, 18-mm-yyyy and 19-mm-yyyy. The normal shipment is processed. The other 4 remain on hold until stock comes in.
    If the Commerce does not have multi-shipment enabled, 1 shipment is generated for 19-mm-yyyy, which is the delivery date furthest from the current date, waiting for stock to come in.

After this removal, the stock is as follows:

  • W1 - Product1 - S - White: 0 units

    • Stock provision for W1 - Product1 - S - White for 10-mm-yyyy: 0 units

    • Reserve provision for W1 - Product1 - S - White for 18-mm-yyyy: 0 units

  • W2 - Product1 - S - White: 0 units

    • Stock provision for W1 - Product1 - S - White for 12-mm-yyyy: 0 units

    • Reserve provision for W1 - Product1 - S - White for 19-mm-yyyy: 0 units

This means there is no normal stock left, no stock provisions left, and no more units reserved under provision are allowed because all the reserves have been used up. Should another order be placed which includes Product1 - S - White, the system would add this combination to the shopping cart, but in reserve. The order is left with 6 units in reserve, so stock will need to come in.

Let us expand the example with what would happen if the Commerce added stock in the combination Product1 - S - White.

a) If stock removal is in "Only remove stock if the order is complete" mode:

Imagine that the following stock comes in for this combination:

  • W1 - Product1 - S - White: 4 units

  • W2 - Product1 - S - White: 2 units

There are 6 units in reserve, and, in principle, 6 new units have also come in. Let us examine this in detail:

  • 4 units have come into W1 and there are 2 units reserved linked to a stock line created at this warehouse. The quantity pending is less than the stock and it is extracted; 2 units of stock (4 - 2) are left in W1. No reserves in W1 are left pending.

  • The normal reservation can be replaced by the stock coming into W1, which still has 2 units and could supply one.

  • 2 units have come into W2 and there are 3 units reserved linked to a stock line created at this warehouse. The quantity pending exceeds the stock and it is all extracted, but 1 reservation still remains pending, and this can only be replaced by stock in W2.

The order cannot therefore be completed because of the reservation in W2. The order does not use up any of the 6 units that come in and remains with the same 6 reservations.

The stock therefore remains intact:

  • W1 - Product1 - S - White: 4 units

  • W2 - Product1 - S - White: 2 units

Imagine further stock comes in, of 1 unit for W1 and 1 unit for W2, and the stock remaining before has not yet been used up. The stock is left as follows:

  • W1 - Product1 - S - White: 5 units

  • W2 - Product1 - S - White: 3 units

The system proceeds as follows:

  • There are 5 units in W1 and there are 2 units reserved linked to a stock line created at this warehouse. The quantity pending is less than the stock and it is extracted; 2 units of stock (4 - 2) are left in W1. No reserves in W1 are left pending.

  • There are 3 units in W2 and there are 3 units reserved linked to a stock line created at this warehouse. The quantity pending is the same as the stock and it is all extracted; the stock in W2 is left at zero. No reserves in W2 are left pending.

  • The normal reservation can be replaced by the stock coming into W1, which still has 3 units and could supply one.

The order can therefore be completed. Following removal, the stock is left as follows:

  • W1 - Product1 - S - White: 2 units

  • W2 - Product1 - S - White: 0 units

b) If stock removal is in "Use Up Stock Gradually" mode:

Imagine that the following stock comes in for this combination:

  • W1 - Product1 - S - White: 4 units

  • W2 - Product1 - S - White: 2 units

There are 6 units in reserve, and, in principle, 6 new units have also come in. Let us examine this in detail:

  • 4 units have come into W1 and there are 2 units reserved linked to a stock line created at this warehouse. The quantity pending is less than the stock and it is extracted; 2 units of stock (4 - 2) are left in W1. No reserves in W1 are left pending.

  • 2 units have come into W2 and there are 3 units reserved linked to a stock line created at this warehouse. The quantity pending exceeds the stock and it is all extracted, but 1 reservation still remains pending, and this can only be replaced by stock in W2.

  • The normal reservation can be replaced by the stock coming into W1, which still has 2 units and could supply one; it is left with 1 unit.

The order cannot therefore be completed because of the reservation in W2, but the order has used up stock because of the reservations.

The stock is therefore as follows:

  • W1 - Product1 - S - White: 1 unit

  • W2 - Product1 - S - White: 0 units

Imagine further stock comes in, of 1 unit for W1 and 1 unit for W2, and the stock remaining before has not yet been used up. The stock is as follows:

  • W1 - Product1 - S - White: 2 units

  • W2 - Product1 - S - White: 1 unit

The system proceeds like this:

  • There are 2 units in W1 and there are no units reserved linked to a stock line created at this warehouse. No stock is removed.

  • There is 1 unit in W2 and there is 1 unit reserved linked to a stock line created at this warehouse. The quantity pending is the same as the stock and it is all extracted; the stock in W2 is left at zero. No reserves in W2 are left pending.

  • There are no normal reserves, so the system does not have to make any further removals.

The order can therefore be completed. Following this removal, the stock is as follows:

  • W1 - Product1 - S - White: 2 units

  • W2 - Product1 - S - White: 0 units