Customer Order Workflows

At time of writing Rattail only supports one workflow for customer orders, and that is the “case / special” order scenario. We expect at some point there may be others, e.g. to assist with basket picking and curbside delivery etc.

Case/Special Orders

To be clear, this is the sort of scenario we’re talking about here:

  • Customer walks up to the cashier and says they’d like to order a case of root beer.

  • Cashier says yep we can probably get that in by late next week.

  • Cashier jots down a note etc. to inform the buyer of need to add a case of root beer on their next order to the vendor.

  • Truck arrives next week and case of root beer is set aside, customer is notified via phone call or possibly email.

  • Customer comes in and picks up the root beer.

Now, somewhere in there the customer needs to pay for the case of root beer. More on that later.

Entering a New Order

Entering a new order is essentially the same regardless of order type:

  • initiate a new order

  • select customer record, or enter new one

  • select one or more items, and/or enter new ones

  • submit the new order

Initiating the order is done automatically when user visits the New Customer Order page.

User then must select an existing customer record, or enter minimal details for a new one to be added to the system. Note that an “unknown customer” (i.e. one not yet in the system) is not considered a “problem” and will (generally) not inhibit the order from advancing in its workflow.

Products work the same way, user either selects existing or can enter minimal details for new one(s) to be added to the system. Note however that in many cases, an “unknown product” is considered a “problem” and may inhibit the order from advancing in its workflow.

Batch Implementation

Rattail internally uses a batch to track the new order. When that batch is executed, it becomes “real” by way of conversion to a proper customer order.

So when the new order is “initiated” (as mentioned in previous section), really a new batch is created. When user selects customer and products etc. the batch is updated. When user clicks “Submit this Order” button then the batch is executed.

Note that the batch makes it possible to use the New Customer Order screen to build an order which in fact will be submitted to some other (e.g. non-Rattail) system for further tracking. One need only configure a custom batch handler and override the execute() method to do whatever is needed with the final order data.

Order Item Status

When the order is first submitted, each item on the order will be given “initiated” status.

The item’s status should be updated as its workflow progresses. It generally should be possible to manually change status for an item, but certain workflow-specific interfaces (web pages) may provide tools to make some status changes more convenient etc.

See the rattail.enum module, specifically CUSTORDER_ITEM_STATUS, for all possible values, unless you’ve overridden that for your project. Here are some of the more common status values an item may go through in its life:

  • CUSTORDER_ITEM_STATUS_INITIATED

  • CUSTORDER_ITEM_STATUS_PLACED

  • CUSTORDER_ITEM_STATUS_RECEIVED

  • CUSTORDER_ITEM_STATUS_CONTACTED

  • CUSTORDER_ITEM_STATUS_DELIVERED

Receiving Payment

We’ve mostly avoided talk of payment thus far, but it needs to happen. Some stores will have different perspectives on this but they can probably be boiled down to just two types: either payment is required up-front (e.g. before buyer will order the product from vendor), or it’s required at the end when customer picks up product.

To work well, this requires that Rattail have access to the POS transaction data, so it can check transactions for customer order payments. This of course also requires such customer order payments to be “marked” in some way within the POS transaction, to make it clear which order is being paid for etc.

Payment Required Up-Front

If payment is required up-front then probably that means, after the order is first submitted, its status remains “initiated” until payment is confirmed to have been received, at which point the buyer is cleared to add the item onto their next vendor order.

In this case we can make use of the CUSTORDER_ITEM_STATUS_PAID status, which logically sits between INITIATED and PLACED. Buyers then would only “see” the orders with paid status, when looking for things to add on their vendor order.

To work well, this requires that Rattail have “real-time” access to the POS transaction data. If a customer places new order at 1pm, and pays for it, and buyer is placing vendor order at 4pm, it would be a shame if they didn’t “see” the new order b/c payment hadn’t yet been processed…

This also poses the problem of, how to accurately ring up the various items on the customer order, in a POS transaction. If payment happend at the end then cashier can simply scan the product which is physically present. Whereas “pre-payment” may require a paper printout of the item scancodes needed, which is then scanned at POS by the cashier when taking payment.

Payment Required at the End

If payment is required at the end then things get simpler, compared to payment up-front.

After the order is first submitted it will still remain “initiated” but in this case that is precisely what the buyer will see when doing their vendor order thing.

Rattail will still need access to POS transaction data, but it doesn’t have to be real-time, it can process the day’s transactions overnight if that’s easier, because there is no urgency to the final status update.

A payment within a POS transaction will still need to be marked clearly so that it is attributed to the correct order etc. But as mentioned above, the cashier can simply scan the physical items present, so there is no question of “how” to ring up the items.