The programming aspects aren't the hard part. The hard part is adjusting procedures so that at least the invoice, if not the ASN, isn't sent until all items have been shipped to all locations. When you're working with something like MAS90 that will probably require the invoicing clerk to do some extra manual steps which are vulnerable to error.
Mike Paul McTeigue wrote: > For Shipping (ASN) and invoicing purposes, I have found that it is often > necessary to cobble together a bridge program that helps in that assembly. > i.e. Give me customer #, invoice or packlist # range, and the program will > scan through the ERP data and auto-build the ASN's or 810's. > > -Paul > > > |-----Original Message----- > |From: [email protected] [mailto:[EMAIL PROTECTED] On > |Behalf Of Mike Rawlins > |Sent: Thursday, October 19, 2006 4:08 PM > |To: [email protected] > |Subject: Re: [EDI-L] To SDQ or not SDQ... > | > | > |Yeah, we could split out a separate sales order for each SDQ > |without too > |much trouble. The problem is in re-assembling all of those > |sales orders > |into a single ASN and a single invoice per PO. > | > |Travis Truax wrote: > |> Mike, > |> We use MAS200 here, and have the same problem. However we worked > |> around it like some of the other posts mentioned by parsing > |through the SDQ > |> and making separate orders. Luckily we don't have to handle > |them very often > |> with that hack. > |> The particular customer that sends the infrequent SDQ > |POs allows us > |> to invoice them separately, though. > |> You've got to love those 4-digit address code fields in > |MAS. GLNs > |> fit really well! ;) > |> > |> Travis- > |> > |> -----Original Message----- > |> From: Mike Rawlins [mailto:[EMAIL PROTECTED] > |> Sent: Thursday, October 19, 2006 10:37 AM > |> To: [email protected] > |> Subject: Re: [EDI-L] To SDQ or not SDQ... > |> > |> > |> This is exactly the same situation I'm trying to handle with > |one of my > |> clients. They're a small supplier to several retail chains, > |and one of > |> them recently announced they were going to start sending multiple > |> ship-tos (via SDQ) on each PO. My client's order management system, > |> MAS90 creates one sales order per delivery location (at > |least in the way > |> that they use it). The SDQ would have caused us a *lot* of > |heartburn in > |> trying to re-assemble single invoices and ASNs per PO from multiple > |> sales orders. Fortunately for us, the buyer backed off from > |using the SDQ. > |> > |> The bottom line is that for many suppliers this really isn't > |a mapping > |> problem. It's an issue with the order management systems. > |> > |> Mike > |> > |> John Fiorino wrote: > |> > |>> Another thing to consider is whether your suppliers can in > |fact even > |>> handle > |>> an SDQ type order. Since you now send 1 store per PO, they > |more than > |>> likely > |>> create one customer order within their systems and then > |return one ASN and > |>> one invoice for that order back to you. If their systems > |can't handle > |>> multiple ship-to's within one order they'd continue to > |create multiple > |>> sales-orders per ship-to in the SDQ. I'm just guessing, but > |this would > |>> result in one invoice per SDQ referring to the same PO > |number you sent in > |>> the first place. > |>> > |>> Can your new host application handle multiple invoices for > |each SDQ order > |>> you initially sent? For that matter, how does your new > |merchandising > |>> system > |>> handle inbound invoices for these orders? ASN's? > |>> > |>> Although 'the customer is always right', and you can impose your new > |>> standards on them and insist that they comply by your go-live date > |>> (resulting in many on this board making a living out of > |it.) I prefer > |>> taking > |>> the 'KISS" approach. > |>> > |>> Since your suppliers already handle your current PO > |standard, keep it > |>> simple > |>> and create multiple 850's with the store number appended to > |the PO# as > |>> others have suggested. This would have the least impact on > |your go-live > |>> date. One less thing to test. Implementing a new > |merchandising system is > |>> hell as it is (been there done that many,many times.). > |>> > |>> Just my 2 cents worth. > |>> > |>> John Fiorino > |>> CompuSys Solutions > |>> Systems Integration Specialist > |>> > |>> -----Original Message----- > |>> From: [email protected] <mailto:EDI-L%40yahoogroups.com> > |>> [mailto:[email protected] <mailto:EDI-L%40yahoogroups.com>]On > |>> Behalf Of Jayne > |>> Gillette > |>> Sent: Wednesday, October 18, 2006 18:29 > |>> To: [email protected] <mailto:EDI-L%40yahoogroups.com> > |>> Subject: [EDI-L] To SDQ or not SDQ... > |>> > |>> Dear Group: > |>> > |>> Due to the upcoming implementation (next summer) of a new > |merchandising > |>> system, we are reviewing the current format of our 850s and > |860s (as > |>> well as > |>> several other EDI documents) to determine where changes are needed. > |>> > |>> Under the current system, we issue purchase orders with a > |unique PO number > |>> for each ship-to location (i.e., 1 PO number = 1 ship-to > |location). In the > |>> new world, the same purchase order number could be used for > |multiple > |>> ship-to > |>> locations. > |>> > |>> We know we could change our 850 / 860 EDI format to utilize > |the SDQ format > |>> like this: > |>> > |>> BEG segment: PO #12345 > |>> LIN segment: Item #ABC, Total Quantity 4000 > |>> SDQ segment: Ship-to Location 1, quantity 2000; Ship-to Location 2, > |>> quantity > |>> 1500; Ship-to Location 3, quantity 500 > |>> > |>> ...but, we are hoping to minimize the impact to our EDI trading > |>> partners as > |>> much as possible, so as not to jeopardize the go-live date > |for the new > |>> merchandising system. > |>> > |>> Since we do not currently issue SDQ-format 850s and 860s, we are > |>> considering > |>> sending the documents in the same EDI format we send today, > |which for the > |>> same order described above would look like this: > |>> > |>> 850 TRANSACTION #1: > |>> ------------------------------------------------- > |>> BEG segment: PO #12345 > |>> N1 segment: Ship-to Location 1 > |>> LIN segment: Item #ABC, Quantity 2000 > |>> > |>> 850 TRANSACTION #2: > |>> ------------------------------------------------- > |>> BEG segment: PO #12345 (same PO number as transaction #1) > |>> N1 segment: Ship-to Location 2 > |>> LIN segment: Item #ABC, Quantity 1500 > |>> > |>> 850 TRANSACTION #3: > |>> ------------------------------------------------- > |>> BEG segment: PO #12345 (same PO number as transactions #1 and #2) > |>> N1 segment: Ship-to Location 3 > |>> LIN segment: Item #ABC, Quantity 500 > |>> > |>> The EDI format is the same as what we send today, but the > |difference > |>> is the > |>> same purchase order number could now appear in multiple > |850s / 860s, for > |>> individual ship-to locations. > |>> > |>> We are being told we really can't consider doing this because > |>> manufacturers > |>> can't process "duplicate" PO numbers such as that described above. > |>> Based on > |>> your experience / knowledge, is it true that "duplicate" PO > |numbers like > |>> this will cause major problems in manufacturers' order > |entry / shipping / > |>> invoicing / etc. systems? > |>> > |>> As always, thanks for all your help and advice! > |>> Jayne > |>> > |>> -- > |>> No virus found in this outgoing message. > |>> Checked by AVG Free Edition. > |>> Version: 7.1.408 / Virus Database: 268.13.6/486 - Release > |Date: 10/19/2006 > |>> > |>> [Non-text portions of this message have been removed] > |>> > |>> > |>> > |> > |> > | > |-- > |--------------------------------------------------------------- > |Michael C. Rawlins, Rawlins EC Consulting > |www.rawlinsecconsulting.com > | > | > | > | > |... > |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 > | > | > | > | > > -- --------------------------------------------------------------- Michael C. Rawlins, Rawlins EC Consulting www.rawlinsecconsulting.com ... 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/
