Here are a few things to consider when thinking about the concept of 
errors...

One thing you must remember is that we're TRADING PARTNERS and we 
need to work together and COMMUNICATE any issues, errors or problems 
we're having....

--- In [email protected], "Art Douglas"  wrote:

 One solution I came up with worked when a customer was consistent 
with their SKU errors:  I created a customer SKU cross-reference 
table.  Then we tweaked the Order Import process so that when a SKU 
validation failed against the Item Master, the process attempted a 
look-up in the SKU XREF table:  First by ship-to, then by customer, 
then a general look-up.  The original SKU was stored in an extra 
field in the sales order, which was  passed on to the ASN and the 
Invoice interface files.  Then we mapped those extra fields to the 
outbound product code.  The problem we ran into was when the 
customer placed a phone order.  Then we didn't have the "original" 
SKU for the invoice.  Solution?  They outsourced EDI before we 
addressed that one, so I have no idea. 
 Art Douglas

----- REPLY -----
Art, this is an excellent idea, and one that many of our vendors 
work with.  We send a multitude of information in our PO1 segment – 
our SKU, the UPC, the vendor style, a size and a color (if 
applicable) and an item description.  We REQUIRE on our inbound ASN 
that they provide OUR SKU and they can also send anything else back –
 UPC, vendor style, whatever…  But the SKU is mandatory.  So many of 
them will either capture the SKU from the inbound PO and store it in 
a table OR they will create a table of our SKUs and their UPCs/Style 
numbers and populate the ASN or the Invoice from that table.
If, however, an order is placed via phone or fax, there is no 
requirement for the ASN.  But, basically, if you're EDI compliant 
and capable, there IS no phone or fax order.  There is always EDI 
and then a confirmation  fax.

-----Original Message-----
--- In [email protected], "Jake Holt" wrote:
 I hear what you guys are saying, the only problem is I run into 
exactly what Art said.  They just expect me to accept and adjust it 
but then it delays everything down the line.  If I correct the 
issue, now I have labeling problems (which I get to handle too), ASN 
problems, etc. and we all know where that leads (hint: $$$$).  
Generally we can challenge the fines but that costs money too.  I 
would be fine if they didn't "resend" a PO since I can understand 
that's a no no for some people, but certainly I would think 
implementing an EDI solution to the problem would be valuable to 
both parties.
 That PO hold is a pretty solid Idea, and it could tie right into my 
current validation engine.  Amazing how you can miss the simple 
answers in favor of the complex ones that make everyone mad =).
 Now I feel better... until next week when someone else does it.

----- REPLY -----
Jake, go back and read the opening of My reply – the part about it 
being a PARTNER RELATIONSHIP.  It needs to be discussed and 
understood BY BOTH PARTIES that errors will be ______ and then fill 
in the solution.  If there's an incorrect UPC, then it's up to the 
buying partner to fix the error in their system and either resend 
the UPC or allow you to fix it on your side.    If you hold the 
order and don't alert the buyer to that hold, they're going to be 
calling you when the shipment is late and asking "DUDE! WHERE'S MY 
STUFF?"  And that ends up costing BOTH partners the hinted at $$$$ 
because of lost sales AND any discounts you give Me to make Me happy 
over the foul up!

-----Original Message-----
--- In [email protected], "Dale Marthaller" wrote:
 We have the mother of all hybrid systems. We receive EDI PO's with 
vague and/or incorrect UPC's, determine and ship the correct ones 
billing the customer back with their own UPC codes. We are lucky 
that our product's packaging does not have bar codes on them.  
  Dale Marthaller

----- REPLY -----
Oooh!  Danger!  Danger!  Danger Will … err … Dale Marthaller!
Or wait… do you sell a product that the buyer then repackages and 
applies their OWN UPC number and barcode to?  Wow… interesting…
But I go back to My above – communicate the problem with the buyer 
and get it corrected for present and future orders… don't let it 
snowball and continue.

-----Original Message-----
--- In [email protected], "Art Douglas" wrote:
 If the customer sends an incorrect SKU, part number, UPC, etc., and 
the supplier "figures it out" and creates a sales order with the 
correct part number on it, ships it, and invoices it, then dollars 
to donuts the customer's A/P department will delay payment 
because "the PO doesn't match the invoice."

----- REPLY -----
BINGO!  And given the tightness of the economy today and the 
concepts of JIT ordering, is it really wise to have a delay in 
payment processing…?
-----

 One of the big advantages of EDI is that it forces trading partners 
to synchronize their product catalogs and price lists. If they 
don't, then things won't work as they should.

----- REPLY -----
BUZZ!  WRONG ANSWER…. Sorry, Art, but no…  it doesn't force anything 
of the sort.  It DOES create an instance where synchronization of 
the catalog can be beneficial, but there are other aspects to 
consider…  For example, if we were to download and use an 832 
(catalog) from either the vendor or a catalog service (Inovis or SPS 
Commerce, for example) it doesn't work well with our Item Master 
files in that it may populate a field with your data and that data 
may not perfectly fit our needs.  For example, you call a pair of 
shorts the AD Denim – that's it.  However, for 2007, your design was 
slightly different – or you offered a different shade of blue – than 
you did in 2006 and 2008 and will be different from 2009.  So, in 
our item description, we add something to denote a change in season 
or year.  So we call it the "AD Denim – SP07" to show that it's the 
denim short from Spring of 2007.
-----

My initial response to Jake's dilemma would be to reject the order. 
But on further consideration, I think I would recommend placing the 
order on hold pending a PO Change, replacement order, etc. A 
verbal "okay" from the buyer is insufficient. The buyer _never_ 
informs his/her A/P department of the change.

----- REPLY -----
But you must be sure to communicate the needed changes with the 
buyer.  If they don't know you've put the order on hold, then it 
does no good to "wait" for a PO Change or replacement order or 
whatever…
And as for the "verbal OK" – you are SO right…!  I can't even begin 
to tell you the times that I've come across errors (or been told of 
them by AP!) in an invoice because it doesn't match the PO…!  Our 
buyers are notorious for changing terms or quantities or colors or 
_____ and then not changing the PO in the system!!!  "Oh, they 
shipped it early and are giving us an extra 30 days to pay?  Great!" 
but the PO never was changed!!!
-----

This rant also applies to pricing, quantity, changes etc. If it is 
not in writing or EDI, the approval for a change doesn't exist.
  Art Douglas

----- REPLY -----
BINGO AGAIN!

-----Original Message-----
--- In [email protected], "Earl Wertheimer" wrote:
 " If a customer requires me to correct and resend any document that 
they can't process due to an error (which isn't a problem), 
shouldn't they be  able to do the same when they can't get a UPC 
right to save their life?  "
 They are the client. If it becomes too expensive to handle their 
requirements,  you can add the cost to their prices or ask them to 
go elsewhere.  
 I would suggest a bit of gentle training. 

----- REPLY -----
Exactly, Earl…  Jake's comment is a bit antagonistic – but it's 
true.  But it's not always the buyer that is the source of the 
error.  Sometimes a vendor gives the buyer the wrong UPC or some 
other product information and a buyer inputs in their system 
incorrectly.  The best way is to communicate the error with them and 
get it fixed and resent.  And there have been times where the 
vendors own system was mucked – in that they had style 123 
associated with the UPC for XYZ and UPC for XYZ was attached to 
12891.  And then our PO is wrong because they're filling from style 
number and they no longer sell XYZ.  Or XYZ is a proprietary brand 
reserved for another buyer!
-----

 "Garbage In, Garbage Out" still applies. If they cannot submit the 
correct UPC to you, then you always have the option to reject the PO 
and send them a notice that they are wrong, ship them the wrong 
goods, or correct it yourself...
 "  Email is a good way to resolve errors on POs, right? anyone? "
 It depends on the error.  If there are turnaround documents from 
the 850 (ie.  Invoice or ASN), then the email will not correct the 
error on the PO.
 Email is a good way to explain a problem and supply a backup, but 
nothing can beat a correct PO ;-)

----- REPLY -----
This is exactly right, Earl.  GIGO is an acronym that has been 
around since … well at least since the dawn of the computing age … 
because the computer is just a tool and the data coming out is only 
as good as the data going in.
And e-mail error resolution CAN be a good way to resolve the error – 
as long as the buyer then takes the initiative to fix it in their 
system AND both sides can agree on how to fix the existing, current 
error on the pending order!  
-----





------------------------------------

...
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/

Reply via email to