[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ubl-comment] Further thoughts on Party data for 2.3
|
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’s what we’ve done in UBL, isn’t it? The suggestion was to make these processes normative in the UBL spec, and I’m 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’t 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’t 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’t 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’s a different solution to the same problem (fiscal control). I don’t think it’s the role of the UBL TC to globally
standardize tax systems, nor to be judge over which countries have the “right” 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 <david.goodenough@broadwellmanor.co.uk> 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’t 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 <steve.capell@gmail.com>
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/.
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
Mob: 0410 437854
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 “universally”.
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 <david.goodenough@broadwellmanor.co.uk>
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:roberto.cisternino@javest.com>roberto.cisternino@javest.com>
> >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:david.goodenough@broadwellmanor.co.uk>david.goodenough@broadwellma
> >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) |
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]