General Architecture

Commerce Inventory is built to be Commerce module agnostic; meaning that Order, Product, and Store aren’t required, but are available as additional installable modules included as part of Commerce Inventory. They give a good example of how easy it is to support other purchasable entity types and how to incorporate Commerce Inventory into Commerce core.

Included Modules

The following modules are included to incorporate the core Commerce modules Store, Product, and Order.

Commerce Inventory: Store

The Store module sets up an Inventory Location entity-reference field on the Store entity. This associates Stores with inventory of the related locations. It also sets up an Availability Checker to tell Commerce whether a certain purchasable entity is available based on that purchasable entity's current quantity count (available count - minimum count).

Commerce Inventory: Product

The Product module enables the ability to track Product Variations in the Commerce Inventory module. It enables a page to add and modify the items, as well as sets up checks to disallow variations from being disabled or removed if that variation is used in an inventory item.

Commerce Inventory: Order

The Order module is what fully incorporates Commerce Inventory with Commerce core. It is what enables automatic quantity withholding based on Order status and sets up allocation based on store and product. See the sub-module's documentation page for more information on setting up automatic allocation and adjustments based on Order status.

Architecture

There are 3 entity types:

• Inventory Locations: where inventory is held. Locations are not the same as Stores. Stores can be associated with Locations, which allows multiple stores to use inventory from the same locations, as well as one store to use inventory from multiple locations (this functionality is available in an included module).
• Inventory Items: a purchasable entity at an Inventory Location. An example of a purchasable entity is a product variation (which can be enabled via an included module).
• Inventory Adjustments: a quantity adjustment of a specific Inventory Item. Since this is an entity, this can be used in Views and saved with additional meta data and whatever else.

There are 2 plugin types that work with the entity types:

• Inventory Providers: These are used as the bundles for Inventory Locations and Inventory Items. This is what allows multiple stock providers to be enabled at the same time, since all locations (and ultimately items) are then tied to a certain provider. This plugin has methods which are called at certain events which allows it to react to adjustments, creation, item validation, etc. Items and Locations have a remote ID setup by default, which the provider can declare that it uses. It also has a method to more-easily provide auto-complete for remote IDs.
• Inventory Adjustment Type: These are used as bundles for Inventory Adjustments. They allow adjustments to be tracked by type (generic Decrease and Increase, Move To and Move From, Sale, Return, New). They have a method called adjustQuantity, which an adjustment quantity is passed before creation. This allows the type to clean the adjustment and make sure it matches what is supposed to happen (go negative, positive, etc). Providers can create new adjustments to more-easily track whenever they make adjustments (e.g.: “Square external Decrease” or “Lightspeed external Increase”) for adjustments made outside of Drupal.

The module handles inventory count in a few ways:

• On Hand: The current “On Hand” count of an Inventory Item is automatically calculated from previous adjustments. It is fully handled by the module and isn’t modifiable. This is a cached value that is updated when adjustments are made.
• Available: The current “Available” count of an Inventory item is the “On Hand” count, but modified via an event to relay what is currently available to be used. This allows modules like the included Commerce Inventory Order module to withhold Product on Orders that have been placed but not fulfilled (this functionality is configurable to meet different needs). This is a cached value that is updated when adjustments are made or when modules specify it should be invalidated.
• Minimum: This is the minimum amount that the item can drop to before it’s labeled as “out of stock”. An example that is useful would be the ability to allow for back-orders to a certain point, even if the current Inventory Item “On Hand” quantity is 0. This is a cached value that is updated when adjustments are made or when modules specify it should be invalidated.

Finally, there is an Allotment Manager, which allows modules to modify how quantity is allotted to different Inventory Items based on certain criteria. An example would be when a Store uses multiple Inventory Locations, yet one of the Location’s Items doesn’t have enough stock to completely fulfill the request.