[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: SV: [ubl-dev] Submission of meter readings
This is what I am trying to do. But there are some fields (like the parentDocumentReference) and the LineExtensionAmount which are mandatory and have no useful value. Do you know what they put in those (I suppose the Amount can always be zero), it would be good to follow someone else's lead.
Also do they change the UtilityStatementTypeCode to something like "Water Reading" rather than just "Water"?
On Friday, 4 February 2022 15:37:34 GMT plb@ebConnect.dk wrote:
> 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]