Some years ago I wrote a lovely bit of software to that allowed us to gain much more control over the way that orders are handled by the warehouse at despatch.
Once an order is sent to the "Warehouse" Batch a custom windows service prints off a pick list for that order or sends the order to a "Pending Stock" batch if it is awaiting allocation of more goods due to pending purchase orders or stock shortages. The order is checked for weight and manual handling warnings are printed on the pick if any item requires special handling as does notice get applied should there be hazodous chemicals or problems with air frieghting the item. The picklist is then added to a despatch screen as awaiting picking and fulfilment.
The operative takes the pick list from the printer and goes off to pick the order (version II was always intended to feed the virtual picklist to PDA's that the staff would carry, not got that one done yet!). Once they have the pick complete, the items are weighed and they then scan the barcode on the picklist at the despatch terminal. The terminal asks the user for the weight of the consignment cartons/boxes and the dimentions if they are exceptional or for export. The wizard then asks for the picker, checker and despatcher names for that pick. Finally it caculates the best carrier for the consignment depending on the weight, if the order has none stock items (thus would be delay if item was to be lost in normal post), if the value of the consignment is over a threshold, the time of day (to catch the next carrier arriving), dimentions are checked for those supported by different carriers, including if the consignment is on a pallet. The soup is stirred and a service and carrier selected to get the items to the customer by the time they requested.
A despatch note is printed by the despatch terminal and tracking numbers are obtained from the carrier systems, and labels printed off for the parcels, and xml sent to the carrier machines so they know all about what they have to deliver.
It automates much more such as preventing duplicate despatches, taking notice of process holds and customer credit issues, charging Credit cards if they were applied to the order, its great!
However I've another company implemenation to do over the next couple of weeks, we are putting Dynamics GP into a computer periferal company that we aquired. Although they have very similar requirements to those already existing they also add in the complexity of a trade counter operation. This means the software now needs to support sales staff at the counter fulfilling orders, producing invoices etc. Cool - I like a challenge. Thus I've cracked open the solution file and started having a look at how it all works again as a refresher to see what needs adapting for the next implementation. Now I've realised that times have moved on with GP and .NET. We now have the WCF and the WPF to help me out together with better webservices in GP. All this application is direct to table, which was the only way to go when it was written, econnect was an arm and a leg and laden with bugs. Now it is a mature affordable soution - thanks MS!
Thus I start thinking about where to go as I also have to think about multiple binning that was never used in the old implementation. This is where you have stock held in multiple locations in the warehouses and set priority for where the stock should be drawn from. Useful if you wish to keep bulk stock up a height and draw it down to accessable locations further down the racks. This lead me to a blog of interest http://scruffylookingcatherder.com/archive/2008/01/03/custom-dynamics-warehousing.aspx where Jacob sounds he is in a similar suituation to my own using similar technology sets to solve the problems. Jacob also has some interesting posts on development to read.
Now I just need to get my skates on and work out how to get my application working for next week....