Document Logs
Change log:
Date: |
Author: |
Version: |
Changes: |
Completed |
Ext. |
Int. |
Is in Core |
|---|---|---|---|---|---|---|---|
| Unknown macro: {page-info} |
Unknown macro: {page-info} |
0.1 |
Doc. created |
Yes/No |
|
|
|
Terms and definitions:
Terms/definitions: |
Meaning: |
|---|---|
TBD |
To be defined |
N/A |
Not applicable |
1 - Purpose of Document
The purpose of this document is to provide an overview of the functionality and implementation of the SEPA Payment Engines.
2 - Introduction to Functionality
SEPA stands for Single Euro Payment Area. The objective of the SEPA is to provide standars for euro payments. All payments under this regulation are treated as domestic transactions. SEPA allows users to make payment transactions in Euro from a single bank account within Europe. SEPA offers a set of instruments to treat these payment transactions (SEPA Credit Transfers and SEPA Direct Debits)in an easy and secure way.
3 - Architecture and Design
All the payment transactios are XML based. In order to support the XML file generation and XML processing (reading) two Engines will be implemented:
- SEPA Generator: This engine will read the information from the SEPA Payment table and create the SEPA XML file depending on the payment type (Direct Debit or Credit Transfer).
- SEPA Reader: This engine will read the incoming SEPA XML and updte the corresponding SEPA tables.
3.1 - Object Model
The following diagram presents the main classes of the SEPA Generator:
3.2 - Data Model
The SEPA Engines use specific tables to retrieve and store information. The following ER diagram shows the relationship between the tables of the SEPA Generator Engine:
3.3 - Implementation Overview
This section will give an overview of the implementation, describing the functionality and purpose of important methods on classes or functionality stored in the database (PL/SQL, triggers etc.).
The actual implementation of the methods should not be described here; this should be documented in the code base.
4 - Configuration
If special setup is needed this should be described here. This goes for parameters or properties to be defined in the system, content of style sheets, templates, etc.
5 - Operational Considerations
This section describes how to use the functionality operationally.
For engines this includes how to initiate the functionality, how often the engine preferably should run and how to instantiate several instances of the engine.
This section might also include guidelines and suggestions to solve problems that might arise using this functionality. This part of the section should be extended regularly when problems or solutions to problems are found.