Hi all! The client wants to print packing slips. I’ve created a report that matches the Sales Order without the costs. Now the client wants to ‘control’ the issuing of packing slips, so the same order isn’t packed more than once. This client is using some of Canadian 2.50 Adv. Distr. I wanted to pick the brains of other developers out there. I’m not sure which approach is best. Bascally, there are tmes when printing the Slip a second time is useful (a truly lost slip, paper jam, whatever). My thoughts were to either: 1) create a new table with a code field and a counter or Boolean field to track the times printed; or 2) edit the existing tables with a Bolean to say whether it was printed or not. To further compicate the issue, Packing Slips can be printed from either the Sales Order, and the Posted Sales Invoice. Can anybody who has done this before please give me some input? cheers, Matt.
You got a “number of printed copies” field (don’t know it’s exact name at the international version) in the sales order headers record… it’s that what you’re searching?? Alfonso Pertierra Spain
Hi! Not exactly. That field counts the number of times the invoice or the order has been printed. I thought about changing it to a decimal, and having the whole number count the orders printed and the decimal count the packing slips, but thought that was too many changes to a ‘base’ table to justify the work during upgrades. So I’m back to trying to decide if I should create a new table, or modify the existing base tables. cheers, Matt.
They COULD check the posted shipments field to see if a shipment has already been made. If everything has been shipped, then they can simply not pick it and ship it. Of course, to use this functionality with maximum efficiency, you would have to give someone on the loading dock access to Navision so they could post the shipments as they are made, which might be unthinkable:-) Another way, which doesn’t involve putting Navision on the loading dock, would be to physically sort picking slips by order number and/or by Customer No. and Posting Date. That way, it would be easy to see if the picking slip is a duplicate of an existing slip. I believe the standard pick list report does show how many items have been ordered but not shipped. If not, it could always be modified. ------- Tim Horrigan
A Picking List is only ONE step in a series of processes which have to be defined. Such as: 1) Call-Center takes phone-orders and creates the Sales-Order 2) Ordered Items are being assembled, wrapped, packed 3) Finished Parcel is being sent. These steps and possible problems have to be taken into consideration. Let me give you some examples: a) After the picking list has been printed and someone is running arround the stock to collect the desired items, the customer calles again and changes the order. How do you solve that problem? b) It often happenes that in large stocks different people are responsible to pick different kind of items. Such as one guy collects Hardware another one CD’s and the third one Pencils. Therefore the pick list might have to be split and be printed on several different printers containing the items from the appropriate item group. c) The amount of items ordered is not available. Who is correcting the amount shipped in the Sales order? In order to keep track of the live-cycle of an order the following method has proved to be very helpful in earlier projects I worked on: Define a Status-Field (Option) in T36 which might - depending on the steps you need - contain the following Status: New; being picked; ready for delivery; delivered; billed On the Sales order form you place a button “Done” which, when pressed, does some processing and then increases the Status to the next higher Status. For example: A Sales order (SO) is being created (Status::new). The SO is being filled out, corrected etc. “Done” is pressed. At this point the packing list is being printed and the status increases to Status::“being picked”. As soon as the packing is done and necessary corrections have been made, the next click on “Done” increases the status to “ready for delivery” which indicates that the parcel is now standing in the shipment zone of the warehouse waiting for the truck (or whatever). Up to this point it could still be possible that the SO is being modified (if the customer changes his order). At the moment, the truck arrives to take the parcels and the parcel is being loaded another click on “Done” will print the Shipping Invoice and change the status to “delivered”. This status should make sure that the order cannot be changed anymore. Of course, the above is only ONE possible scenario. It depends of your customer whether or not he is able to accept order-changes while an order is being packed or whether or not Shipment and Invoice are done at the same time or not. But I guess this might give you an idea what is expecting you. I wish you luck! Marcus Marcus Fabian phone: +41 79 4397872 m.fabian@thenet.ch
Hi! This is a first implementation, so Tim’s solution has a strong appeal. However, the client, I think, will like the functionality of Marcus’ solution. Especially, as it will allow the Outside sales staff to dial in and check the status of the order. The client generally only issues Packing Slips for Posted Sales Invoices. If their customer changes and/or cancels an order, a credit is issued, and a new order is created. I would need to change some of the options to account for that, but that’s trivial. Marcus, how have you integrated Batch Invoicing with this solution? cheers, Matt.
Hi Matt, >>how have you integrated Batch Invoicing with this solution?<< Very simple: The batch invoicing simply filters for Sales Orders which have the status “delivered”. In one project Batch invoicing is done every evening. The job is started after 5 p.m. In another project it’s more complicated as they combine shipments and only send invoices every 2 weeks. But in both cases the system is the same. Marcus Marcus Fabian phone: +41 79 4397872 m.fabian@thenet.ch