68 lines
2.4 KiB
ReStructuredText
68 lines
2.4 KiB
ReStructuredText
|
|
Customer Order Overview
|
|
=======================
|
|
|
|
Here we offer a general overview of the "customer order" features
|
|
provided by Rattail.
|
|
|
|
|
|
Rationale
|
|
---------
|
|
|
|
There are many potential scenarios, where it may be helpful to track a
|
|
customer order. Basically that's exactly what a POS system does,
|
|
albeit a particular type of order (immediately fulfilled).
|
|
|
|
Often another particular type of order (case/special orders) is *not*
|
|
tracked very well, if at all, by the POS system. There may be other
|
|
types of tracking that is needed to help with basket picking and
|
|
curbside delivery, warehouse fulfillment, etc.
|
|
|
|
So the thinking is that we just call all those "customer orders" and
|
|
use common schema and logic to track them, to the extent possible.
|
|
|
|
|
|
Objectives
|
|
----------
|
|
|
|
Short version:
|
|
|
|
#. common schema
|
|
#. common logic
|
|
|
|
The schema for customer orders should be generic and useful enough to
|
|
accommodate the various scenarios needed. Obviously each order has a
|
|
customer assigned to it, and it has one or more items (products) being
|
|
ordered. Any new "common" scenarios which require additional
|
|
attributes to be tracked on the order and/or items, should probably
|
|
require the Rattail schema to change. Any new "esoteric" scenarios
|
|
needing extra attributes should require custom schema extensions.
|
|
|
|
The logic for customer orders may vary in lots of ways for different
|
|
scenarios, but certain things will likely come up in several places,
|
|
and so the logic should be shared where it makes sense.
|
|
|
|
|
|
Strategy
|
|
--------
|
|
|
|
We assume you already have a POS with customers and products. It of
|
|
course handles the normal scenario of POS transactions, e.g. a
|
|
customer grabs a root beer from the shelf and then walks to the
|
|
cashier and pays for it.
|
|
|
|
But when that customer wants to order a case of root beer, and come
|
|
pick it up next week after the truck comes in, is often a different
|
|
story, and that scenario is "handled" by way of post-it notes and
|
|
maybe an Excel spreadsheet thrown in somewhere...
|
|
|
|
Rattail's customer order system can help with that. It is generally
|
|
able to talk to other POS systems which means it can present customer
|
|
and product choices for a user entering a new order to the system.
|
|
Once the order is entered, it can be updated as needed via some
|
|
workflow(s).
|
|
|
|
At this time only the "case/special order" type is supported by
|
|
Rattail proper. Other types may be supported in the future; however
|
|
any project can establish other types and support them as needed.
|