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] Mapping business model fields to UBL 2.0


I saw Ken's response after sending mine and I prefer Ken's answer to #3
but if you want to go to town explaining responses in a process context
then you could document your own reason codes and cross reference
them to process descriptions perhaps

---
Stephen D Green
Document Engineering Services Ltd


2009/7/13 G. Ken Holman <gkholman@cranesoftwrights.com>
At 2009-07-13 14:37 +0200, Darko Gulija wrote:
I'm a member of a committee  that works on a Croatian standard for e-Invoice based on UBL.

Welcome to the list!


We studied UBL version 2.0 as a base, but found out that we had a few fields in our business model for which we could not find a proper mapping.

I'm walking through the HTML model reference pages to propose my suggested approaches:

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

As readers of the list have heard before, my angle-bracket-oriented focus on UBL does not serve me very well on the business side of things so I am putting out straw-man suggestions for answers business-oriented questions as I would answer them ... and then learn from people like Stephen Green, Fulton Wilcox and Tim McGrath (amongst many others) who can then fix my responses.

I find answering questions like this an excellent exercise in discovering what is in UBL ... so these are my suggested answers:


Here they are:
1.       InvoiceReference
Invoice could contain a reference to another invoice, most often expressed through the invoiceID and date. This information is most often used in DebitNote or CreditNote.

Example of business context is when supplier sends a CreditNote document to the buyer because on one of the previous invoices there was an error and the price was higher than it should have been. Now, when supplier wants to issue the document to give buyer a credit for the difference, there should be a reference to the original document (invoice) that contained the error.

<cn:CreditNote>
 <cac:BillingReference>
   <cac:InvoiceDocumentReference>
     <cbc:ID>
     <cbc:IssueDate>
     ...


2.       OfferReference
Invoice could contain reference to the offer that started the whole transaction

Offer or order?  Wouldn't an order trigger the invoice?

Order would be here:

<in:Invoice>
 <cac:OrderReference>
   <cbc:ID>...

I'm guessing offer might be here:

<in:Invoice>
 <cac:OriginatorDocumentReference>
   <cbc:ID>...

... or ...

<in:Invoice>
 <cac:AdditionalDocumentReference>
   <cbc:ID>...


3.       BusinesEventOrActivityIndicator
Invoice (especially Debit Note and Credit Note) could contain the codes and corresponding explanations of the business events that resulted in issuing the invoice.

Example of business context is that ,e.g.  a Credit Note is usually a result of wrongly calculated price on one of previous invoices, but there could also be another reasons for issuing it. It is sometimes important to exactly know the reason why it has been issued (expressed through the code of the type of business transaction that cause it and corresponding explanation), so that it could trigger the specific action on the recipient side.

<cn:CreditNote>
 <cac:DiscrepancyResponse>
   <cbc:ResponseCode>


4.       PlaceOfProcessing
Part of the enterprise responsible for processing of e-invoice (usually address or ID of regional headquarter – potentially expressed as GLN).

In some enterprises there are rules  where the paper invoices should be sent to (to which address  - usually regional headquarters), so that regional headquarter office could check whether the prices and the quantities match with the supplied goods and approve (or disapprove) its further processing.

When converting to e-invoicing, this information is still required because the business rules within the company that decide who should give approval for the invoice are still in place (and they are based on that address – business processes and internal ERP systems are still set up for processing paper invoices and they need this information, although the address of the “inbox” will be the same for all the e-invoices).

This is a wild guess on my part, but since you can identify multiple parties for an organization, why not have a second party being the one responsible for processing (note the identifiers I'm using here are made up ... you would set up a code list for this):

<in:Invoice>
 <cac:AccountingSupplierParty>
   <cac:Party>
     <cac:PartyIdentification>
       <cbc:ID>Buyer</cbc:ID>
     </cac:PartyIdentification>
     ... the information for the usual supplier party ...
   </cac:Party>
   <cac:Party>
     <cac:PartyIdentification>
       <cbc:ID>Processor</cbc:ID>
     </cac:PartyIdentification>
     ... the information for the processing responsible party ...
   </cac:Party>


I’d appreciate if you could help us to find out the best solution for the problems mentioned above,

I wouldn't call it "best" but I hope other UBL-Dev members can critique my suggestions to see how close I got to what they would have recommended.


as we would like to avoid treating them as extensions if possible.

I understand!

Good luck with UBL and have fun!

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

--
XSLT/XQuery/XSL-FO hands-on training - Oakland, CA, USA 2009-08-03
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]