Re: [ubl-dev] Mapping business model fields to UBL 2.0

["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