Page Comparison

{noprint}{float:right|width=300px|background=lightgrey|border=solid blue 2px|margin=10px|padding=8px}
*Contents*
{toc:all=true|depth=4|excerpt=true|indent=14px}
{float}{noprint}{table-plus:width=665|enableSorting=false}




*Document Logs*
*Change log:*
|| *Date:* || *Author:* || *Version:* || *Changes:* || Completed || Ext. || Int. || Is in Core ||
| {page-info:created-date|dateFormat=dd MMMM yyyy} | {page-info:created-user} | 0.1 | Doc. created | Yes/No | | | |

*Terms and definitions:*
|| Terms/definitions: || Meaning: ||
| TBD | To be defined |
| N/A | Not applicable |
\---- 




h2. 1 - Purpose of Document
The purpose of this document is to provide an overview of the functionality and implementation of the SEPA Payment Engines.






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






h2. 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 incominfincoming SEPA XML and updte the corresponding SEPA tables.





h3. 3.1 - Object Model
The object model is supposed to describe how the functionality is mapped into objects, and how the relationship between the object model and other standard objects within the system. Typically, the description would include drawings (like UML diagrams) showing the relationship.

{tip:title=Examples:}
Describing the terminate() method on a Subscription could be described showing the relationship between the classes Subscription, SubscriptionLockin, Service, SubscriptionTermination etc.
{tip}








h3. 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:

{gliffy:name=ER SEPA Generator Tables|version=1}



The data model describes how the functionality is using tables within the database. Often there is a one-to-one relationship between the object model and data model, but sometimes additional database tables are use.

If no database tables are used, this section might be removed.





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





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





h2. 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.
{table-plus}