Fwd: OFBiz & SEPA (IBAN) processing

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

Fwd: OFBiz & SEPA (IBAN) processing

Pierre Smits-3
Hi all,

This is a follow-up on the posting earlier done on the user ML of the
project to explain a bit about a CAMT.053 document (xml) and how it will be
processed in the plugin component.

A CAMT.053 document contains the following:

   1. a main BkToCstmrStmt, which contains
      1. a header element (GrpHdr), which contains data to identify the
      message, when it was created and indicate how many pages the message
      contains;
      2. One (1) to N statements (STMT), with each statement containing:
         1. identifying and timestamp elements
         2. the IBAN account (bank account), the currency (currencyUomId)
         of the account and the BIC (Swift) code of the Financial
Institute the IBAN
         account is associated with
         3. opening and closing balances, with each having the amount (and
         the currency), the date, and whether it is a debit (DBIT) or
credit (CRDT)
         balance.
         4. One (1) to N statement entries (NTRY), containing:
            1. amount (and its currency) moving in or out of the IBAN
            account;
            2. book and value dates;
            3. SEPA transaction codes;
            4. party details received from or paid to (when the NTRY
            pertains to a SCT or SDD transaction), with IBAN account
and BIC details of
            parties involved;
            5. foreign currency amount (and its currency) (when applicable);
            6. additional NTRY information, like comments.

Based on the data provided in STMT elements 1,2 and 3 a check will be
performed to identify an existing GlReconciliation record for the
associated FinAccount, and if none exists create a new GlReconciliation
will be created.
The data in the NTRY element will be used to:

   1. check whether an existing FinAccountTrans exists, and if not create a
   new FinAccountTrans record;
   2. identify an existing external party (Customers, Suppliers, other);
   3. suggest matching to an existing payment (for approval/association,
   based on party found in aspect 2), and when matched create the Payment;
   4. suggest matching to outstanding invoice(s), based on a party found in
   aspect 2, and when matched create the Payment and the PaymentApplication
   records.


Best regards,

Pierre Smits

*Apache Trafodion <https://trafodion.apache.org>, Vice President*
*Apache Directory <https://directory.apache.org>, PMC Member*
Apache Incubator <https://incubator.apache.org>, committer
*Apache OFBiz <https://ofbiz.apache.org>, contributor (without privileges)
since 2008*
Apache Steve <https://steve.apache.org>, committer


---------- Forwarded message ---------
From: Pierre Smits <[hidden email]>
Date: Mon, Nov 26, 2018 at 10:51 AM
Subject: OFBiz & SEPA (IBAN)
To: <[hidden email]>


Hi All,

SEPA (Single European Payments Area) [1] is an payment-integration
initiative of the European Union, that is in play in the 28 member states
of the EU and the 4 member states of the EFTA (as well as Andorra, Monaco
and San Marino). It is intended to simplify bank transfers in Euro, as well
as cross-border transfers in and out of the eurozone countries, and is
standardised by ISO 20022 [2]. SEPA clearance is based on the IBAN
bank-account identification[3] (which has been adopted in over 70 countries
worldwide).

I have started working on a solution, that will (ultimately):

   1. register parties as banks, register bank accounts and associate these
   with banks and other parties (customers, suppliers, employees, etc.);
   2. process bank statements in camt.053.002.01 format, with
      1. processing statement entries as OFBiz financial account
      transactions (entity FinAccountTrans);
      2. processing payments from customer and suppliers as OFBiz payments
      (entity Payment);
      3. processing these payments as OFBiz payment applications against
      invoices (entity PaymentApplication), where possible;
   3.
   4. store the bank statements in the db as xml (optional) and/or as a
   file in CMS (optional);
   5. generate outgoing SEPA Credit Transfer (SCT) and SEPA Instant Credit
   Transfer (SCT inst) messages for invoice payment, and other payments, e.g.
   salaries, etc.)
   6. work with, and generate messages for SEPA Direct Debit (SDD).

Currently I have completed aspect 1, and I am making great strides in
aspect 2.

Is there an interest to have such a solution publicly available as a
pluggable OFBiz component? If so, please let me know (please also let me
know which OFBiz version you have implemented, or which version(s) you - as
an integrator - are developing for).


[1] https://en.wikipedia.org/wiki/Single_Euro_Payments_Area
[2] https://en.wikipedia.org/wiki/ISO_20022
[3] https://en.wikipedia.org/wiki/International_Bank_Account_Number


Best regards,

Pierre Smits

*Apache Trafodion <https://trafodion.apache.org>, Vice President*
*Apache Directory <https://directory.apache.org>, PMC Member*
Apache Incubator <https://incubator.apache.org>, committer
*Apache OFBiz <https://ofbiz.apache.org>, contributor (without privileges)
since 2008*
Apache Steve <https://steve.apache.org>, committer