Stock for Drupal 8 commerce - Technical overview & use cases

The business requirements

Drawing on the experience of maintaining the Drupal 7 stock module and working with a number of ERPs over the years we have come up with a completely new architecture for Drupal 8 commerce stock module.

The following are the 4 main challenges that I encountered with the Drupal 7 module that needed addressing:

• Performance issues including deadlocks
• The need for a mature transactional based system
• Location based stock
• Integrate with external ERP systems.

At the same time it was important to me to make sure the module is suitable for the majority of the stock module users that were happy with the simple approach of the Drupal 7 version.
In so doing we have made it easy for others to extend.

The result is a proposed architecture that addresses all these and has been presented over the last year through the drupal.org commerce stock issue queue

The Service architecture

The StockAvailabilityChecker - This implements the core commerce AvailabilityCheckerInterface and, once this interface is implemented in commerce, it will provide the stock checking functionality.
This service doesn’t do much in itself as it uses the StockManager to do the work.

The StockManager - This is a service collector that collects services of type StockServiceInterface. It also holds a configuration class that tells it when to use this service.
Currently the configuration will allow for selecting one active service but at a later stage this will be extended to work at a more granular level (probably by product type).

The Stock service - The module comes with two services: The first is an "Always in stock" and the second is the "Transactional Stock" currently called "Local Stock" (i.e. stored in the drupal DB).  
Each stock service needs to implement 3 classes based on the following interfaces: StockCheckInterface, StockUpdateInterface & StockConfigurationInterface.
The Configuration determines the relevant location(s). The checker does the availability checking and the Update the updating.

The Transactional Stock Service

This is designed to provide full audit capabilities on current stock levels, far better tracking and reporting and improved performance across multiple locations (warehouses, stores, ...)
The idea is that each stock movement (sold products, new stock ..) will result in a transaction record. This record will hold a quantity along side other information.    
These records can be summed up by product variation to get the overall stock level.
The advantage of this system is that by using only selects and inserts we get a highly efficient db system that can not result in deadlocks (a common D7 stock issue). The potential problem is that large number of transactions can be expensive to sum. The solution for this problem is a cron job that will periodically sum existing transactions and update a master record with the totaled quantity alongside the last transaction id. This introduces an update but as this is handled by a single process (cron) we are not introducing a potential deadlock so the result should provide performance and scalability.

The state of things

The current implementation of the Drupal 8 module available on drupal.org provides a complete service architecture and it's the Stock service itself that is the focus of on going development.
The transactional stock service implements an API capable of creating transactions and running availability checks, so once we have an interface (currently only a dev one is available) & commerce implements the availably Checker we should have a working system.   
However the following need implementing:

• The cron job for updating the location stock
• UI for creating and managing stock locations & transactions. Currently a development sub module for calling API functions is included but will be removed when the first beta is realised.
• Transaction Metadata holding information for each transaction - In progress to be finished shortly.
• Unit Cost - The transaction record includes a unit_cost field for for FIFO and LIFO reporting.

Use cases

The plan is to sub-class the current service "local Stock" into two services that will be almost identical but serve two use cases.

• Transactional stock - A full transactional service or a 'non watered down version' of "local Stock"
• Simple stock - This will use the "local stock" functionality but delete transactions after they are totalled to avoid holding a large dataset when one is not needed. It is likely to include a more simplified interface and possibly be limited to a single location.

Other use cases for the module are:

• External ERP integration - New services can be developed for specific ERP systems I am hoping to develop the Brightpearl one see https://www.drupal.org/project/commerce_brightpearl in time for a full release.
• Other use cases and customisation - The combination of a the service architecture + the fact that Drupal 8 is OOP will allow people to derive their own services from existing ones as well as developing a complete solution to be plugged into the StockManager.

How can I help?

If you have an interest in inventory management or just want to help make Drupal and Drupal Commerce better do get involved with the issue queue.

for more details see https://www.drupal.org/project/commerce_stock and Stock for D8: Architecture & high level functionality in the drupal.org issue Q