Managing Inventory without Stock Limits

[RaggedStaff]

We have some scenarios around inventory management that we need to figure out compatibility for:

• Some of our platforms don't manage inventory at all. They will not be processing or passing any values for CatalogItem:StockLimitation
• Some platforms allow inventory management to be turned off for specific products (so they continue selling into negative stock values).
• Some platforms have strict inventory management and do not support negative stock values.

How do we wish to support this within the ontology? Some options I can think of:

1. We add a boolean field to determine if inventory is being managed.
2. We have rules around how to express stock values that are not limited (e.g. nil, zero etc...). - this approach might impact some Connector functionality around empty nodes (see issue).

What are your thoughts @Alcoz @lecoqlibre ?

[RaggedStaff]

I think my preference is that we allow platforms to send negative stock values... and (in the docs) instruct platforms to interpret those as unlimited.

[mkllnk]

So if we do have positive stock on an unlimited item then we just need to set the stock limit to -1, right? Sounds reasonable to me because it's not an enforced limit in this scenario and the actual stock value is only internal and doesn't need to be communicated on the API.

[Alcoz]

Regarding the ontology, stock limitation is not mandatory and is a float, which is very flexible. Maybe it is okay to just send nothing, which would signify that there is no stock limitation.
A negative value would really mean there is an unlimited stock ? Maybe there is a negative tolerance threshold known by the company, i don't know if it is a use-case

[RaggedStaff]

I think that option might be impacted by an issue with the Connector, around Nil/Null/Empty values

[mkllnk]

It also makes it impossible to send sparse documents. This becomes especially important in interoperability where one system may not know all the latest attributes of an object. And if a system doesn't include an attribute, we don't know if it was intentionally unset or unknown or if that system just doesn't care about that particular one.

And yes, at least the Ruby RDF library omits null values.

[lecoqlibre]

Stock policy proposal

Let's take an example with 10 orders each of one tomato while stock limitation is set to 5:

Stock policy	Behavior	Resulting stock
Platform 1: does not manage stock (NONE or UNLIMITED).	Accepts the 10 orders.	N/A
Platform 2: allow negative stock (PERMISSIVE).	Accepts the 10 orders.	-5
Platform 3: deny negative stock (STRICT).	Accepts the 5 first orders, deny the 5 next.	0

If the user wants to manage stock, all the platforms he is using must support this feature. If this feature is missing in a single application, the entire chain is broken.

For instance, suppose the user wants to manage stock while using the three platforms, what will happen when 5 orders will be sold on Platform 1 in the first place and 5 other orders will be sold on the Platform 3 after? The Platform 3 won't know that the stock is already 0 and will accept to deliver the orders but there is no product left. The same thing will happen in the opposite direction: the Platform 3 sells 5 orders before the Platform 1 which is accepting orders whatever happens.

The ontology should probably support what could be named "stock policies" (what I previously showed as NONE, UNLIMITED, PERMISSIVE and STRICT).

The choice of the stock policy should be made by the users: do they want to manage stock and how.

But that's not sufficient. If we want the DFC applications to be consistent, they should support these different stock policies.

I think this problem clearly illustrates the limits of ontology. Here, the standard must take over and instruct platforms to support different stock policies.

[RaggedStaff]

Thanks @lecoqlibre

I think agree with your analysis of the different stock policies... although I'm a little unclear on the functional difference between NONE/UNLIMITED and PERMISSIVE. 🤔 Why couldn't we just have (effectively) an on/off toggle for stock (or stipulate a specific value that the platforms should interpret as NONE/UNLIMITED/PERMISSIVE (either -1 as I suggested or and empty value as @Alcoz suggested) ?

I don't think I agree that we need to require platforms to enforce all of these stock policies. As you say - the choice should reside with the User, and if they choose to use a platform that doesn't support Inventory Management, that's their choice. Can we not simply require platforms that don't manage stock to set all stock limits to the UNLIMITED value ?

[mkllnk]

I just remembered another stock policy I have been working on. It's not the Open Food Network app and we don't have to support that now but a similar system distinguishes between three different stock policies of products in the database:

• Regular: simple stock on hand. Used for bulk items.
• Available in future: simple stock on hand for the next few days but assumes unlimited after four days because items are frequently restocked. For example veggies. You can only get 20kg of potatoes today but whatever you want next week.
• Daily stock: One stock level for each day. For example bread is delivered daily in batches of 30 loafs.

Just mentioning it here because we want to be open to these systems. But I guess that any of this can be expressed as daily stock level with one-day sale sessions attached to the offers with stock limitation. In that case we don't care about the logic in the data model, we just need to model the result.

[RaggedStaff]

Just noting that within FDC, in the absence of a StockPolicy, we are implementing a work around for this:

We are considering any negative stock value (<0) as PERMISSIVE/UNLIMITED and using the value -1 to communicate that across the network.

[RaggedStaff]

Flow Diagram available here

[lecoqlibre]

Thank you, I paste the diagram here for the record:

[mkllnk]

Just to confirm that I understand this: permissive stock allows negative stock, right?