Supply Chain Ordering Lead Time

This is one of the possible Use Cases.

1. Abstract

This is a use case about policies for ordering lead time in supply chain management. A vendor/seller shares its policy rules about lead time with their prospective customers/buyers. (By BenjaminGrosof)

It illustrates the reusability of such info across vendors/sellers and customers/buyers. It also illustrates the usefulness of being able to represent prioritized default rules in the manner of the Courteous extension of declarative logic programs. And in its further-extended/longer version with action rules, it further illustrates the usefulness of being able to represent action rules in the manner of the Situated extension of declarative logic programs (which combines fairly orthogonally with the Courteous feature).

2. Status

This use case is submitted by BenjaminGrosof.

It's still undergoing some editing.

This example is taken from the paper "Rule-based Policies across Multiple E-Services Tasks, using Courteous Logic Programs in RuleML, SWSL, and SweetRules" by Benjamin Grosof, Chitravanu Neogy, and Shashidhara Ganjugunte, available at: http://ebusiness.mit.edu/bgrosof/paps/policy-rules-for-sws-v4.html .

The description here is modified to be closer to the requested use case template for RIF, but the rules are unmodified.

The example first appeared in this form in the SWSF design report

-> Application Scenarios document
- -> section on Policy Rules for E-Commerce.

(http://www.daml.org/services/swsf/1.0/ -> ...). Earlier similar versions appeared in an EC-99 conference paper, the SweetRules V2+ download examples, and the IBM CommonRules V1+ download examples.

A longer version of the example, and extensive discussion, is in the paper "Representing E-Commerce Rules Via Situated Courteous Logic Programs in RuleML", a preprint version of an ECRA journal paper, at http://ebusiness.mit.edu/bgrosof/#ecra-sclp-ruleml. That paper, in its Example 4, includes in particular an extension of the example/scenario/use-case in which action rules are used to specify side-effect-ful notification/business-messaging from the seller to the buyer about the lead time status of placed/modified orders.

That paper, in its Example 3, also includes an analysis of how using the Courteous feature is advantageous as compared to an alternative variant in which the policy is represented using rules that have only the default-negation construct (negation-as-failure) but not the Courteous feature.

The rules are given in the RuleML/SWSL presentation syntax. A primer on that syntax is given below as an appended section, is also in the above paper, and full details about it are in the above SWSF design report.

Implementation:

This example has been implemented in SweetRules V2 (and in earlier form, in IBM CommonRules).

Frequency/importance in real world:

This is a very common and important kind of policy in real-world commerce, both electronic and non-electronic.

3. Benefits of Interchange

The buyer and seller can communicate in a precise, informative, and automated fashion, about an important aspect of e-selling/e-procurement: ordering lead time policies.
They can use different rule engines/languages. E.g., a production rules systems or Prolog systems.
The ordering lead time policy rules are reusable across multiple tasks in e-contracting and supply chain management including: advertising, vendor selection, manufacturing/retailing/supply planning and scheduling, contract formation, and contract performance/monitoring (e.g., for umbrella contracts covering a flow of orders between persistent business partners).
The buyer can reason automatically with the policy rules as part of evaluating the prospective value of the proposed deal. The buyer can avoid having to have human(s) read the policies in natural language text and then integrate that understanding into procurement/purchasing decision-making.

Which Rule Systems Supported:

The Courteous LP feature is supported in RuleML/SWSL, SweetRules, and IBM CommonRules (and its BRML). SweetRules implements it on top of / in Jess production rules and/or XSB Prolog rules, by i.e., by translating to and from those via a "courteous compiler" component.

SweetRules includes an open source such courteous compiler component.

4. Requirements on the RIF

The use case shows the desirability of declarative prioritized defaults in the manner of Courteous Logic Programs. The advantages include modularity to add new rules, e.g., that represent special cases / exceptions.
The prioritized defaults here involve in particular an integrity constraint that one should conclude at most one value of the ordering lead time for a given item.
The use case, in its further extended/longer version (in a referenced paper) shows the desirability of representing action rules in a declarative, easily-combined fashion -- in the manner of Situated (or, a bit more generally, Production) Logic Programs.

5. Breakdown

5.1. Actors and their Goals

A seller/vendor wants to share rules about supply chain ordering lead time policies with a set of prospective buyers/customers. The buyer and seller can be using different rule engines/languages. These same rules can be used in advertising and also in contract proposals, agreed-upon contracts, and post-agreement monitoring of contract compliance/performance, and planning/scheduling of manufacturing/retail/distribution processes by buyers and sellers.

5.2. Main Sequence

This is a typical example of a part supplier vendor's (here, Samsung supplying computer equipment) lead time policies as a set of rules. These rules are useful in advertising, and as part of a contract (proposed or final), and as part of contract monitoring / exception handling (which is in turn part of contract execution). In B2B commerce, e.g., in supply chains (especially in manufacturing), sellers often specify how much lead time, i.e., minimum advance notice, is required when a buyer places or modifies a purchase order. Such policies about ordering lead time are also used heavily for planning and scheduling aspects of supply chain management, including in both manufacturing and retailing/distribution, by both buyers and sellers.

In the main sequence scenario:

The seller posts the ordering lead time policy rules on their website, or sends in a message to a prospective buyer (e.g., a quotation/contract-proposal or an advertisement).
Various buyers get the ordering lead time policy rules and reason with them as part of making their decision about whether to place orders or modify previous orders.
Some buyers do indeed place such orders or modify previous orders.
The rules determine whether those orders are allowed, versus disallowed because they violate the ordering lead time, depending on the circumstances.

The first policy rule says "14 days lead time if the buyer is a preferred customer". This might be authored by the marketing part of the seller's organization. The second policy rule says "30 days lead time if the ordered item is a minor part". This might be authored by the financial accounting part of the seller's organization. The third policy rule says "2 days lead time if: the ordered item is backlogged at the vendor (i.e., the seller is having trouble fulfilling its overall set of existing orders), and the order is a modification to reduce the quantity of the item, and the buyer is a preferred customer". This might be authored by the operations part of the seller's organization. The third rule is given higher priority than the first rule, say, because operations' authority (about lead time) is greater than that of marketing. A mutex says that the lead time is unique per purchase order.

/* ordering lead time policy rules */

{leadTimeRule1} orderModificationNotice(?Order,days14) :-

preferredCustomerOf(?Buyer,?Seller) and purchaseOrder(?Order,?Buyer,?Seller).

{leadTimeRule2} orderModificationNotice(?Order,days30) :-

minorPart(?Order) and purchaseOrder(?Order,?Buyer,?Seller).

{leadTimeRule3} orderModificationNotice(?Order,days2) :-

preferredCustomerOf(?Buyer,?Seller) and orderModificationType(?Order,reduce) and orderItemIsInBacklog(?Order) and purchaseOrder(?Order,?Buyer,?Seller).

overrides(leadTimeRule3,leadTimeRule1).

!- orderModificationNotice(?Order,?X) and orderModificationNotice(?Order,?Y) | notEquals(?X,?Y).

/* some "case" facts about particular purchase orders */

purchaseOrder(po1234567,compUSA,samsung). preferredCustomerOf(compUSA,samsung).

purchaseOrder(po5678901,microCenter,samsung). preferredCustomerOf(microCenter,samsung). orderModificationType(po5678901,reduce). orderItemIsInBacklog(po5678901).

The above premises (policy rules and case facts) together entail the following conclusions about the ordering lead time for the particular purchase orders po1234567 and po5678901.

/* the entailed lead times for the particular purchase orders */

orderModificationNotice(po1234567,days14).

orderModificationNotice(po5678901,days2).

5.3. Alternate Sequences

The use case is straightforwardly extended, by adding action rules, to actually do notifications or payments via side-effect-ful procedural attachments triggered by the rules. This can use action rules cf. the Situated (or, a bit more generally, the Production) extension of LP, which can in turn be implemented on top of / in Production Rules or various other rule systems.

A longer version of the use-case/example, and extensive discussion, is in the paper "Representing E-Commerce Rules Via Situated Courteous Logic Programs in RuleML", a preprint version of an ECRA journal paper, at http://ebusiness.mit.edu/bgrosof/#ecra-sclp-ruleml. That paper, in its Example 4, includes in particular an extension of the example/scenario/use-case in which action rules are used to specify side-effect-ful notification/business-messaging from the seller to the buyer about the lead time status of placed/modified orders.

6. Narratives

6.1. (Title of Narrative)

7. Commentary

Considerable commentary was given above, already.

More relevant commentary is in the paper "Rule-based Policies across Multiple E-Services Tasks, using Courteous Logic Programs in RuleML, SWSL, and SweetRules" by Benjamin Grosof et al, from which this example is taken (http://ebusiness.mit.edu/bgrosof/paps/policy-rules-for-sws-v4.html). Please see the Abstract and Section 1 there.

7.1. PRIMER on RuleML/SWSL presentation syntax for CLP:

Next, we give a quick primer on RuleML presentation syntax, to aid the beginner to read examples of policies, in particular to read those in the next section and in the Policy Rules for E-Commerce section of the SWSF Application Scenarios (mentioned above). Full details of this presentation syntax are given in the SWSL (i.e., SWSF Language) document. But that's rather long and technical, so it's useful to have this primer. Note this primer only covers/treats part of the overall presentation syntax.

Next we describe some key syntactic constructs:

"?" prefixes a logical variable. ":-" is the implication connective. It means "if". Thus head-expression :- body-expression means "head-expression if body-expression", i.e., "if body-expression then head-expression". Note that a rule can be simply a fact; in this case, the body expression is empty/absent, and the ":-" connective can be (and usually is) omitted. "." ends a rule statement. "{...}" encloses a rule label. The rule label precedes the rest of the rule. Such a label is essentially a a name for the rule; it is used as a handle for specifying prioritization. "overrides" is a special predicate that is used to define prioritization between rules. overrides(lab1,lab2) specifies that any rule having label lab1 has higher priority than any other rule having label lab2. "!-" begins a mutex, i.e., a mutual-exclusion integrity constraint statement. !- can intuitively be read as "It's a logical contradiction if". In such a mutex, "|" can be read as "given that". "neg" is the classical negation connective. It means "not". Intuitively, "neg p" means that p is believed to be false. By contrast, "naf" is the negation-as-failure connective. It means "not believed". Intuitively, "naf p" means that p is not believed to be true. It may be that neither "p" nor "neg p" is believed, i.e., that the truth value/status of p is unknown. "naf" is thus weaker than "neg". For those less expert in the technical aspects of rules, it can be confusing to employ both "neg" and "naf" in the same rule or ruleset, so it is often helpful to employ (explicitly) only "neg" when writing rules.