Rehashing this month-old discussion:

I'm looking at integrating some web drop-ship (Commerce Hub based) partners, 
and although I'm used to saving customer data in our ERP, the extra data fields 
required for these maps looks really extensive due to the fact that there are 
numerous fields that have no relevance to us whatsoever beyond the fact that we 
must print a very tightly controlled pack slip format (due to it being 
drop-ship).

That means they send line item totals, order totals, tax amounts, shipping 
amounts, member numbers, customer order numbers, etc - so that the pack sheet 
can be constructed. After looking at a few of these specs, I see about 30 
"transient" fields that I don't already handle, and I hate making major 
modifications any time this stuff crops up.

I was pondering the scheme Samantha suggested earlier:
>>things we don't have room for in the ERP go in a generic code/value table 
>>with the order number, a code indicating what the data is, the data, and an 
>>indicator what line it applies to (0 for the header).    

I love the concept, as far as it being extensible in the db, but considering I 
will use so many of these "generic" fields in a single document, I'm afraid 
that querying the data stored that way will require an onerous amount of 
inefficient table joins. Am I off on that?

The only other option I saw mentioned was delimiting it all together in 
key=value pairs in a large text block. From a DBA perspective, that just makes 
me feel "dirty", though. :)

Travis-  
  

--- In [email protected], Samantha Scott <mossmuncher@...> wrote:
>
> We store what we can on the order header or line, such as customer part# so 
> that it is available when we go to generate the invoice/ASN.  That keeps us 
> out of the business of maintaining a cross reference of our customer's data.  
> You want to avoid that.  If I sell part 123 and they send in the order for 
> that with their item X on it one day and Y on it the next then my invoice/ASN 
> will always match the PO and I could care less if they changed it in the 
> meantime.
> 
> Certain  things we don't have room for in the ERP go in a generic code/value 
> table with the order number, a code indicating what the data is, the data, 
> and an indicator what line it applies to (0 for the header).  Keep it simple, 
> universal and reusable and purge that external data shortly after the order 
> is invoiced/cancelled or otherwise finished.  Do not be in the business of 
> being your customers external data storage.
> 
> On Mar 12, 2013, at 11:06 AM, Thorsten Evans wrote:
> 
> > Question for my EDI friends...Customers require us to send back data on the 
> > invoice/ASN that we don't require in our ERP system such as customer item 
> > number, ordered UOM (we translate to our default UOM, but customer requires 
> > theirs back on the invoice)...and a few others.
> > 
> > How do people maintain/get this data from the PO onto the outbound 
> > document?  To make things more difficult, some of these orders are hand 
> > keyed, but require EDI invoicing.  
> > 
> > Here are the 3 options I see:
> > - Look back at the original PO (PO's hand keyed fail)
> > - Maintain this data in tables...either in ERP or in the middle somewhere
> > - Push required data into the delivered Order load interface and carry data 
> > through outbound process (PO's hand keyed would require more data entry)
> > 
> > Are there other options?
> > 
> > Appreciate any feedback and experience from the group.
> > 
> > -Thorsten
> > 
> > [Non-text portions of this message have been removed]
> > 
> > 
> 
> 
> 
> [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:
    [email protected] 
    [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