OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

ubl message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [ubl] PaymentTerms->Amount

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

All the best

Stephen Green

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

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]