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