Re: [ubl-comment] Further thoughts on Party data for 2.3

[David Goodenough <david.goodenough@broadwellmanor.co.uk>]

On your point of transaction data and master data, I think part of the problem (and part of the potential solution I mentioned at the end of my original email) is that UBL has little concept of using master data, all the data is always repeated in every transaction.

 

There is the DigitalAgreement, which is the logical object to establish the master data, but all of the Party information is then repeated on every transaction and there is no architected way to refer to that master data. If my potential solution were implemented then actually the default we would be using your "use the (current) business card" model.

 

As to your bullet points, yes that is the way UBL seems to expect the world to work, unfortunately at least in my (SME) world it does not. I would be astonished if this supplier re-issued the invoices with the new bank details, and also if the old bank account stayed open long enough that at the end of March next year when I have to pay them I could still use it. The problem is, how do we cope with the world as it operates and represent that best we can in UBL?

 

David

 

On Thursday, 9 November 2017 21:18:05 GMT steve capell wrote:

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 <david.goodenough@broadwellmanor.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