The other side of the coin: In most cases our customer maintains their own demand planning so that orders are aggregated to the DC level and sent to us; we fulfill and ship to the DC level and they take care of the breakdown. It has happened, however -- for new product launches, for example -- that we need to do store level shipments.
In those cases we are not going to be invoicing every Walgreens or CVS store if we ship them each three cases of a new product, we are still going to invoice to the bill-to level. In those cases, the only way we're going to be able to figure out how much product goes to which store is via the SDQ segment. In these cases the PO will be a one line PO with thousands of SDQ locations on it. If we invoiced each store, the receiving department at the DC would hate us, since they don't know in total how many cases they're getting. (Unless we are using a third party provider for fulfillment, in which case they could care less.) The A/P department would also burn a Band-Aid (tm) in effigy as we generated one invoice each for the thousands of stores that we're shipping to, instead of generating one single invoice for the whole order. -----Original Message----- From: [email protected] [mailto:[EMAIL PROTECTED] Behalf Of Allan Bennett Sent: Thursday, October 19, 2006 10:36 AM To: [email protected] Subject: [EDI-L] Re: To SDQ or not SDQ... I know that several of you have suggested creating multiple POs with the store number appended to the PO Number. Why? If your system has created multiple PO #s they are already unique. Why go through a system change to "sometimes" have a PO # with the store number appended and "sometimes" have a regular PO#? Jayne, You said: "In the new world, the same purchase order number could be used for multiple ship-to locations." Is that a "could" or a "must"? I agree with what I perceive to be the majority opinion and go with the multiple-PO approach. I think, in the long run, that your Receiving Dept., A/P, etc. will love you as a result. Here at Gorilla Glue we do get SDQ orders, thankfully not a lot of them. Some of the retailers do it well, others do not and they are the headache requiring custom solutions each time. We have Gentran:Server feeding into Great Plains (with vSync as the integrator). Between the three of them we get it done (Great Plains & vSync check for Duplicate POs but don't require them. They obviously ignore the warnings when creating separate orders for each SDQ location). Allan Bennett email: [EMAIL PROTECTED] Cincinnati, OH ... Please use the following Message Identifiers as your subject prefix: <SALES>, <JOBS>, <LIST>, <TECH>, <MISC>, <EVENT>, <OFF-TOPIC> Job postings are welcome, but for job postings or requests for work: <JOBS> IS REQUIRED in the subject line as a prefix. Yahoo! Groups Links [Non-text portions of this message have been removed] ... Please use the following Message Identifiers as your subject prefix: <SALES>, <JOBS>, <LIST>, <TECH>, <MISC>, <EVENT>, <OFF-TOPIC> Job postings are welcome, but for job postings or requests for work: <JOBS> IS REQUIRED in the subject line as a prefix. Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/EDI-L/ <*> Your email settings: Individual Email | Traditional <*> To change settings online go to: http://groups.yahoo.com/group/EDI-L/join (Yahoo! ID required) <*> To change settings via email: mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] <*> To unsubscribe from this group, send an email to: [EMAIL PROTECTED] <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
