Order Partitioning

From Wiki-eostar.com
Jump to: navigation, search

Order partitioning is the splitting of an invoice into multiple orders. This can happen for multiple reasons, the most popular being that the customer requires it - such as when alcoholic and non-alcoholic goods need to be separated.

Salespeople can enter an order either on the handheld or through eoStar's Order Entry Screen. The handheld devices can automatically partition the handheld invoice into multiple invoices based on the items purchased. The pre-sell or tel-sell order entry screens in eoStar will enforce that products that would normally be partitioned do not get entered on the same invoice.

For more information, see Overview: Payment Terms.

Orders may be partitioned when:

  • Different Payment Terms for the types of products on the invoice. The payment terms are defined on a per customer basis on the Customer Terms Panel under the heading Payment Terms. If the check box Require Separate Invoices Based On Payment Terms is checked, then different product types will be paid for using a different payment term.
  • Different delivery trucks for the different Product Classes of the items on the invoice (i.e. one driver can only deliver kegs, and one driver can only deliver cases).

Partitioning Issues

In March 2010, an issue appeared wherein promotions were not appearing for pre-sell orders through mobile devices. The issue was caused due to the fact the order was partitioned into two parts based on the payment terms and their related product sets. Each partition had the proper date that the user would see alongside the driver's name on the pre-sell order screen. However, since there were two partitions, the "Shipped date" on the order as a whole simply defaulted to "tomorrow"; therefore, the promotion didn't go into effect until some day thereafter. This meant that the pre-seller could not see the available promotion and pricing on the order when the order was viewed as a "whole" due to the partitions.

The issue described above was rooted in the assumption that if there was more than one partition, then any date chosen for the "Shipped date" on the order as a whole could not be guaranteed to be correct, so it chose "tomorrow" rather than a delivery date specific to some arbitrary partition.

However, this issue is a symptom of the more general problem introduced by partitioning. Consider the example below where multiple drivers are involved, each getting a portion of the "whole" invoice based on truck restriction partitioning:

Order partitioning issues.jpg

Note that CASE DRIVER is set to deliver on 3/29, but SODA DRIVER delivers on 3/30. If you were to inspect the individual partitions via the info icons, you would see that pricing and promotions are based on the dates of delivery. However, it is still the case that we need to choose some ship date to use when displaying the order as a "whole" to the pre-seller. If we choose 3/29, then the pre-seller might not see a promotion that only becomes available on 3/30. If we choose 3/30, then the pre-seller might inappropriately see a 3/30 promotion applied against items that are on the CASE DRIVER's 3/29 delivery. This is essentially an inescapable problem which we must suffer as a result of providing the pre-seller with the true benefit of being allowed to "type in one order for all of the stuff."

To fix this issue, now, if there are multiple partitions involved when re-computing an order's pricing/promos, it now chooses the minimum date among the delivery dates on those partitions. This solution will be correct almost all of the time, due to the fact that the problem described above only arises if there are multiple drivers involved with the partitions, and only if each of those drivers is scheduled to deliver on different days.