For the re-routing of payment of
selected invoices the statement is still a good solution, you need
to provide a meaninful cbc:StatementTypeCode to clearly identify
the case, but again this is more a process detail.
You can use UBL documents as different transactions into many
different processes.
Using a CustomizationID and a ProfileID you can precisely indicate
the process profile and the business transaction.
//Roberto
Il 20/08/2018 17:23, David Goodenough ha scritto:
The BusinessCard is a good solution for "all future invoices", but the second problem is the re-routing of payment for specific existing invoices as the BusinessCard has no list of invoices/credit/debit notes to which is could apply.
If Statement is not the solution, is there another possibility?
David
On Monday, 20 August 2018 14:23:11 BST JAVEST by Roberto Cisternino wrote:
> The general document intended for communicating Party information as
> well as its banking coordinates, legal and tax info is the UBL Business
> Card.
> Of course the use of this new document into specific transactions such
> as the bank coordinates update must be described into an implementation
> profile.
>
> The Statement is of course a good solution and is actually acting as a
> gentle reminder for the Payer, but again the update of Party info must
> be described in a clear process and agreed beetween parties.
>
> // Roberto
>
> Il 20/08/2018 12:32, David Goodenough ha scritto:
> > An Invoice is an immutable object once it is issued, changes such as
> > updating individual line items or canceling out an an entire invoice
> > are done using a credit note.
> >
> > But how are changes such as the destination bank account for the
> > payment for the invoice distributed.
> >
> > If a supplier changes bank account then obviously all new invoices
> > will be set up with the new bank details, but what about existing
> > invoices? While it is unlikely that such a change would occur during
> > the normal 30 day or so life of an outstanding payment, some payments
> > are made over an extended period which can last for years. We (a farm)
> > were notified that the company providing the 5 year 0% HP deal on a
> > tractor was, 2 years into the deal, moving its bank account. We were
> > notified by letter, which we confirmed by ringing them to make sure
> > this was not fraudulent.
> >
> > We also get cases where a supplier of seed issues a set of invoices
> > which are issued with a 3 month payment period and are bundled
> > together before the due date and factored so that we end up paying a
> > third party, and it was not known at the time of the invoice that this
> > would happen (we get to choose if we want to take advantage although
> > as it typically is a 0% deal over more like 6 months it is a bit of a
> > no brainer). So in this case we change not only the financial account
> > to which it is to be paid, but also due date, and the reference we
> > give with the payment is a single reference for the whole bundle
> > rather than individual invoice references.
> >
> > The Reminder document could I think not be used for this as it is
> > supposed to be for overdue payments.
> >
> > However the Statement could be used for this. The Statement would list
> > the invoices being adjusted and supply new PayeeParty and
> > PaymentMeans/PayeeFinancialAccount. The new due date can be encoded in
> > the PaymentTerms/PaymentDueDate object. I don't think that there is
> > any rule that a Statement must list all outstanding
> > Invoices/Credits/Debits, so it can be used to adjust only those
> > invoices that need adjusting.
> >
> > Is this a suitable approach, or is there another solution that I have
> > missed?
> >
> > David