Table of contents
Data model
Debt position management
The debt position (PD) has the following relationships
- A PD is connected to a debtor (Deb) . If there is a Deb, at least one PD is connected to it.
- A PD can have multiple payment options (OdP). At least one exists. One OdP is connected to only one PD.
- An OdP can have multiple payments, equal to the number of Creditors (EC) to which they refer. At least one exists. One payment is connected to only one OdP.
Logical scheme (ER)
.png)
At a high-level the debt position has the following characteristics
- IUPD : univocal debt position identifier
- Creditor - Fiscal code of the creditor “operator” of the PD.
- Creditor registry office - (company name, department, office, …)
- Date of validity (start)- date from which the PD is valid and payable
- Date of publication - date on which the PD is published on the system
- Expiration[flag]: indicates if the PD must be invalidated upon expiration or no
At a high-level the debtor has the following characteristics
- Type: indicates if it is a physical or legal person
- Identifier: Fiscal code (or also VAT no. in case of a legal person) of the debtor
- Address [optional] : City, province, address, etc.
- Email [optional]
- Telephone number [optional]
At a high-level a payment option has the following characteristics
- IUV - Univocal Payment Identifier, the identifier used by the NodoSPC for the payment will be univocal for each OdP
- Creditor - CF of the creditor “operator” of the PD. It is used together with the IUV to univocally identify a payment.
- Amount - amount foreseen for the OdP.
- Description - a brief description of the content of the OdP (e.g.: in case of a reduction, it could be “30% reduction if the payment is made within 7 days of issue of the PD“ )
- Installment [flag] - indicates if the option is part of an installment payment. In the case of an installment payment, the associated PD is to be considered “paid” only when all the installments are paid.
- Date of expiration (end) - date by which the OdP is payable
- Metadata [optional] - array that permits the ECs to enter information useful to them, typically related to account reconciliation, alignment of management programs, etc. It must have a limit and explicit size (with relative error msg in case of saturation)
At a high-level the payment has the following characteristics
- Payment ID: (progressive) identifier of a payment within an OdP
- Creditor: institution beneficiary of the payment
- Amount: amount foreseen for the payment
- Payment reason: Reason for the individual payment
- Taxonomy: Taxonomy of the service associated with payment.
- IBAN: IBAN to which the amount will be transferred.
Spontaneous payment
We can consider a spontaneous payment as a “special case” of a Debt position that is created at the moment of the request by the user.
In case of a spontaneous payment:
- A OdP corresponds to the request for a Spontaneous payment (PS).
- An OdP can be associated with multiple possible payments (based on the type of spontaneous payment).
- The PD connected to the OdP will have only that OdP.
- A CIT can have one or more PDs (if a CIT exists in the system, there must be at least one).
Enrollment to spontaneous payment services (logical scheme)
.png)
A Creditor who has registered for spontaneous payment management, can register with multiple services. The availability of the services depends on the service catalog of the pagoPA platform.
Some relevant properties of the relationships in question are provided below.
Creditor
- identifier: Fiscal code of the creditor that registered for management of spontaneous payment services
- company name: The company name of the creditor.
Service
- idServizio: ID of the service, as defined by the pagoPa platform with the service catalog
- name: name of the service
- description: description of the service
- service properties: for managing the specific characteristics of the service
- taxonomy: taxonomy of the service
Enrollment
- IBAN: IBAN for collecting the spontaneous payments generated for a specific service
- office name: office of reference for the specific service
- payment reason: payment reason to be assigned to spontaneous payments generated for a specific service
PA postal payment slip
If the EC has at least one postal current account for collections, it is necessary that it follows what is indicated in Bollettino postale pa for the creation of the PD.
Tell us what you think
For clarifications on implementation specifications, such as SACI and SANP, you can open an issue on GitHub