Re: [ubl-dev] Submission of meter readings

["G. Ken Holman" <g.ken.holman@gmail.com>]

Yes, you could create your own top-level document element and then 
share the UBL common library to create your own document type. Other 
projects are doing this readily ... I wouldn't shy away from doing so.

Nevertheless, I would be tempted to "stretch" the interpretation of 
the semantics in your closed environment to match your needs with the 
least amount of effort.

Remember that UBL is used to interchange between systems and by 
standardizing the semantics, both systems can make assumptions about 
the meaning of the content. Yet I'm interpreting that yours is a 
closed environment of simply reading the meters. If you are not using 
UBL in this case to exchange the meter information openly to other 
users of UBL relying on the same semantic, I, personally, see no 
problem re-interpreting what the "parent" document is within your own 
environment.

How about making the parent document the contract under which the 
meter reading is being performed? Or some other closed meaning 
between your meters and your system.

For inter-company exchange I certainly would create a new document 
and share the common library (and then put forward the new document 
type to the committee for consideration), but for intra-company 
exchange, leverage the existing UBL for your own internal purposes. 
There are no UBL police to slap your wrist for doing so.

UBL exists to try and help people, not hinder them. Consenting adults 
can use UBL as they wish!

I hope this is helpful.

. . . . . Ken

At 2022-02-04 11:56 +0000, David Goodenough wrote:

> I have been trying to use UBL for as many things as possible on our 
> farm.  So we send out invoices as both PDF and UBL, and also remittances.
>
> Our electricity is now all metered using AMR (automated meter 
> reading) meters, so they send the readings to the supplier over the 
> LTE phone network and sending meter readings is not an issue, 
> although every now and then they ask for a manual read (by me) to 
> verify that the AMR is working properly and the numbers they are 
> getting agree with those displayed on the meter.
>
> We do not have any gas meters, and anyway gas meters along with the 
> gas they meter are all due for retirement in the not too distant future.
>
> Which leaves water meters.  Ours are in hedges (literally), or along 
> side farm tracks, and have no source of power to them so they are 
> all manual read, so some means of sending the meter readings to our 
> supplier is necessary as they no longer come and read them every 
> time, and I do not want estimated bills.  So I read the meters every 
> 90 days, and send them the readings.
>
> It would be nice to do this using UBL, and my initial thought was to 
> use the UtilityStatement, but that has a required field (the 
> ParentDocumentReference) which means that it has to be sent with or 
> after the invoice/credit note.  I appreciate that changing this from 
> a require field to an optional field would break backward compatibility.
>
> So I guess that means yet another root UBL object.  It would be very 
> similar to the UtilityStatement, and might be named UtilityReadings, 
> and would be almost identical to the UtilityStatement but without 
> the ParentDocumentReference.  All the other fields would remain, 
> even the DocumentCurrencyCode and the AccountingCostCode and 
> AccountingCost, which would be used as requests to the supplier to 
> set up the invoice correctly in the same way as an Order does.  The 
> SubscriberParty then becomes the SenderParty rather then the 
> ReceiverParty which is only a field comment change.


--
Contact info, blog, articles, etc. http://www.CraneSoftwrights.com/u/ |
Check our site for free XML, XSLT, XSL-FO and UBL developer resources |
Streaming hands-on XSLT/XPath 2 training class @US$125 (5 hours free) |
Essays (UBL, XML, etc.) http://www.linkedin.com/today/author/gkholman |