VS: [Fwd: Re: [ubl] PaymentTerms->Amount]

["Peter Borresen" <PLB@itst.dk>]

Hi Mark

Can we discuss this monday? Perhaps we should invite Roberto to join.

Kind regards

Peter

-----Oprindelig meddelelse-----
Fra: roberto@javest.com [mailto:roberto@javest.com]
Sendt: 8. juni 2007 13:39
Til: Peter Borresen
Cc: jon.bosak@sun.com
Emne: [Fwd: Re: [ubl] PaymentTerms->Amount]


Hello Peter,

1) About UBL Workshop in Rome:

We are arranging a 45 minutes presentation as required - I will send you
the Workshop final program soon.

2) PaymentTerms-Amount

I am not sure you had the time to evaluate the worksheet I attached into
my last email, but please I would like to know if the italian use cases I
presented are compliant with the NES / CEN work.

3) The CSI Piemonte S.p.A. (Piemonte is a northern regional subdivision in
Italy) was present at the NES Workshop in Brussels, they told me they are
very interested into NES and CEN/ISS work about e-procurement.
I found their address is not included in the mailing list of the CEN
Workshop.
I please ask you to include adriano.leli@csi.it into the next invitations
to join the CEN BII workshop.
I told them I could be available to support them, but they should pay my
subscription, travel, so on...
However at this moment I see the Piemonte italian region the only
opportunity to let Italy join the CEN BII Workshop for e-procurement.

4) As UBL ITLSC together my collegue Luca Reginato (Mercury Consortium -
Italian ERP/Accounting Software Houses - Technical Director) we could
produce some useful information to let NES / CEN BII be compliant with
italian use cases of UBL Documents.
This reason I have to understand if we can do it as LSC (as we have local
info) or what is the right channel.
Of course I understand the better situation is the italian government will
partecipate directly (e.g. through the Piemonte region)

Please advise about this.

I would like our efforts will be made in the right direction.

Best regards,

UBL ITLSC
co-chair
Roberto Cisternino

---------------------------- Original Message ----------------------------
Subject: Re: [ubl] PaymentTerms->Amount
From:    roberto@javest.com
Date:    Wed, June 6, 2007 11:12 pm
To:      "stephen.green@systml.co.uk" <stephen.green@systml.co.uk> Cc:    
 "ubl@lists.oasis-open.org" <ubl@lists.oasis-open.org>
--------------------------------------------------------------------------

Hello,

I am not sure there should be a direct relationship between payment
instalments and single invoice items amounts.

Usually instalments are calculated from the total of the document
according to some terms (e.g. 30 60 90) and by splitting the total into
equal parts or based on a percentage.

The only exception to this that I am aware of is about taxes (IVA/VAT),
these are commonly (in Italy) splitted uniformely on all instalments or
all into the 1st instalment.

This can be better understood on the attachment samples I made by
analyzing 2 well known accounting systems.

The 1st sample is about a complex splitted payment.
The 2nd is a sample about IVA/VAT issue where it is showed how an
accounting software configures the payment terms.

If we need any technical accounting information I could arrange an
interview with an expert from a local consortium made of ERP and common
accounting systems Producers.

Hope these samples are useful,
also the Payment Terms Amount (Peter asked for) can be easely identified
in the 1st sample to specify a fixed amount instalment.

Regards,

Roberto Cisternino
UBL ITLSC


Stephen Green wrote:
---------------------------------------------------------------------
Sorry to be putting the following points to the TC rather than PSC. Maybe
they should just be forwarded to PSC.

I can't add much light at this stage but I would add my own request too
that Payment/PaymentMeans/PaymentTerms be thoroughly thrashed out for UBL
2.1. There seem to be some aspects which may pose problems in any solution
such as whether something which is 0..1 can be made 0..n in a minor
version (and if not then what?).

We did a lot of work in that incredible last stint in Brussels on trying
to get the cardinalities of the relationships between these entities right
for 2.0 and maybe we didn't get it all quite perfect of course. We did
agree that the relationship between Payment and PaymentMeans (and perhaps
PaymentTerms too) should be many-to-many. We used IDs and references to do
this so that PaymentMeans can relate to several payments and several
PaymentMeans can relate to a single Payment or several Payments - at least
that was what was intended (at the last minute, like I say, but it seems
to work). The same with PaymentTerms - one PaymentTerms entity can relate
to several Payments or even to several PaymentMeans and likewise the other
way round round - one PaymentMeans or Payment can be related to one or
several PaymentTerms. It seems to work well enough.

So that ought to leave the possibility that there can be an Amount as a
property of a Payment, an Amount as a property of a PaymentMeans and an
Amount as a property of a PaymentTerms aggregate and it should all work
out. But it doesn't seem to be as simple as that since these can each have
various possible cardinalities in their relationships with the document
and its other associations and properties. 1) It might be best to make the
relationship between the relevant documents and * each * of these
aggregates a 0..n but that might not be easy when some are 0..1 in UBL 2.0
so some gaps may have to be filled some other way. And 2) It might be a
good thing to look at the other places there are in other aggregates -
such as AllowanceCharge - which have an Amount which needs to be related
to any or each of these payment-related aggregates and to examine the
effective cardinalities of how they all relate together. So can a single
PaymentTerms be somehow related to a single AllowanceCharge's qualified
Amount? Likewise can multiple PaymentTerms be somehow be related to a
single AllowanceCharge's qualified Amount? And maybe ask: Can multiple
AllowanceCharge's Amounts each be related to the same PaymentTerms? The
same would go for possible needs for relationships between Payment and
AllowanceCharge/xyzAmount and PaymentMeans
and AllowanceCharge/xyzAmount. With the latter it was disputed at one
point when some objected that it sounded illegal to make an
AllowanceCharge Amount dependant on the PaymentMeans, so that means it
must have been discussed.

To answer Peter: The latter discussion does seem to suggest that
PaymentMeans was to be related in some way to AllowanceCharge and this
seems to me to lend weight to the argument that it has been considered
that PaymentTerms too might
relate to the Amount in the AllowanceCharge. What then PaymentTerms' own
Amount property is to be used for I do not know - perhaps it was a
mistake.

To answer Robert: The whole thing has been discussed but perhaps not
enough so in my opinion it needs more discussion on what would be the gaps
to fill and then how to do that while maintaining backwards compatibility
in minor release(s).

All the best

-- 
Stephen Green

Partner
SystML, http://www.systml.co.uk
Tel: +44 (0) 117 9541606

http://www.biblegateway.com/passage/?search=matthew+22:37 .. and voice



Quoting roberto@javest.com:

> Hello Peter,
>
> I am dealing with this topic too,
>
> as in Italy we have many different payment terms use cases.
>
> Under a normal situation we could have something like this:
>
> 30-60-90
>
> which means the payment is splitted into equal parts, the 1st to be
payed after 1 month, the 2nd aftr 2 months, so on...
>
> But there are situation where payment is splitted with more complex rules:
>
> - different periods
> - different means of payment for each instalment
> - different composition of instalments as percentages %
> - special IVA/VAT payment terms
> - handling of "End of Month, End of next Month" expiration terms.
>
> Thus I think the Payment Term Amount is the explicit splitted part
according to the settlement period and its "description code" which
should clarify exactly that instalment.
>
> Usually accounting systems generates the instalments into a Bill Book
(something to take care of payment due) from the payment terms.
>
> But I think the explicit amount of the payment instalment is necessary
as not all accounting systems are able to understand automatically
payment terms.
>
> Hope this helps
>
> Best regards
>
> Roberto Cisternino
>
>
>> Dear all
>>
>> We have a discussed i NES the meaning of PaymentTerms->Amount. The
difinition
>> is "The payment amount for the Payment Terms.".
>> 1) Is this the amount the payment terms applies to (e.g. for split
payment)
>> 2) or is it a fixed penalty amount?
>>
>> Arguments for number 1:
>> * Since there can be multible PaymentTerms an implicit rule can be
given that the sum of PaymentTerms->Amount is equal
>> LegalMonetaryTotal->PayableAmount.
>> * If Amount was meant to be PenaltyAmount if would have been named
"PenaltySurchargeAmount" like PenaltyChageRate.
>>
>> Arguments for number 2
>> * PaymentDueDate is part of paymentMeans
>> * PaymentTerms->Amount is not part of UBL 1.0, but an new element
>>
>> Can anyone help me find out the original requirement for this? I would
also
>> like to have help with how to specify split payment in UBL + how to
specify a
>> fix penalty amount.
>>
>> Kind regards
>>
>> Peter
>>
>
>
> Roberto Cisternino
>






Roberto Cisternino

PaymentTerms.xls