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