h3. Background/Intro:

* The order dispatch process is supposed to work as follows:
* Order is invoiced (once EFT comes in or credit card success), and goes to status Processing
* Once fully stocked, appears in "Full stock orders" in ERP->order processing, and can be "selected" by selecting individually or using "Add all Full Stock Orders to selection" button
* "Picking list" button will print picking lists, invoices, etc. for selected orders, and also change their status to Packing, and reassign them to operator (user account) "Packing". These settings are in system->config->erp->order preparation->picking list
* "Dispatch orders" button allows orders to be dispatched, by scanning them, as per code in vendor/silvertree-capital/magento-embedded-erp/app/code/local/Silvertree/MDNOrderpreparation/controllers/DispatchOrdersController.php:
** There's a dropdown to force a specific courier, else the system will use the current courier for the order
** Barcode scanning is asynchronous, i.e., you can scan multiple orders, and these will each trigger an AJAX request to server and be handled appropriately
** If the courier has isShippingLabelsAvailable() true (see below), then it will submit the waybill via API and store tracking number (we send our order number as tracking number to the courier, rather than ask them for one)
** If the courier has isShippingLabelsAvailable() false, then it pops up a dialog to manually request waybill number
** If the courier needs additional data (e.g., Citisprint asked for weight and dimensions for packages) there are rudimentary hooks to add these forms. See the commented code in vendor/silvertree-capital/magento-sa-couriers/app/design/adminhtml/default/default/layout/silvertree_citisprint.xml, and the file it points to – the "magic" pieces are the class and ID of the div in the packaging.phtml. For now this isn't needed for any of the current couriers (given that Citisprint has delayed their API work)
** In each case, once waybill is known, the system creates a shipment for the order, saves the tracking number, and notifies the customer
* If the above shipment creation is the entire order, then defaut Magento behavior will change order state to "Complete"; if not, then custom behavior will change order status to "Partially shipped"

h3. To-do:

* Test this process works as described above
* There are various scenarios that can be constructed and then tested
* In each scenario we assume that some issues or bugs will crop up
* Test each courier, including the API integration, parcel tracking, and what happens if e.g., API call fails (needs to handle gracefully, i.e., tell user that call failed and NOT ship order).
* Test paper waybill mode (a checkbox on dispatch orders page)
* Check exceptions such as ship an order twice, ship an order that isn't in "Packing" status, etc. These should not be allowed to happen.
* Test partial order fulfilment – select an order from "Stockless orders", then picking list and dispatch the order. It should create a shipment only for the products that were in stock, and leave the order in status "Partially shipped".
* Check that if isShippingLabelsAvailable() is false, then there's a window for manual waybill number entry; make sure that clicking "Cancel" cancels the order submission and doesn't create shipments, etc.