Receiving

Assuming that OrderProducts were added to a purchase order, eventually they should be delivered to the organization. Usually this would be cause for further workflow actions on the OrderProduct(s).

The Basics

More than likely the following at least is needed:

The OrderProduct is marked as physically received.
An OrderProductEvent is created to log who received the product.
The product is set aside for the customer.
The customer is contacted.

Status Update

All OrderProducts which are delivered as part of a purchase order will need a status update to reflect their physical presence in the shop. If a BuyerClaimBatch was created then all such status updates may occur in one fell swoop via the claim batch. However it's of course possible that some of the products expected did not get delivered; such products should obviously not be marked as received.

Any OrderProduct which did not arrive must get a different status update, depending on its situation. It may be that the product was merely out-of-stock from the vendor and should be re-queued so another purchase attempt may be made. However sometimes such products are continually not available, etc., and the customer may prefer to simply cancel their order. They should probably be consulted to determine this. Anyway the process might be like:

The BuyerClaimBatch is identified within Rattail.
Any OrderProducts not received must be updated according to their situation.
A "not delivered" OrderProductEvent is created for each of the above products.
All OrderProducts which were received must get OrderProduct.status set to "physically received" or similar.
A "physically received" OrderProductEvent is created for each of the above products.
BuyerClaimBatch.status might also be set according to need.

Purchase Orders

If a purchasing system is in effect, then a PurchaseOrder probably exists in the system already, and could also be used in updating the OrderProducts' statuses if desired. It also would need some workflow of its own though most likely; that documentation will be elsewhere.

Order Ticket

It will typically be advantageous to print out a ticket or sticker of some sort to physically attach to the customer's product. This will include data such as a unique identifier for the OrderProduct, as well as the customer's name and phone number, product PLU and price (with discount if applicable), etc. Of course the specifics of that could vary.

Product(s) Held

The product will usually be held for the customer for some amount of time at least. Of course some shops might deliver the product to the customer, but this workflow may be biased in its assumption that the customer will be responsible for visiting the shop in order to pick up their product(s).

Some shops will enforce time limits of some sort, such as, "Product will be held for two weeks from delivery date, after which it will be placed on the shelf for general sale." These rules will probably vary significantly and are left to the shop to determine, along with any accompanying workflow with regard to the order system.

Customer Contact

Since the customer is assumed to be "expecting" their product(s) to arrive at the shop (and perhaps they even expect it at a certain date/time), the customer should probably be contacted regardless of the situation with regard to their product(s). We'll assume though that the product(s) did in fact arrive intact, and the customer will simply be notified that they can come in and pick it up, or they may be consulted to establish a delivery schedule, etc.

Some shops might be able to simply email their customers with these status updates automatically. Others will need someone to call the customer's phone number and speak to them or leave a message, etc. It's up to the shop to determine how the customer should be contacted and when. (Does the receiver call the customer immediately when coming across the customer's product, or does a customer service representative do it later, etc.?)

One primary consideration here might be to reduce the number of contact attempts which are made. For example, if the customer has ordered several different products which happen to exist on the same purchase order for the shop, whenever that purchase order arrives care should perhaps be taken that the customer isn't also contacted several times when really one would suffice.

The other consideration (which is related) is how to log the contact attempts. Automated attempts are easy; "manual" phone calls may be more difficult to consistently log if those responsible for attempting the contact do so in a very distributed manner. Strictly speaking of course it's not even necessary to log them, but it would surely be beneficial.