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: SV: [ubl-dev] Submission of meter readings


Hi David and Ken

Have you considered using the UtillityStatement? This is used in Denmark and
Portugal for similar services.

/Peter

-----Oprindelig meddelelse-----
Fra: G. Ken Holman <g.ken.holman@gmail.com> 
Sendt: 4. februar 2022 13:31
Til: David Goodenough <david.goodenough@broadwellmanor.co.uk>;
ubl-dev@lists.oasis-open.org
Emne: Re: [ubl-dev] Submission of meter readings

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 |


---------------------------------------------------------------------
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]