Re: [ubl-dev] UBL 2.1 Invoice and Utility Statement

["G. Ken Holman" <gkholman@CraneSoftwrights.com>]

At 2013-06-19 10:17 +0000, =?iso-8859-2?Q?Matija_Tu=B9ek?= wrote:
> I have successfully created UBL 2.1 Invoice and 
> Utility Statement as supplement to that Invoice.
>
> How can I extend UBL Invoice 2.1 with Utility 
> Statement to have one master schema with Invoice and it's supplement?
> -                                 - Do I need to 
> fill parts in Utility Statement like 
> Sender/Receiver/Copy Indicator/Issue 
> Date/Customer etc -  because I already have them in main Invoice?
> -                                  - The main 
> part that I need from Utility Statement is 
> -  Subscriber Consumption and I've mapped everything I needed.
> -
> The main idea is to send to our partner UBL 
> 2.1  Invoice with Utility Statement supplement and attached invoice pdf.

I've appreciated this discussion and Matija's starting of it; thank you Matija.

At 2013-06-20 09:17 +0200, Roberto wrote:
> you could embed just the details of the 
> UtilityStatement inside an UBLExtension, anyway 
> I would embed the whole UtilityStatement and fill it accordingly.

At 2013-06-20 15:54 +0800, Tim McGrath wrote:
> yes, thanks for raising that.  Ken suggested 
> something similar to me.   i suspect that for 
> validation purposes this would work best.

At 2013-06-20 10:00 +0100, Stephen D Green wrote:
> I don't think
> there is anything technically wrong with combining two bits of the advice
> from the others to your question and sending the UBL 2.1 Invoice with
> just the subscriber consumption part of the utility statement inside a UBL
> extension in the invoice.

I see there is wide agreement regarding using the 
UBL Extension point, and so I've been thinking 
about the schema ramifications of this.  Using 
the extension point was the first thing to come 
to my mind because then the XML of the statement 
is addressable and not compressed and opaque 
inside of a base64-binary component.

This is how I see the issues for candidate users 
(and I hope others will look for faults in my reasoning):

- using UBL 2.0 we don't get any extension validation because of
  process="skip" in the extension content data type

- using UBL 2.1 we do get extension validation of those elements
  from the common library that are used because of process="lax"
  in the extension content data type

- we do not get extension validation of the "top level" of a UBL
  document that is under an extension because, say, the Invoice
  schema does not include a declaration for the UtilityStatement
  apex element, even though we do get validation of descendants
  of UtilityStatement found in the common library

Thus, the suggestions to put only subscriber 
details under the extension point are currently 
already supported in out-of-the-box UBL 
2.1:  simply create an apex element of your own 
design and constrain it to contain the Library 
ABIE (as an ASBIE) elements and BBIE elements 
from the UBL common library.  I think everything 
will be validated (I'll test this later when I 
get more time; I wanted to comment while the discussion was ongoing).

So it works out-of-the-box for <cac:SubscriberConsumption>.

But what if one wants to embed a Document ABIE, 
say <UtilityStatement>, under the extension 
point?  The children of <UtilityStatement> will 
individually be validated because the constraints 
are already loaded into memory from the common 
library.  But as it stands as delivered without 
changes, <UtilityStatement> *itself* will not be 
validated, so its children may be out of order.

To address this, I think all the user needs to do 
is simply add to 
mod/common/UBL-ExtensionContentDataType-2.1.xsd 
an <xsd:import> pointing to the Utility Statement 
XSD, and then the presence of <UtilityStatement> gets validated itself.

It is expected that users will change 
mod/common/UBL-ExtensionContentDataType-2.1.xsd 
to accommodate user-defined extensions, so this is not a problem.

I'm not convinced this is a change we should do 
at the committee level:  I don't think we import 
all 65 document schemas into the out-of-the-box 
extension module.  That is a heavy processing 
penalty when very few communities need it.  We'll 
just let communities do this if they need it, and 
it gets done in the one module that the community 
is allowed to change for itself.

I'll do a full suite of structured tests as soon 
as I get the time, and then I'll report my 
findings here.  Please send me scenario suggestions either on-list or off-list.

Would readers of the list feel that a published 
Committee Note regarding this topic would be a useful resource?

Again, please let me know if you see any faults 
in my reasoning before I take the time for the tests.

Thank you, again, Matija!

. . . . . . . . . . Ken


--
Contact us for world-wide XML consulting and instructor-led training |
Free 5-hour lecture: http://www.CraneSoftwrights.com/links/udemy.htm |
Crane Softwrights Ltd.            http://www.CraneSoftwrights.com/u/ |
G. Ken Holman                   mailto:gkholman@CraneSoftwrights.com |
Google+ profile: https://plus.google.com/116832879756988317389/about |
Legal business disclaimers:    http://www.CraneSoftwrights.com/legal |