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....
Just a note if you use the Nolan Computers Credit Control module for Dynamics GP.
We just went to apply the SP3 release to our clients and server only to find that it caused issues with Nolan credit windows.
As it happens we had been considering migrating to the native module now available with GP, so we have now got the keys for the native module and will be moving to that in the near future. I will cover that when we get to it. Aparently there is no migration wizard...
I'm certain a new release of Nolan will be available in a few days to cover SP3 so contact them if you want to keep using the product. We'd rather jump ship to the natively supported version and be carried along for the ride with whatever enhancments come our way. I doubt there are any plans to do much work with Nolan with the native verion now available.
An event I wish I could attend, please bring it to the UK!
Technical Airlift 2008
Microsoft Dynamics GP Technical Airlift Scheduled for May 28 - 29, 2008
Mark your calendars and plan to attend the Microsoft Dynamics GP Technical Airlift in Fargo, on May 28 and 29, 2008.
The Technical Airlift is designed to deliver advanced technical skills around Microsoft Dynamics GP 10.0 for the roles of consultants (both sales and implementation) and developers.
Implementation consultants will see this as a great opportunity to take their knowledge to the next level on some of the more advanced topics of Microsoft Dynamics GP, including areas like workflow, business intelligence, SQL Reporting Services, and planning for security or compliance.
Sales consultants will similarly benefit from deepening their product knowledge and command of more advanced technical topics, providing a perfect complement to the sales skills learned in Demo2Win.
Developers, whether focused on developing modules that complement Microsoft Dynamics GP or delivering customizations for individual customers will be able to deepen their technical knowledge including areas like extending workflow and leveraging web services. Of course, all roles will benefit from the shared learning and networking opportunity of bringing together the community of technical professionals around Microsoft Dynamics GP!
Mark your calendars! We look forward to seeing you in Fargo on May 28 and 29, 2008. Watch for more details and registration information coming in early 2008.
Throwing people at the problem is not always the solution. Something large development teams I expect are fully aware of.
Paul Murphy has some wise words on the subject, pointing out the obvious, a fully descriptive design would actually be the code to do the job...
Development work and team size by ZDNet's Paul Murphy -- the programming language appropriate for a particular application is the highest level language in which the requirements can be fully and completely expressed.