[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
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:kbengtsson@efact.pe>kbengtsson@efact.pe> 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@broadwellmanor.co.uk>david.goodenough@broadwellma > >nor.co.uk> Date: Monday, November 13, 2017 at 10:12 AM > > > >To: > >"<mailto:ubl-comment@lists.oasis-open.org>ubl-comment@lists.oasis-open.org" > ><<mailto:ubl-comment@lists.oasis-open.org>ubl-comment@lists.oasis-open.org> > >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:steve.capell@gmail.com>steve.capell@gmail.com> > >Date: Friday, November 10, 2017 at 5:45 PM > >To: Kenneth Bengtsson <<mailto:kbengtsson@efact.pe>kbengtsson@efact.pe> > >Cc: David Goodenough > ><<mailto:david.goodenough@broadwellmanor.co.uk>david.goodenough@broadwellma > >nor.co.uk>, > >"<mailto:ubl-comment@lists.oasis-open.org>ubl-comment@lists.oasis-open.org > >" > ><<mailto:ubl-comment@lists.oasis-open.org>ubl-comment@lists.oasis-open.org > >> 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:kbengtsson@efact.pe>kbengtsson@efact.pe> 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@broadwellmanor.co.uk>david.goodenough@broadwellma > >nor.co.uk> Date: Friday, November 10, 2017 at 4:28 PM > >To: > >"<mailto:ubl-comment@lists.oasis-open.org>ubl-comment@lists.oasis-open.org" > ><<mailto:ubl-comment@lists.oasis-open.org>ubl-comment@lists.oasis-open.org> > >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:roberto.cisternino@javest.com>mailt > > > > o:roberto.cisternino@javest.com><mailto:roberto.cisternino@javest.com>robe > > rto.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>mailto:david.goodenough@broadwellmanor.co.uk>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) |
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]