TheCoreDev/bio-concept-labo
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Initial commit

Browse Source
This commit is contained in:
Laurent LE CORRE
2019-11-20 07:44:43 +01:00
commit 5bf49c4a81
41188 changed files with 5459177 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

70
web/modules/prelevementsepa/libs/docs/COMEDY-OF-ERRORS Normal file
View File

@@ -0,0 +1,70 @@
This file lists specific errors observed in the official IBAN specification.
In addition to the specific errors, there persist basic outstanding
matters that cause issue for implementers:
- Non 1:1 mapping of records to countries (eg: French territories, etc.)
- Mixing of free text and hard data in specification fields
- Missing clear definition of fields ("Domestic account number example" is
in many cases pre-IBAN era, in others it's an IBAN-era BBAN)
- Lack of validation of information in fields prior to publishing
- Lack of synchronisation between TXT and PDF versions of the registry
2016-01-31
----------
- SWIFT released a v63 registry PDF document supposedly
including a fix for the BBAN example for Israel with reason "typo", however
it still does not match with the specified BBAN format.
2016-01-21
----------
- Correction for broken example IBANs for multiple countries (checksum
failed, length incorrect, etc.)
- Correction for broken IBAN length field for Khazakstan (no specified
length whatsoever)
2011-07-16
----------
- No information for Kuwait past sixth column
- Total absence of information regarding Kazakhstan
- '1.00001E+15' instead of a valid BBAN example for Lithuania
- Repeated IBAN example in human format instead of IBAN format-
specification for UAE
- Incorrect domestic example for Bulgaria, Kazakhstan, Latvia,
Lithuania, Luxembourg, Macedonia, Mauritius, Romania, San Marino
(complete, human-format IBAN instead of domestic example)
Early 2012
----------
- Inconsistent record ordering (KW, KZ)
- Inconsistent capitalization (DK)
- Continued presence of incorrect domestic examples
February 2013
-------------
- Deployment of unparseable special values such as "Not in use" (FI).
- Still(!) missing a registry entry for 2010's 'new' entry of Khazakstan
September 2013
--------------
- Azerbaijan, Brazil, Costa Rica, Palestine, Virgin Islands 'SEPA
Country' field in PDF (yes/no) is completely blank
March 2014
----------
- In multiple cases, territories of a major country have a SEPA status
that differs from the parent jurisdiction. The IBAN specification as
previously released does not include individual records for these
territories, and thus cannot convey this important information.
- The IBAN registry's old URL is no longer publicly available! Its now
ends in a 404, and the apparent new home, located over at
http://www.swift.com/products_services/by_type/reference_data/iban_registry_iso13616
does not have any content. The parent portion of this part of the
SWIFT website suggests the information may have been moved to a new
'SWIFTRef' site, however that site appears to only peddle paid for
directories of BICs and similar. The new location after much
searching was found to be http://www.swift.com/products_services/bic_and_iban_format_registration_iban_format_r
June 2014
---------
- The TXT registry records of QA and JO do not match those within the
PDF and are essentially spurious while looking roughly correct. Dang.

BIN
web/modules/prelevementsepa/libs/docs/ECBS standard implementation guidelines SIG203V3.2.pdf Normal file
View File

Binary file not shown.

27
web/modules/prelevementsepa/libs/docs/FALSEHOODS.md Normal file
View File

@@ -0,0 +1,27 @@
# Falsehoods Programmers Believe About IBANs
In the spirit of [Falsehoods Programmers Believe About Phone Numbers](https://github.com/googlei18n/libphonenumber/blob/master/FALSEHOODS.md), here is a list of mistaken perspectives on International Bank Account Numbers (IBAN)...
1. **IBANs are global.**
While the IBAN system has been deployed in some states on most continents, it is a long way from achieving universal adoption. Certain states, such as Australia, when their High Value Clearing Payments Association were queried regarding their decision not to adopt IBAN, first refused to respond for upwards of 12 months then finally refused to release any reasoning. There are a lot of established interests that are against reduced barriers to financial systems integration.
2. **IBAN country codes are the same as ISO3166-1 alpha-2 country codes.**
Quite dangerously this is mostly, but not always the case. Both unofficial codes such as `AA` and various dependent territories which may use the parent jurisdiction's code instead of their own do not equate to the ISO3166-1 alpha-2 country code as expected.
3. **IBAN country codes are the same as IANA country codes.**
Quite dangerously this is mostly, but not always the case. Take for example `XK`, unofficial codes such as `AA`, or various dependent territories which may use the parent jurisdiction's code instead of their own.
4. **IBAN represents a 'free' and 'neutral' namespace for global financial cooperation.**
In fact, under the IBAN standard, which is managed by defacto global monopoly SWIFT, which has significant political significance to and affinity for US interests despite being a nominally Belgium-registered international cooperative, the only people who can create endpoints are existing financial institutions within countries holding an ISO3166-1 alpha-2 country code, a list which excludes many legitimate actors, virtually all innovators, plus the various states of the world with limited recognition. For a potentially mutually interoperable system adopted by some actors (eg. Bitcoin exchange Kraken) see the Internet IBAN (IIBAN) proposal at http://ifex-project.org/
5. **Pre-IBAN national checksums are still in operation.**
There is no way to reliably determine whether or not a given country had a national, pre-IBAN checksum system, whether that system was actually applied to all banks (certain central banks are known exceptions), or whether that system is still in operation after IBAN adoption. The `php-iban` library represents a best-effort approach to gathering this knowledge as appropriate.
6. **IBAN is clearly published standard.**
There are significant problems with the current dual-format publishing process used by SWIFT, which are documented [over here](https://raw.githubusercontent.com/globalcitizen/php-iban/master/docs/COMEDY-OF-ERRORS).
7. **IBANs are always written the same way.**
Some countries tend to continue to use methods of spacing/delineation amongst legacy components present within the IBAN. Others tend to concatenate the entire IBAN to a machine-readable single word. Still others use the human-style formatting with four characters per block, `XXXX YYYY ZZZZ 0000`. It is difficult to know how to best present an IBAN to a customer. In general, reasonable practice is that if the user is likely to manually transcribe (eg. via pen and paper) then a human format (four characters per block) is recommended. If the output is likely to be copy-pasted, however, then a single word (machine format) is preferred... in which case care should be taken to exclude neighbouring punctuation.
8. **IBAN solves input errors.**
IBAN has a strong checksum system built in, however this does not really help you to help the user find the source of an input problem. The `php-iban` library includes a flexible and robust mistranscription error detection system which can assist you in presenting possible errors to the user for manual evaluation.

63
web/modules/prelevementsepa/libs/docs/HACKING Normal file
View File

@@ -0,0 +1,63 @@
By unix tradition, this file outlines information that may be useful to
people who wish to modify the php-iban project. It outlines some basic
information around design decisions and other considerations.
Procedural style
----------------
The code is written in PHP's original procedural style, and does
not require or assume any OO model. This is unix tradition and
should ease any integration pains due to objectspace mismatches.
In addition, it should make it easy for users both within an OO
or a procedural codebase to make use of the library. An OO wrapper
has been supplied to make things more familiar for those who are
only exposed to OO PHP: please try to keep it in synch with the
procedural (main) library where possible.
Registry maintenance
--------------------
The 'convert-registry.php' tool found in the 'utils/' subdirectory
is intended to assist with the automatic conversion of the SWIFT-
provided 'IBAN Registry' text files to the format required to
support php-iban execution. Why is there a new format, and why is it
distributed with php-iban instead of being generated on the fly
from SWIFT-provided data files? There are a few reasons:
- Error correction
If errors are discovered in the official specification then they
can be resolved by us. There are (or have been) known errors
with the official IBAN Registry. (See COMEDY-OF-ERRORS)
- Exclusion correction
If exclusions are discovered in the official specification then
they can be resolved by us. There are (or have been) known
exclusions from the official IBAN Registry. (See COMEDY-OF-ERRORS)
- Efficiency
Because pattern matching is a core part of the functionality of
php-iban, and the pattern algorithms distributed by SWIFT are
(rather strangely) not in regular expression format, using their
files directly would result in a fairly significant startup
penalty as pattern conversion would be required (at each
invocation!) unless a caching strategy were deployed, which would
create additional complexity and sources of bugs (in addition,
due to the previous two points automatic conversion is not
presently possible ... and may never be!)
- Maintainability
Distribution of a modified registry along with php-iban places
the burden of registry maintenance on with the package
maintainer(s) rather than with the user. This is better for
users who, if they really want, can still hack their local copy.
Note that due to points one and two, the 'convert-registry.php' tool
is insufficient to produce a correct 'registry.txt' file. (You may
wish to review the differences between your newly generated file
and the original with the 'diff' tool in order to ascertain what
has changed.)
A closing point on the registry: obviously, if any new fields are
added, then it is best to append them to the end of the registry
(rightmost, new field) in order to preserve backwards compatibility
instead of re-ordering the fields which would break older installs.
(The internal '_iban_load_registry()' function re-orders these fields
at load time in order to simplify runtime debugging, anyway.)

BIN
web/modules/prelevementsepa/libs/docs/ISO13616.pdf Normal file
View File

Binary file not shown.

165
web/modules/prelevementsepa/libs/docs/LICENSE Normal file
View File

@@ -0,0 +1,165 @@
GNU LESSER GENERAL PUBLIC LICENSE
Version 3, 29 June 2007
Copyright (C) 2007 Free Software Foundation, Inc. <http://fsf.org/>
Everyone is permitted to copy and distribute verbatim copies
of this license document, but changing it is not allowed.
This version of the GNU Lesser General Public License incorporates
the terms and conditions of version 3 of the GNU General Public
License, supplemented by the additional permissions listed below.
0. Additional Definitions.
As used herein, "this License" refers to version 3 of the GNU Lesser
General Public License, and the "GNU GPL" refers to version 3 of the GNU
General Public License.
"The Library" refers to a covered work governed by this License,
other than an Application or a Combined Work as defined below.
An "Application" is any work that makes use of an interface provided
by the Library, but which is not otherwise based on the Library.
Defining a subclass of a class defined by the Library is deemed a mode
of using an interface provided by the Library.
A "Combined Work" is a work produced by combining or linking an
Application with the Library. The particular version of the Library
with which the Combined Work was made is also called the "Linked
Version".
The "Minimal Corresponding Source" for a Combined Work means the
Corresponding Source for the Combined Work, excluding any source code
for portions of the Combined Work that, considered in isolation, are
based on the Application, and not on the Linked Version.
The "Corresponding Application Code" for a Combined Work means the
object code and/or source code for the Application, including any data
and utility programs needed for reproducing the Combined Work from the
Application, but excluding the System Libraries of the Combined Work.
1. Exception to Section 3 of the GNU GPL.
You may convey a covered work under sections 3 and 4 of this License
without being bound by section 3 of the GNU GPL.
2. Conveying Modified Versions.
If you modify a copy of the Library, and, in your modifications, a
facility refers to a function or data to be supplied by an Application
that uses the facility (other than as an argument passed when the
facility is invoked), then you may convey a copy of the modified
version:
a) under this License, provided that you make a good faith effort to
ensure that, in the event an Application does not supply the
function or data, the facility still operates, and performs
whatever part of its purpose remains meaningful, or
b) under the GNU GPL, with none of the additional permissions of
this License applicable to that copy.
3. Object Code Incorporating Material from Library Header Files.
The object code form of an Application may incorporate material from
a header file that is part of the Library. You may convey such object
code under terms of your choice, provided that, if the incorporated
material is not limited to numerical parameters, data structure
layouts and accessors, or small macros, inline functions and templates
(ten or fewer lines in length), you do both of the following:
a) Give prominent notice with each copy of the object code that the
Library is used in it and that the Library and its use are
covered by this License.
b) Accompany the object code with a copy of the GNU GPL and this license
document.
4. Combined Works.
You may convey a Combined Work under terms of your choice that,
taken together, effectively do not restrict modification of the
portions of the Library contained in the Combined Work and reverse
engineering for debugging such modifications, if you also do each of
the following:
a) Give prominent notice with each copy of the Combined Work that
the Library is used in it and that the Library and its use are
covered by this License.
b) Accompany the Combined Work with a copy of the GNU GPL and this license
document.
c) For a Combined Work that displays copyright notices during
execution, include the copyright notice for the Library among
these notices, as well as a reference directing the user to the
copies of the GNU GPL and this license document.
d) Do one of the following:
0) Convey the Minimal Corresponding Source under the terms of this
License, and the Corresponding Application Code in a form
suitable for, and under terms that permit, the user to
recombine or relink the Application with a modified version of
the Linked Version to produce a modified Combined Work, in the
manner specified by section 6 of the GNU GPL for conveying
Corresponding Source.
1) Use a suitable shared library mechanism for linking with the
Library. A suitable mechanism is one that (a) uses at run time
a copy of the Library already present on the user's computer
system, and (b) will operate properly with a modified version
of the Library that is interface-compatible with the Linked
Version.
e) Provide Installation Information, but only if you would otherwise
be required to provide such information under section 6 of the
GNU GPL, and only to the extent that such information is
necessary to install and execute a modified version of the
Combined Work produced by recombining or relinking the
Application with a modified version of the Linked Version. (If
you use option 4d0, the Installation Information must accompany
the Minimal Corresponding Source and Corresponding Application
Code. If you use option 4d1, you must provide the Installation
Information in the manner specified by section 6 of the GNU GPL
for conveying Corresponding Source.)
5. Combined Libraries.
You may place library facilities that are a work based on the
Library side by side in a single library together with other library
facilities that are not Applications and are not covered by this
License, and convey such a combined library under terms of your
choice, if you do both of the following:
a) Accompany the combined library with a copy of the same work based
on the Library, uncombined with any other library facilities,
conveyed under the terms of this License.
b) Give prominent notice with the combined library that part of it
is a work based on the Library, and explaining where to find the
accompanying uncombined form of the same work.
6. Revised Versions of the GNU Lesser General Public License.
The Free Software Foundation may publish revised and/or new versions
of the GNU Lesser General Public License from time to time. Such new
versions will be similar in spirit to the present version, but may
differ in detail to address new problems or concerns.
Each version is given a distinguishing version number. If the
Library as you received it specifies that a certain numbered version
of the GNU Lesser General Public License "or any later version"
applies to it, you have the option of following the terms and
conditions either of that published version or of any later version
published by the Free Software Foundation. If the Library as you
received it does not specify a version number of the GNU Lesser
General Public License, you may choose any version of the GNU Lesser
General Public License ever published by the Free Software Foundation.
If the Library as you received it specifies that a proxy can decide
whether future versions of the GNU Lesser General Public License shall
apply, that proxy's public statement of acceptance of any version is
permanent authorization for you to choose that version for the
Library.

207
web/modules/prelevementsepa/libs/docs/README Normal file
View File

@@ -0,0 +1,207 @@
php-iban README
---------------
php-iban is a library for parsing and validating International Bank
Account Number (IBAN) information in PHP.
It also validates Internet International Bank Account Number
(IIBAN) as specified at http://tools.ietf.org/html/draft-iiban-01
(see also http://www.ifex-project.org/our-proposals/iiban)
php-iban lives at http://code.google.com/p/php-iban
What is an IBAN?
----------------
An IBAN is basically a standardised way of explaining a bank
account number that works across borders. Its structure is:
<Two Letter ISO Country Code> + <Two Digit Checksum] + <BBAN>
BBAN is the term used to describe the national-level format
for a bank account number, which varies between countries
(and was sometimes created just to get IBAN connectivity!).
Note that a BBAN may have its own checksum algorithm.
IBAN provides basic protection, using the checksum, against
transcription (ie: human copying) errors. It also provides
a registry of valid destination countries and their BBAN
formats. Thus, when you ask php-iban to 'validate' an IBAN
it ensures that these checks are passed. However, it cannot
ensure that a bank account actually exists - the only party
who can do that is the receiving bank or country.
IBAN was invented in Europe, however its usage is growing
rapidly to other parts of the world. Thus, the future of
this library looks pretty good.
For further information, please see 'docs/ISO13616.pdf' or
visit Wikipedia at http://en.wikipedia.org/wiki/IBAN
What is an IIBAN?
-----------------
An Internet IBAN (IIBAN) identifies an internet-based financial
endpoint in a manner that is superset-compatible with the existing
European Committee for Banking Standards (ECBS) International Bank
Account Number (IBAN) standard [ISO13616].
For more information see http://tools.ietf.org/html/draft-iiban-00
and http://www.ifex-project.org/our-proposals/iiban
To disable IIBAN support from your installation, simply remove
the second ('AA|...') line from the top of the registry.txt file.
Execution environment
---------------------
At present the library merely requires a PHP engine to be present
and has no external dependencies. It is recommended that your
PHP engine is configured to disable verbose warnings for events
such as access of unknown array indexes, though this should be
standard on almost any PHP deployment today. Any PHP engine
in use today should be compatible, though PHP3 or PHP4 execution
environments may require minor modifications (specifically,
some string functions may have changed).
Installation
------------
Simply copy 'php-iban.php' and 'registry.txt' to an appropriate
location for your project. The location of the files will affect
the 'require_once()' line used to load the library from your
codebase, and may have relevance security (see 'Security' below).
Note that 'php-iban.php' expects to find 'registry.txt' in the
same directory as itself.
Security
--------
Following best practice for library files, the location chosen
for the php-iban.php and registry.txt files should ideally be
outside of any web-accessible directories. Thus, if your
web project lives in /var/www/myproject/htdocs/ then it would
be preferably to place php-iban in /var/www/myproject or some
other directory that is not visible to regular web users.
Secondly, neither file should be writable by the web server
itself in order to prevent compromise of the execution path
(ie: getting hacked). So, for example if your web server runs
as user 'www', group 'www', you can ensure that the web server
has minimal required privileges against the files as follows
(note that you will need to be root to execute these commands):
# chown <myuser> php-iban registry.txt # where <myuser> is a
# non-root user that
# is not 'www'.
# chgrp www php-iban registry.txt # set group to 'www'
# chmod ugo-rwx php-iban registry.txt # remove privileges
# chmod g+r php-iban registry.txt # allow 'www' group
# to read the files
Obviously the above do not apply if you are using PHP in a
non web-oriented project (eg: a cronjob or daemon), a usage
of the language that is apparently growing - but limited.
Using the library
-----------------
Basic invocation is as follows:
# include the library
require_once('/path/to/php-iban.php'); # /path/to/ is optional
# use some library function or other...
if(!verify_iban($iban_to_verify)) {
# blame the user...
}
Note that because the library is designed in a procedural manner
rather than an object-oriented manner it should be easy to
integrate with a wide variety of established codebases and
PHP interpreter versions.
Using the library's OO wrapper
------------------------------
Because many new PHP programmers seems to learn the language via
books that only teach OO based programming and are thus unfamiliar
with procedural PHP (and often relatively inexperienced as
programmers, too) an OO wrapper-library has been provided.
======================= READ THIS =================================
However *you should avoid excessive use of OO*. For some thought
provoking discussions of the negative aspects of overusing OO,
please refer to 'Coders at Work' and 'The Art of UNIX Programming'.
(OO is great for some problems, but simply pointless for most.)
===================================================================
Anyway, to use the OO wrapper supplied, invocation is as follows:
# include the OO wrapper to the library
require_once('/path/to/oophp-iban.php'); # /path/to is optional
# instantiate an IBAN object
$myIban = new IBAN('AZ12345678901234');
if(!$myIban->Verify()) {
# blame the user...
}
Documentation
-------------
There are three types of functions provided by the library:
- IBAN-level functions
These are functions that operate on an IBAN. All of these
functions accept either machine format or human format
IBANs as input. Typically they return facts about an IBAN
as their output (for example whether it is valid or not,
or the BBAN (national-level) portion of the IBAN), though
some of them may perform other functions (eg: fixing a
broken IBAN checksum). These functions are named 'iban_*'
with the exception of the most commonly used function,
'verify_iban()', and excepting the country-level functions.
(Regarding the object oriented wrapper - all of these
functions are implemented as methods on IBAN objects)
- IBAN country-level functions
These functions return information about countries that are
part of the IBAN standard. They each take the two letter
ISO country code at the beginning of an IBAN as their
argument. They are named 'iban_country_*', with the
exception of 'iban_countries()' which returns a list of
the known IBAN countries. (For example, functions that
return an example IBAN or BBAN for the country, or the
name of the country.)
(Regarding the object oriented wrapper - all of these
functions are implemented as methods on IBANCountry
objects, except for 'iban_countries()' which is
implemented as the Countries() method on the IBAN class)
- Internal functions
These functions begin with '_iban_*' and can be ignored.
(Regarding the object oriented wrapper - these functions
are not present)
Please refer to either http://code.google.com/p/php-iban or the
commented source code of php-iban itself for the complete list of
which functions are available. Of course, in unix style one could
achieve the same in a pinch as follows (instant documentation!):
$ grep function php-iban.php
$ egrep '(Class|function)' oophp-iban.php
Community
---------
You are encouraged to contribute bugs, feedback and suggestions
through the project's website.
Particularly if you deploy php-iban in a commercial setting, you are
STRONGLY encouraged to join the project's mailing list, which can
be found via the website. Joining the mailing list ensures that you
can be made aware of important updates. Important updates include:
- Updates to new registry editions (support new countries that have
been added to the IBAN system)
- Bug fixes
- Security updates
The email list receives almost no traffic and as a 'Google Group' is
well protected from spam, so don't worry about junk in your inbox.
Thanks for choosing php-iban! You have excellent taste in software ;)

17
web/modules/prelevementsepa/libs/docs/REGISTRY-URL Normal file
View File

@@ -0,0 +1,17 @@
To get the latest ISO13616 IBAN registry, go to:
https://www.swift.com/standards/data-standards/iban#topic-tabs-menu
TXT format:
https://www.swift.com/node/11971
PDF format:
https://www.swift.com/file/5996/download?token=lf3shUpn
Unfortunately, it has been noticed in 2011 that the official .txt file is
not an accurate representation of the PDF format specification, and lacks
some information. It is hoped that in future SWIFT will be more careful to
publish only correct standards information.
It has been noted in 2014 that this is still the case.
(For more information on this subject, see the HACKING file)

9
web/modules/prelevementsepa/libs/docs/SEPA Normal file
View File

@@ -0,0 +1,9 @@
Interpreting the SEPA Field
===========================
Note that some IIBAN providers may in fact provide SEPA connectivity.
Thus, implementers are reminded to consider the reported SEPA status
of a country within the registry as confirming rather than negating
the potential SEPA status of a potential financial institution who
may be party to a proposed transaction.

27
web/modules/prelevementsepa/libs/docs/TESTING.md Normal file
View File

@@ -0,0 +1,27 @@
Testing
-------
This document describes the project's approach to testing. Essentially we do not require tests
for all code but do strive to maintain reasonable test coverage.
Local testing
-------------
To run local tests, simply execute the appropriate group of tests in the `utils` subdirectory.
For example:
```sh
$ php utils/test.php # Run main tests
$ php utils/ootest.php # Run object-oriented wrapper tests
$ php utils/other-test.php # Run additional tests
```
Automated testing
-----------------
The project uses the free Travis Continuous Integration (CI) service to test new code.
The service runs automatically every time code is committed, and the results will be emailed
and displayed publicly on the project's github page.

35
web/modules/prelevementsepa/libs/docs/index.php Normal file
View File

@@ -0,0 +1,35 @@
<?php
/*
* 2007-2017 PrestaShop
*
* NOTICE OF LICENSE
*
* This source file is subject to the Academic Free License (AFL 3.0)
* that is bundled with this package in the file LICENSE.txt.
* It is also available through the world-wide-web at this URL:
* http://opensource.org/licenses/afl-3.0.php
* If you did not receive a copy of the license and are unable to
* obtain it through the world-wide-web, please send an email
* to license@decanet.fr so we can send you a copy immediately.
*
* DISCLAIMER
*
* Do not edit or add to this file if you wish to upgrade PrestaShop to newer
* versions in the future. If you wish to customize PrestaShop for your
* needs please refer to http://www.decanet.fr for more information.
*
* @author SARL DECANET <contact@decanet.fr>
* @copyright 2007-2017 PrestaShop SA
* @license http://opensource.org/licenses/afl-3.0.php Academic Free License (AFL 3.0)
* International Registered Trademark & Property of PrestaShop SA
*/
header("Expires: Mon, 26 Jul 1997 05:00:00 GMT");
header("Last-Modified: ".gmdate("D, d M Y H:i:s")." GMT");
header("Cache-Control: no-store, no-cache, must-revalidate");
header("Cache-Control: post-check=0, pre-check=0", false);
header("Pragma: no-cache");
header("Location: ../");
exit;