[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ubl-dev] Submission of meter readings
Comments inline.
On Friday, 4 February 2022 12:31:27 GMT G. Ken Holman wrote:
> 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.
Not in a closed environment, I am sending this to the supplier - see below.
>
> 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.
No, I am trying to email the readings to the supplier so that they can generate an invoice and (if they were to move to UBL which one day they might) they would then take those readings and return a UtilityStatement as well along with a UBL Invoice
> 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.
We do not have an electronic contract, but if I could make the ParentDocumentReference refer either to the last one I sent them (have to make something up for the first in the chain).
>
> 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.
The new top level document (UtilityReading) was what I was suggesting. Looking further there are a few other changes needed, as of course a UtilityReading is not able to mention money as that is calculated by the Utility supplier, and there are things like the LineExtensionAmount in the ConsumptionLine, but I can always leave them as zero.
The other comments I made about changing the semantics of a few of the fields were aide-memoir to the design of that new top level document.
I also have no idea what form you want new documents defined in, so I was doing it in narative form for want of anything better (and given that there is a close analogue)
>
> UBL exists to try and help people, not hinder them. Consenting adults
> can use UBL as they wish!
I am trying to introduce people to UBL by sending it to them anyway. While it might only have limited effect on them, it makes me feel good, and helps my understanding of what I need to put into the documents and check that the code I have to code and decode them actually works.
>
> 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]