[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

FpML-BP Payment message types



At last week’s meeting I said that I would send an email describing what I had found with the different payment message types, to show how Matt’s proposed payment type extension might fit in.

 

 

There are a couple of existing similar payment types in FpML that should be kept a consistent as possible.  I’ve omitted the annotations for clarity:

 

SimplePayment – in fpml-shared.xsd

 

                <xsd:complexType name="SimplePayment">

                                <xsd:sequence>

                                                <xsd:group ref="PayerReceiver.model"/>

                                                <xsd:element name="paymentAmount" type="Money"/>

                                                <xsd:element name="paymentDate" type="AdjustableOrRelativeAndAdjustedDate"/>

                                </xsd:sequence>

                </xsd:complexType>

 

 

PaymentMatchingfpml-reconciliation.xsd – this is the basis of Matt’s proposal.

 

                <xsd:complexType name="PaymentMatching">

                                <xsd:sequence>

                                                <xsd:element name="identifier" type="PaymentId"/>

                                                <xsd:group ref="PayerReceiver.model"/>

                                                <xsd:element name="paymentAmount" type="Money"/>

                                                <xsd:element name="calculationDetails" type="CalculationDetails" minOccurs="0" maxOccurs="unbounded"/>

                                </xsd:sequence>

                </xsd:complexType>

 

Matt proposes to add “adjustedPaymentDate” to the Payment Matching structure.

 

 

To keep these as similar as possible, to be consistent with the  existing types:

1)      the payment date should appear after the payment amount

2)      to make it more consistent with SimplePayment, it should perhaps be called “paymentDate” and allow adjustable dates as well as or instead of just adjusted payment dates.  (we should perhaps discuss this)

3)      there’s some opportunity for reusing the definitions.  Some possibilities include:
a) create a PaymentMatchingBase type that holds the first 3 elements/groups, and extend from that
b) create a PaymentMatchingModel group that also holds the same 3 elements, and us that in both type definitions.