OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ubl-dev message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [ubl-dev] cXML Order Request to UBL Order




On 07/08/2009 02:59 AM, Stephen Green wrote:
92040e120907070959v14678d33o8bc66bafe1a8905e@mail.gmail.com" type="cite">I tend to think that payment terms seems
odd when talking about an Order; whilst I agree
with Ken's mapping of it to Transaction Conditions,
I wonder whether it makes sense except from in
the invoice - unless the ordering party (cXML's
order-requesting party?) might sometimes dictate
the payment terms which seems unlikely.
Just for the record. I work mostly in the footwear supply chain and I can assure you that customers dictating payment terms is very common. However there is more than one reason.

Payment terms are negotiated prior to any ordering, however the (unfortunate?) existence of people in the process loop means that mistakes can be, and often are, made. For the supplier the more verifiable information passed from the customer the better.

Some large customers simply dictate terms. Being so large, often relative to their suppliers, they just have uniform payment terms and if you want to do business with them you accept those terms.

Many customers even specify the barcodes to be used on the product (even though this is technically a supplier prerogative). And the purchase order needs to support this as well - a mapping from customer barcodes to supplier barcodes/sku codes.

Secondly, the suppliers often check the customer payment terms in the purchase order to ensure agreement to terms of trade.

We also check pricing as large customers often pay on receipt of an ASN (which does not include prices) rather than receipt of an invoice. It is important that prices at the customer end have been checked on receipt of the order and corrected if wrong.

One thing I have found over the years is that there is no such thing as "the way" to send/receive purchase orders, confirmations, ASNs, invoices, etc. The more flexibility, the better off you are.

Rick
92040e120907070959v14678d33o8bc66bafe1a8905e@mail.gmail.com" type="cite">I agree
that order total is AnticipatedMonetaryTotal. I
don't claim familiarity with complex ordering like
that used in supply chains - I've only been involved
with public sector purchasing/buying) - but I take
third party billing to be where a party paying for
freight is not the same as the party paying for
goods so I think it isn't right to use the
AccountingCustomerParty for this - maybe UBL
doesn't support this (hopefully someone will
correct me). Maybe there could be an extension
for anything not supported by UBL - if necessary
to cover complex supply chain requirements. I
don't know about 'drop ship' or 'ship complete'
- for same reasons as above.

I agree it would be good to see a wiki page for
documenting all this kind of information. Well done
Ken.

Best regards

---
Stephen D Green
Document Engineering Services Ltd


2009/7/7 G. Ken Holman <gkholman@cranesoftwrights.com>
At 2009-07-07 11:06 -0400, Marzka, Jeremy wrote:
I am in the process of mapping trading partner documents in various formats to a UBL Order layout. The document I am currently working on is a cXML Order Request and I am not sure where to map the following header fields:

Here are my guesses:

Order total

 /po:Order/cac:AnticipatedMonetaryTotal
 "An association to the total amounts for the Order anticipated by the Buyer."

Third party billing

 /po:Order/cac:AccountingCustomerParty
 "An association to the Accounting Customer Party. The party that Invoice is expected to be sent to if not the buyer party."

Drop ship PO/release

 /po:Order/cac:DeliveryTerms

Payment terms

 /po:Order/cac:TransactionConditions


Ship Complete (For the header)

 /po:Order/cac:DeliveryTerms


Any suggestions would be greatly appreciated.

I don't have an accounting background, so I don't even recognize some of your terminology (such as drop ship PO and release), but I hope that my guesses turn your face in the correct direction.

Please don't take my interpretations as gospel ... I'm trying to learn here myself by throwing up straw-man suggestions to be torn down if necessary.  I hope the business experts on the list will provide their own suggestions.

I'm also working with OASIS regarding setting up a collaborative environment on UBL.xml.org where each and every business entity in UBL can be discussed.


I'd also be interested to hear what your process is to find equivalent fields in UBL.

I'm looking through the HTML summary reports found here:

   http://www.CraneSoftwrights.com/resources/ubl/index.htm#ubl2modelreport

... because the hyperlinking through the tables is very quick, and they copy most of the information from the spreadsheets.  Note there are two main sections:  the definitions and the tables.  Numeric hyperlinks link back and forth switching between the two sections.  Alphabetic hyperlinks link within the same section.


It seems to me like there isn't much documentation for the recommended use of the fields.

True ... my personal perspective is that it is not the UBL TC's role to tell a community of users *how* to use UBL, just to provide the standardized framework within which a community of users can send their information between parties using agreed-upon constructs.

I hope this helps.

. . . . . . . . . . . . Ken

--
Possible July/August XSLT/XQuery/XSL-FO training in Oakland/CA/USA
Crane Softwrights Ltd.          http://www.CraneSoftwrights.com/u/
Training tools: Comprehensive interactive XSLT/XPath 1.0/2.0 video
Video lesson:    http://www.youtube.com/watch?v=PrNjJCh7Ppg&fmt=18
Video overview:  http://www.youtube.com/watch?v=VTiodiij6gE&fmt=18
G. Ken Holman                 mailto:gkholman@CraneSoftwrights.com
Male Cancer Awareness Nov'07  http://www.CraneSoftwrights.com/u/bc
Legal business disclaimers:  http://www.CraneSoftwrights.com/legal


---------------------------------------------------------------------
To unsubscribe, e-mail: ubl-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: ubl-dev-help@lists.oasis-open.org




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]