Following on from my previous email and using the link in the email below I have now subscribed to ubl-dev (or at least I have started the process), and I will try to divide my comments and suggestions between the two.
As a matter of interest, where are the definitions of what is appropriate for each list? I think I have gathered some of the difference from other emails in this thread, but I would be interested to read for formal definition.
David
On Monday, 13 November 2017 12:46:25 GMT G. Ken Holman wrote:
> Gentlemen,
>
> I've just been corresponding with Chet and
> explained how this specific discussion is related
> to changes being proposed and discussed for UBL
> 2.3 and so qualifies to be carried out within the
> confines of the IPR agreement obligated by
> participation in the UBL Comment List.
>
> But I acknowledge that some of the discussion
> could easily be construed as "how to work with
> UBL as it is or could be" and, thus, very much belongs on UBL-Dev and not
> here:
>
> https://www.oasis-open.org/mlmanage/
>
> Let us all try to be more mindful of the role of
> the UBL Comment List to be the conduit for
> specific identifiable suggestions and public
> review comment from contributors outside of the committee.
>
> I suggest a compromise by focusing on the content
> and splitting this and other future discussions
> into the two parts: suggestions for specific
> changes go to the comment list and discussions of
> requirements in general go to the UBL Dev
> list. Which, I suppose, is as it should be and isn't a compromise at all.
>
> Thank you!
>
> . . . . . . Ken
>
> At 2017-11-13 10:55 -0500, Chet Ensign wrote:
> >Hi folks - Can I ask that you move this over to
> >the ubl-dev@ mailing list. Per OASIS rules, the
> >ubl-comment@ mailing list should not be used for
> >ongoing discussions. This looks like it is an
> >on-going discussion so it should be moved someplace else.Â
> >
> >Thanks much,Â
> >
> >/chet
> >
> >
> >On Mon, Nov 13, 2017 at 10:48 AM, Kenneth
> >Bengtsson <<mailto:>> wrote:
> >
> >Hi David
> >
> >Â
> >
> > > Just because a particular process or profile
> >
> > does not fit every possible need that does not
> > mean that it is not worth defining a simple starting set.
> >
> >Â
> >
> >I think thatâ?Ts what weâ?Tve done in UBL,
> >isnâ?Tt it? The suggestion was to make these
> >processes normative in the UBL spec, and Iâ?Tm
> >pointing out some problems I see with that. If
> >the processes were normative in UBL, they would
> >no longer just be suggestions. They would make
> >it impossible to use UBL in environments where
> >the normative process couldnâ?Tt be applied.
> >
> >Â
> >
> > > In the case you mention, the way you describe
> >
> > it is a simple matter of using a self-billed
> > invoice rather than an invoice, the process for
> > which presumably remains the same as for most other self-billed invoices.
> >
> >Â
> >
> >I agree that this is similar to a self-billed
> >invoice, however the invoice follows an initial
> >exchange of documents that doesnâ?Tt follow the
> >UBL self-billed process as such. In all cases,
> >my intention was not to discuss this case in
> >particular but rather to illustrate how
> >pre-defined normative business processes in UBL
> >could make the use of UBL impossible.
> >
> >Â
> >
> > > It also is useful to show regulators who are
> >
> > being difficult just how the rest of the world
> > operates - not that such a regulator is likely to listen.
> >
> >Â
> >
> >Size may vary, but I personally donâ?Tt feel
> >that regulators who have different systems from
> >the European necessarily are being difficult.
> >Companies in countries with regulated invoicing
> >are typically not required to have their
> >financials audited for example, because the tax
> >administrator instead uses the invoices as
> >source of information. You can either have 6 or
> >half a dozen - itâ?Ts a different solution to
> >the same problem (fiscal control). I donâ?Tt
> >think itâ?Ts the role of the UBL TC to globally
> >standardize tax systems, nor to be judge over
> >which countries have the â?orightâ?? tax system
> >and who not. What we can do (and I truly believe
> >we are doing) is to provide a layer of
> >interoperability that works independently of and
> >indiscriminating of regulation, industry, culture, etc.
> >
> >Â
> >
> >Best regards,
> >
> >Â
> >
> >Kenneth
> >
> >Â
> >
> >Â
> >
> >Â
> >
> >From: David Goodenough
> ><<mailto:>david.goodenough@broadwellma
> >nor.co.uk> Date: Monday, November 13, 2017 at 10:12 AM
> >
> >To:
> >"<mailto:>"
> ><<mailto:>>
> >Subject: Re: [ubl-comment] Further thoughts on Party data for 2.3
> >
> >Â
> >
> >Kenneth,
> >
> >Â
> >
> >Just because a particular process or profile
> >does not fit every possible need that does not
> >mean that it is not worth defining a simple starting set.
> >
> >Â
> >
> >For those for whom it works, it frees them from
> >all the work in creating bi-lateral agreements
> >both legally and technically, and for those for
> >whom it does not work, it provides at the very
> >least a check list of things that need to be
> >considered technically, so that the regulatory
> >requirements can be added on top. It also is
> >useful to show regulators who are being
> >difficult just how the rest of the world
> >operates - not that such a regulator is likely to listen.
> >
> >Â
> >
> >In the case you mention, the way you describe it
> >is a simple matter of using a self-billed
> >invoice rather than an invoice, the process for
> >which presumably remains the same as for most other self-billed invoices.
> >
> >Â
> >
> >David
> >
> >Â
> >
> >On Monday, 13 November 2017 14:54:22 GMT Kenneth Bengtsson wrote:
> >
> >Hi Steve
> >
> >Â
> >
> >The lifecycle you sent works fine in regulatory
> >environments where the supplier and customer
> >parties have the freedom and flexibility to
> >define invoicing formats and processes
> >themselves, such as in Australia, North America
> >(except for Mexico), and most of Europe.
> >However, that is not always the case. In many
> >countries, the invoice format (being it physical
> >or electronic) is regulated by the tax
> >administration, and the processes and sequence
> >of the document exchanged may depend on a number
> >of things, such as invoice amounts,
> >products/services being exchanged, and even the
> >size or nature of either the supplier party or the buyer party.
> >
> >Â
> >
> >To give you an example, Ken and I were recently
> >advising a Latin American tax administrator on
> >the specific situation where not-for-profit
> >organizations receive donations from legal
> >entities registered as tax payers. According to
> >the regulatory requirements of this country,
> >these transactions must be documented by an
> >invoice exchange, like any commercial
> >transaction, however in this specific context,
> >the invoice must originate from the buyer party
> >and not from the supplier party.
> >
> >Â
> >
> >As you go through different countries different
> >requirements and regulations, you will find
> >innumerable examples and context where a
> >standardized business process canâ?Tt be
> >applied. So to standardize business processes in
> >UBL and to make them normative we would somehow
> >have to map all these processes and keep our
> >specification updated as regulations and
> >requirements change. Again, I believe that what
> >makes UBL truly universal is its ability to
> >provide syntax and semantic interoperability
> >applied across different business and regulatory contexts.
> >
> >Â
> >
> >Best regards,
> >
> >Â
> >
> >Kenneth
> >
> >Â
> >
> >Â
> >
> >From: Steve Capell <<mailto:>>
> >Date: Friday, November 10, 2017 at 5:45 PM
> >To: Kenneth Bengtsson <<mailto:>>
> >Cc: David Goodenough
> ><<mailto:>david.goodenough@broadwellma
> >nor.co.uk>,
> >"<mailto:>
> >"
> ><<mailto:>
> >> Subject: Re: [ubl-comment] Further thoughts on Party data for 2.3
> >
> >Â
> >
> >I'm with DavidÂ
> >
> >Â
> >
> >For example, to make UBL work for us in the
> >e-invoicing space e had to define a standard
> >state lifecycle - seeÂ
> ><http://ausdigital.org/specs/ausdigital-bill/1.0/>http://ausdigital.org/spe
> >cs/ausdigital-bill/1.0/. Â Â I don't think there's anything industry or
> >jurisdiction specific in that state
> >lifecycle. But without it, there is no shared
> >understanding of meaning of status fields in
> >response documents or when / how to process things like credit  notes etc
> >
> >Â
> >
> >I'm not saying that industry specific processes
> >don't exist. But I don't see why customizing a
> >standard process for a specific industry or
> >jurisdiction is any different to customizing
> >document semantics for that sector. And if
> >that's true then there's no reason not to define
> >some useful standard processesÂ
> >
> >Â
> >
> >CheersÂ
> >
> >
> >Steven Capell
> >
> >Mob: 0410 437854
> >
> >
> >On 11 Nov 2017, at 8:59 am, Kenneth Bengtsson
> ><<mailto:>> wrote:
> >
> >Hi David (and sorry for jumping late into the discussion)
> >
> >Â
> >
> >I would argue to the contrary, to be quite
> >frankly. Business processes may vary
> >significantly depending on industry, region,
> >culture, individual corporate requirements, and
> >any number of other parameters, making them hard
> >(if not impossible) standardize
> >â?ouniversallyâ??. There are a number of groups
> >that are standardizing business processes for
> >different purposes, and an even larger number of
> >solution providers offering standardization that
> >caters to specific segments and industries
> >â?"based on UBL documents. The ability to
> >provide syntax and semantic interoperability
> >traversing these diverse settings is what makes
> >UBL truly universal. If we were to make an
> >attempt at business process standardization as
> >well, we would fail to be universal and instead become an industry
> >standard.
> >
> >Â
> >
> >Best regards,
> >
> >Â
> >
> >Kenneth
> >
> >Â
> >
> >Â
> >
> >Â
> >
> >From: David Goodenough
> ><<mailto:>david.goodenough@broadwellma
> >nor.co.uk> Date: Friday, November 10, 2017 at 4:28 PM
> >To:
> >"<mailto:>"
> ><<mailto:>>
> >Subject: Re: [ubl-comment] Further thoughts on Party data for 2.3
> >
> >Â
> >
> >And it my contention that UBL will never be
> >Universal if you do not and will therefore have
> >failed to live up to UBL's full name. I know of
> >no other standard that takes the approach have half a standard is
> >acceptable.
> >
> >Â
> >
> >Yes you can keep your private profiles, must
> >there MUST be a default profile that can be
> >used, if you like, as a lowest common
> >denominator. It may not cover all possible uses
> >of all of UBL, but it should enable normal
> >business operations to happen in a common, well
> >documented way - process and all.
> >
> >Â
> >
> >It is my intention to produce just such a
> >default profile, suitable for SMEs. I have
> >started with what I know, that is the business
> >processes that we use here in the UK, and I know
> >these broadly match those in the EU and North
> >America and Australasia. I will then look for
> >input for things that need to change for the
> >rest of the world. Once I have completed this I
> >will be submitting it to the committee for inclusion in the standard.
> >
> >Â
> >
> >I believe without such a default profile UBL can
> >not fulfill its mandate and will not achieve
> >widespread use. If it is not widely used what is the point of having it?
> >
> >Â
> >
> >David
> >
> >Â
> >
> >On Friday, 10 November 2017 14:20:52 GMT G. Ken Holman wrote:
> > > Please note, David, that UBL states nothing normative regarding
> > > processes.
> > >
> > >
> > >
> > > All of the swim-lane diagrams in UBL are merely documentary to
> > >
> > > illustrate the context of use of the document types.
> > >
> > >
> > >
> > > It is the committee's expectation that all users of UBL will describe
> > >
> > > their own processes that may incorporate the use of UBL
> > >
> > > documents. Their use of our documents may lead to new requirements
> > >
> > > that users can submit through the public comment list (as you have
> > >
> > > been doing). I note that Roberto has recorded a candidate new
> > >
> > > business object for UBL 2.3 based on your email.
> > >
> > >
> > >
> > > But it has always been the view of the committee that processes
> > >
> > > differ around the world and so it is not in the purview of the
> > >
> > > committee to specify any in particular. The only normative
> > >
> > > components are the information bundles (the business objects) and the
> > >
> > > XML schemas.
> > >
> > >
> > >
> > > I hope this clarifies the role of the illustrative process diagrams
> > >
> > > in the UBL specification.
> > >
> > >
> > >
> > > . . . . . . Ken
> > >
> > > At 2017-11-10 09:03 +0000, David Goodenough wrote:
> > > >Should it be a BusinessCard, which (currently) has no process
> > > >
> > > >associated with it, or a revision DigitalAgreement, which does have
> > > >
> > > >a process associated with it and must be acknowledged to complete it?
> > > >
> > > >
> > > >
> > > >There is still however the question of whether the IssueDate (the
> > > >
> > > >only date in the BusinessCard and DigitalAgreement objects) is the
> > > >
> > > >date the notice is issued or the date from which it is valid. If the
> > > >
> > > >latter the description needs updating, if the former then we need to
> > > >
> > > >add a ValidFrom date so that you can find the most recent object
> > > >
> > > >valid from before today.
> > > >
> > > >
> > > >
> > > >But this still touches on the question of whether all the (in this
> > > >
> > > >case Party) master data should be included in the other messages, or
> > > >
> > > >whether just a reference to the master data (i.e. the now current
> > > >
> > > >version from the previous paragraph). While UBL allows the
> > > >
> > > >abbreviated form in that many field are optional and there are
> > > >
> > > >various IDs that can be the lookup key, none of the narrative
> > > >
> > > >suggests this as a suggested or even valid way of using it and none
> > > >
> > > >of the examples use it.
> > > >
> > > >
> > > >
> > > >David
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >On Thursday, 9 November 2017 22:18:22 GMT JAVEST by Roberto Cisternino
> > > >
> > > >wrote:
> > > >
> > > >
> > > >
> > > >Yes we are close,
> > > >
> > > >The issue with electronic business documents is similar to paper,
> > > >
> > > >the computer must be instructed to read party data and update master
> > > >
> > > >records if necessary, humans with paper can simply forget or skip such
> > > >
> > > >details.
> > > >
> > > >
> > > >
> > > >The availability of a specific message (BusinessCard) for
> > > >
> > > >communicating Party's info will facilitate the design of processes
> > > >
> > > >where the update of Party's info is covered by a precise transaction
> > > >
> > > >and business rules.
> > > >
> > > >
> > > >
> > > >Thanks
> > > >
> > > >Roberto
> > > >
> > > >
> > > >
> > > >Il 09/11/2017 21:46, Steve Capell ha scritto:
> > > >
> > > >
> > > >
> > > >I think we are saying the same thing.
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >If I send an invoice that says "please pay to account xyz" then that
> > > >
> > > >is what the recipient should do. Even if their supplier file says
> > > >
> > > >that supplier has payment account pqr
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >It's a separate thing to send a business card (or better still,
> > > >
> > > >point to a registry that holds it) that says "please change your
> > > >
> > > >master file so that all future Payments go to xyz"
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >Steven Capell
> > > >
> > > >
> > > >
> > > >Mob: 0410 437854
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >On 10 Nov 2017, at 7:33 am, JAVEST by Roberto Cisternino
> > > >
> > > ><<<mailto:>mailt
> >
> > o:><mailto:>robe
> > >>
> > > >wrote:
> > > >
> > > >
> > > >
> > > >I have few comments
> > > >
> > > > >The UBL invoice is a statement of transactional fact that is valid
> > > >
> > > > only in context of the specific invoice transaction and does
> > > >
> > > > not >imply any instruction to update master data.
> > > >
> > > >In the common business it is an error to ignore financial
> > > >
> > > >information (bank coordinates) provided along with the Invoice.
> > > >
> > > >For Party's legal name, address and Tax ID it is quite the same.
> > > >
> > > >
> > > >
> > > >Between well known trading partners it is common to receive an
> > > >
> > > >e-mail stating there have been a change in the company address, tax
> > > >
> > > >id or other data. The UBL BusinessCard holds Party information and
> > > >
> > > >is best suited for updating our partners with a new version of our
> > > >
> > > >business data/coordinates.
> > > >
> > > >
> > > >
> > > >The specific process and rules for using the BusinessCard are
> > > >
> > > >outside of scope of UBL, so implementers may decide to use the
> > > >
> > > >BusinessCard document together other transactions in the Billing
> > > >
> > > >process or other processes.
> > > >
> > > >
> > > >
> > > >The BusinessCard can be used into several processes:
> > > >
> > > >- Party Introduction process (just published online)
> > > >
> > > >- As part of other processes for communication of any business,
> > > >
> > > >legal, financial updates
> > > >
> > > >- As import/export format to/from business directories
> > > >
> > > >
> > > >
> > > >A business process (implementation) profile specification is the way
> > > >
> > > >to design this kind of business collaborations.
> > > >
> > > >
> > > >
> > > >Il 09/11/2017 11:18, steve capell ha scritto:
> > > >
> > > >
> > > >
> > > >Apologies in advance if I am stating the obvious here, but I think
> > > >
> > > >many of the discussions I have seen on this thread on this and
> > > >
> > > >similar topics may be confusing the idea of transaction data and master
> > > >
> > > >data.
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >In my view
> > > >
> > > > * The UBL invoice is a statement of transactional fact that is
> > > >
> > > >
> > > >
> > > > valid only in context of the specific invoice transaction and does
> > > >
> > > > not imply any instruction to update master data. "Here is my
> > > >
> > > > invoice for $200, please pay it to my account xyz".
> > > >
> > > >
> > > >
> > > > * If the supplier has separately sent a business card with bank
> > > >
> > > >
> > > >
> > > > account details then that does not override the specific
> > > >
> > > > instruction in the invoice. it would update the master data record
> > > >
> > > > of the buyer and would be relevant for things like RCTI (recipient
> > > >
> > > > created tax invoice) - eg "thanks for your timesheet, we've paid
> > > >
> > > > $200 into the account we have on file for you"
> > > >
> > > >The only time you'd look to your master data record for whatever is
> > > >
> > > >the current bank account details for your supplier is of the invoice
> > > >
> > > >payment means said something like "as per my business card that you
> > > >
> > > >can find at this end point URL". Personally I think it would be
> > > >
> > > >good practice to say exactly that. not just for bank account
> > > >
> > > >details but also for shipping addresses etc. But for it to work, I
> > > >
> > > >think the invoice as to say "please pay as per my current business
> > > >
> > > >card" and not "please pay as i specify in this document"
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >But UBL doesnt really (so far as I can see) have a means to say that.
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >On 9 November 2017 at 21:01, David Goodenough
> > > >
> > > ><<<mailto:.
> >
> > uk>mailto:>david.goodenough@broadwell
> > ma>
> > > ><http://nor.co.uk>nor.co.uk> wrote:
> > > >
> > > >
> > > >
> > > >This morning I got a letter from one of our suppliers saying that
> > > >
> > > >their bank details have changed. They were rather disorganized and
> > > >
> > > >the letter was dated 1st Nov and in the letter we were asked that
> > > >
> > > >all remittances from the 1st should go to the new bank! Quite what
> > > >
> > > >would have happened had we sent a payment between then and now is
> > > >
> > > >unspecified, and now long the old bank account still exists is
> > > >
> > > >likewise unspecified.
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >Now this not only has relevance to new invoices that we might
> > > >
> > > >receive from them, but also to existing ones. By this letter they
> > > >
> > > >are changing existing invoices retrospectively. How would that be
> > > >
> > > >expressed in UBL? Should the invoices be canceled and reissued - we
> > > >
> > > >have some that are not due for payment until the end of March but
> > > >
> > > >which we received last month?
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >The other thing that this letter raises and that seems to be missing
> > > >
> > > >from the existing Party data is a valid-from date. There is an issue
> > > >
> > > >date on the BusinessCard and DigitalAgreement objects, which I
> > > >
> > > >suppose could be used as a valid-from date, but that would the need
> > > >
> > > >the description tightening up a bit as the current description and
> > > >
> > > >name suggests that in the case above had they been more organized
> > > >
> > > >and sent the letter in advance of the change it would have been the
> > > >
> > > >letter date rather than the change date.
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >This brings to mind the whole question of whether the detail of the
> > > >
> > > >Party information should really be repeated on every other object,
> > > >
> > > >or whether some identifier (in old paper speak an account number)
> > > >
> > > >needs to be agreed as part of the DigitalAgreement (and its
> > > >
> > > >subsequent revisions possibly by BusinessCard) from then on the
> > > >
> > > >other documents only the identifier is given. The receiver then uses
> > > >
> > > >the time qualified version of the Party data in the agreement for
> > > >
> > > >any actions that need the information in the Party data. By time
> > > >
> > > >qualified I mean the most recent version where the valid-from date
> > > >
> > > >is less than today.
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >Now I can hear the response even as I type this. This is subject to
> > > >
> > > >the profile and the paper agreement that went with it. In my world
> > > >
> > > >there are no paper agreements (and no lawyers). What I am looking
> > > >
> > > >for is the right UBL way to do this, if you like some kind of
> > > >
> > > >default profile, or at least a narrative describing a suitable and
> > > >
> > > >functionally complete approach.
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >David
>
> --
> Contact info, blog, articles, etc. http://www.CraneSoftwrights.com/o/ |
> Check our site for free XML, XSLT, XSL-FO and UBL developer resources |
> Streaming hands-on XSLT/XPath 2 training class @ US$45 (5 hours free) |
