Special Orders as presented in CORE are a mechanism by which a customer can place an order for an item, wait for the co-op to order the item, and then pick up the item. Common uses include when the customer wants an item that the store does not normally carry or the customer wants a large quantity. The special order system has some degree of flexibility but the following assumptions are currently included:
- Customers are ordering items by the case. Pricing is entirely editable but the initial pricing calculated will be based on case size. For some vendors the case size may be a single item.
- Customers will pay for the order when they pick it up.
Configuring Special Orders
There are a few options that may require attention before you begin creating orders. First is departments (site map: Special Order Departments). This tool has two uses. First, you can create a mapping such that items in one POS department will be transferred to another POS department when added to a special order. This only works for items that the store carries and have POS department numbers. The main use is for accounting if there are a special, separate set of department numbers for special orders. The other use is setting minimum quantities on departments. When the minimum quantity is greater than zero, a user entering an item in that department will be prompted to specify a quantity. This can be useful with vendors that allow for partial or split cases.
The next stop is Batch Types. The batch type editor has a column named SO Eligible. If an item is on sale in a Special Order Eligible batch it will be added to the order at the sale price rather than calculating any form of discount. This setting is not relevant on non-sale, price change batches.
Next, the Special Order Discounts page defines pricing rules for each member type. The choices are mark up from cost and mark down from retail. Either is specified with a percentage (and zero is allowed). If an item retails for $10, using 10% mark down from retail will price the item at $9. If an item costs $5 then using a 50% markup from cost will price the item at $7.50.
Finally, there's a specific user permission related to special orders. All users with a valid username and password are allowed to create special orders. However, these users will not see any price related information. Only user accounts assigned the special order permission class will be able to see and edit an items price in the order.
Special Order Pricing
Special Order unit pricing works as follows:
- If the item is set to non-discountable then the unit price is simply the retail price.
- If the item is on sale, the sales batch is SO Eligible, then the unit price is the sale price. With member only sales this only applies if the customer is a member.
- Otherwise the unit price is calculated from the retail price or cost based on the mark up or mark down rule associated with the customer.
The unit price is then multiplied by the case size to arrive at a case price. The pricing generated by the special order system is entirely editable but customizing settings to get as many scenarios right as possible will minimize mistakes as well as time spent managing orders.
Entering Special Orders
A special order has two key components: a customer and one or more items being ordered. Entering a member number will fill in all contact fields; for non-member orders they must be filled in manually. When entering a member order, any contact field may be overridden but these are not permanent changes.
An order must include one or more items. An item entry is taken as a "case" although for some items and/or vendors a case may be a single item.Items may be added in a number of ways:
- By entering a UPC or vendor SKU. Items in vendor catalogs but not normally stocked may be ordered this way.
- HABA items always prompt for a quantity because case sizes are often very small. This needs to be configurable.
- By entering a non-numeric UPC. The user will be prompted to choose a department. This option is rarely used.
- By entering a Note in the larger input field describing what the customer wants.
The order must include a POS department number somewhere. This can be one of the line-item entries, or the department selection adjacent to the Note field. Categorizing the order ensures some particular person is responsible for it on the back end.
Any logged in user can enter an order, but only a user with specific permissions can see pricing details. Often this means the person taking the order cannot give the customer an immediate price. This works OK for WFC. Having the buyer (or other final pricing decision maker) call the customer with a guaranteed correct price is preferable to giving out inaccurate information.
Buyers can view a list of all pending orders. Orders can be filtered by super department, status, and vendor. The default statuses are:
- New, No Call means the customer does not want a confirmation phone call. The order can be placed immediately.
- New, Call means the customer wants a confirmation call.
- Called/waiting means the customer was called but didn't answer and the buyer is waiting for a return call.
- Pending means the order is ready to place but has not actually been placed. Orders rarely hit this status unless there's a supplier issue like out-of-stocks.
- Placed means the item(s) have been ordered from the vendor(s).
- Arrived means the item(s) are delivered and in the store.
Statuses are not currently configurable. The two New statuses must exist to support the "call to confirm" selection. Called/waiting ties into automatic closing (see Miscellaneous below). The others could be configured or edited without much issue.
Initial back end processing involves converting any Notes to actual items and/or verifying pricing on entered items, contacting customers as needed, and placing orders with vendors. When items arrive, an employee must Print Tags. Tags are a quarter sheet of paper size with basic order info and a scannable barcode. Tags are taped to items to assist cashiers in ringing them up as well as the employees who need to locate items in back stock and bring them to the front end. An order with both status=Arrived and printed=yes is ready for pick up.
Orders can be cloned, but there's currently no mechanism for an automatically recurring order.
On orders with more than one item, individual items can be split into separate orders. This often happens if items on a single order belong to different buyers, or if items on a single order have different supplier availability.
Items will shift from pending orders to completed orders over night but only if the clerk scans the order tag. An order is not considered completely closed until all its items have been picked up. An order with multiple items can sometimes appear simultaneously in both pending and closed orders with some line items on each.
Orders with status Called/waiting will automatically close after 30 days. Pending orders with any status will automatically close after 90 days.
Three additional statuses appear in closed orders: Completed, Canceled, or Inquiry. These are selected when manually closing a pending order.
Administrator / Developer Considerations
Under the hood special orders operate kind of like a partial suspended transaction. When a cashier scans a special order tag, POS is looking up that particular line item of the order and adding it to the transaction as-is. If you look at special orders in the database they have a nearly identical structure to transaction logs. This provides a lot of control over exactly how a given item will ring up. The tags are considered a type of Special UPC and must be enabled on the lane's Scanning settings or they won't ring up (same place as coupons & house coupons).
Orders are only shifted from pending to complete when all their items' tags have been scanned & sold. The Special Orders task is responsible for marking orders as complete. Open ringing an item instead of scanning it means that order will hang around in the pending list until the 90 days limit (although as long as this isn't happened regularly it's not a big deal).
By default, barcoded items' special orders will be logged using the same UPC as the same individual items. In other words cases sold as special orders will be reflected in movement reports. The transaction record's ItemQtty field lists the number of cases sold and the record's quantity field lists the number of items per case. SPINS reporting is cognizant of this and will adjust quantities appropriately. It's important to fill in the correct case size if vendor catalogs are not available to provide it automatically or it will appear to SPINS as if a single unit was sold at the price of a whole case.