OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ubl-comment message

[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]