Party Bank information

[sampac]

Does anyone know of a Tryton module to add bank information to a party
(something like bank.partner.bank in OpenERP) ?
If not I will code it so please give me any requirements you would
have for such module

[Cédric Krier]

I think an important thing to take care is that a bank account could
have multiple representation like national number and IBAN.

--
Cédric Krier

B2CK SPRL
Rue de Rotterdam, 4
4000 Liège
Belgium
Tel: +32 472 54 46 59
Email/Jabber: cedric...@b2ck.com
Website: http://www.b2ck.com/

[Romain Séon]

On Sun, Jun 24, 2012 at 9:32 PM, Cédric Krier <cedric...@b2ck.com> wrote:

On 23/06/12 03:15 -0700, sampac wrote:
> Does anyone know of a Tryton module to add bank information to a party
> (something like bank.partner.bank in OpenERP) ?
> If not I will code it so please give me any requirements you would
> have for such module

 

I'm also working on this subject.

I think an important thing to take care is that a bank account could
have multiple representation like national number and IBAN.

The IBAN only works mainly for european countries and can be calculated from the national number, I'm not sure we need to store both informations.

Romain

[Cédric Krier]

On 25/06/12 17:10 +0200, Romain Séon wrote:
> On Sun, Jun 24, 2012 at 9:32 PM, Cédric Krier <cedric...@b2ck.com> wrote:
>
> I think an important thing to take care is that a bank account could
> > have multiple representation like national number and IBAN.
> >
> > The IBAN only works mainly for european countries and can be calculated
> from the national number, I'm not sure we need to store both informations.

The adoption is larger than Europe
https://en.wikipedia.org/wiki/IBAN#Adoption

But I think each form should be stored in the database to be able to
search for it. And more over, we don't know if there will always be a
transformation.

[sampac]

On 25 juin, 17:10, Romain Séon <rom1.try...@gmail.com> wrote:

> On Sun, Jun 24, 2012 at 9:32 PM, Cédric Krier <cedric.kr...@b2ck.com> wrote:
> > On 23/06/12 03:15 -0700, sampac wrote:
> > > Does anyone know of a Tryton module to add bank information to a party
> > > (something like bank.partner.bank in OpenERP) ?
> > > If not I will code it so please give me any requirements you would
> > > have for such module
>
> I'm also working on this subject.
>
> I think an important thing to take care is that a bank account could> have multiple representation like national number and IBAN.
>
> > The IBAN only works mainly for european countries and can be calculated
>
> from the national number, I'm not sure we need to store both informations.
>
> Romain
>

Oh! What's your status Romain ? I'm nearly done with a module.
I integrated extensible number of account types. For the moment I can
do IBAN with ibanlib and french RIB

>
>
>
>
>
>
> > --
> > Cédric Krier
>
> > B2CK SPRL
> > Rue de Rotterdam, 4
> > 4000 Liège
> > Belgium
> > Tel: +32 472 54 46 59

> > Email/Jabber: cedric.kr...@b2ck.com
> > Website:http://www.b2ck.com/

[Rom1]

On Mon, Jun 25, 2012 at 5:28 PM, sampac <*@sampaccoud.com> wrote:

On 25 juin, 17:10, Romain <rom1.try...@gmail.com> wrote:

> On Sun, Jun 24, 2012 at 9:32 PM, Cédric Krier <cedric.kr...@b2ck.com> wrote:
> > On 23/06/12 03:15 -0700, sampac wrote:
> > > Does anyone know of a Tryton module to add bank information to a party
> > > (something like bank.partner.bank in OpenERP) ?
> > > If not I will code it so please give me any requirements you would
> > > have for such module
>
> I'm also working on this subject.
>
> I think an important thing to take care is that a bank account could> have multiple representation like national number and IBAN.
>
> > The IBAN only works mainly for european countries and can be calculated
>
> from the national number, I'm not sure we need to store both informations.
>
> Romain
>

Oh! What's your status Romain ? I'm nearly done with a module.
I integrated extensible number of account types. For the moment I can
do IBAN with ibanlib and french RIB

Not very far : http://pastebin.com/aJ2rQbgC

 

>
>
>
>
>
>
> > --
> > Cédric Krier
>
> > B2CK SPRL
> > Rue de Rotterdam, 4
> > 4000 Liège
> > Belgium
> > Tel: +32 472 54 46 59

> > Email/Jabber: cedric.kr...@b2ck.com
> > Website:http://www.b2ck.com/

--
--
try...@googlegroups.com mailing list

[Rom1]

On Mon, Jun 25, 2012 at 5:46 PM, Cédric Krier <cedric...@b2ck.com> wrote:

On 25/06/12 17:10 +0200, Romain wrote:
> On Sun, Jun 24, 2012 at 9:32 PM, Cédric Krier <cedric...@b2ck.com> wrote:
>

> I think an important thing to take care is that a bank account could
> > have multiple representation like national number and IBAN.
> >
> > The IBAN only works mainly for european countries and can be calculated
> from the national number, I'm not sure we need to store both informations.

The adoption is larger than Europe
https://en.wikipedia.org/wiki/IBAN#Adoption

I said "mainly Europe", and you're there is a few more country using it :)

 

But I think each form should be stored in the database to be able to
search for it. And more over, we don't know if there will always be a
transformation.

 

We should store the iban number whatever the account is? Even for a us account, whish is not compatible with the IBAN ?

[Cédric Krier]

On 25/06/12 18:19 +0200, Rom1 wrote:
> On Mon, Jun 25, 2012 at 5:46 PM, Cédric Krier <cedric...@b2ck.com> wrote:
> But I think each form should be stored in the database to be able to
> > search for it. And more over, we don't know if there will always be a
> > transformation.
> >
>
> We should store the iban number whatever the account is? Even for a us
> account, whish is not compatible with the IBAN ?

Of course it makes no sense to store something that doesn't exist.

[sampac]

On 25 juin, 18:19, Rom1 <rom1.try...@gmail.com> wrote:

> On Mon, Jun 25, 2012 at 5:46 PM, Cédric Krier <cedric.kr...@b2ck.com> wrote:
> > On 25/06/12 17:10 +0200, Romain wrote:

> > > On Sun, Jun 24, 2012 at 9:32 PM, Cédric Krier <cedric.kr...@b2ck.com>

> > wrote:
>
> > > I think an important thing to take care is that a bank account could
> > > > have multiple representation like national number and IBAN.
>
> > > > The IBAN only works mainly for european countries and can be calculated
> > > from the national number, I'm not sure we need to store both
> > informations.
>
> > The adoption is larger than Europe
> >https://en.wikipedia.org/wiki/IBAN#Adoption
>
> I said "mainly Europe", and you're there is a few more country using it :)
>
>
>
> But I think each form should be stored in the database to be able to
>
> > search for it. And more over, we don't know if there will always be a
> > transformation.
>
> We should store the iban number whatever the account is? Even for a us
> account, whish is not compatible with the IBAN ?
>
>

I think we should store only one number AND a type.
Depending on the type, we can call different methods to interpret the
account number differently : validate it, extract the bank code, the
branche code, the account code,...

[Cédric Krier]

On 25/06/12 10:10 -0700, sampac wrote:
> I think we should store only one number AND a type.
> Depending on the type, we can call different methods to interpret the
> account number differently : validate it, extract the bank code, the
> branche code, the account code,...

I'm pretty sure that we must store all the different formats of an
account.

[Farès Hantous]

To identify a bank account, you must store the IBAN and the account number.

The RIB is the IBAN minus the 4 first characters for all the countries. But the rule to find the IBAN from the RIB needs some calculations.

Each country has its own rule to find the account number from the RIB. So it is better to store it.

Also, you can store the BIC code (which identifies the bank), the bank name and the bank agency name.

[Rom1]

On Tue, Jun 26, 2012 at 10:10 AM, Cédric Krier <cedric...@b2ck.com> wrote:

On 25/06/12 10:10 -0700, sampac wrote:
> I think we should store only one number AND a type.
> Depending on the type, we can call different methods to interpret the
> account number differently : validate it, extract the bank code, the
> branche code, the account code,...

I'm pretty sure that we must store all the different formats of an
account.

I don't know what are the information needed for each country. 

Do you think, we also need to store the country information (needed for the iban) or we juste need the Iban (that contains the country) ?

If so, we could calculate the iban with an on_change on the other fields, otherwise if the account is a RIB I could calculate the IBAN but I don't know how I could go further.

[Rom1]

On Tue, Jun 26, 2012 at 9:48 AM, Cédric Krier <cedric...@b2ck.com> wrote:

On 25/06/12 18:19 +0200, Rom1 wrote:
> On Mon, Jun 25, 2012 at 5:46 PM, Cédric Krier <cedric...@b2ck.com> wrote:

> But I think each form should be stored in the database to be able to
> > search for it. And more over, we don't know if there will always be a
> > transformation.
> >
>
> We should store the iban number whatever the account is? Even for a us
> account, whish is not compatible with the IBAN ?

Of course it makes no sense to store something that doesn't exist.

What I meant, is that I think only one table will be enough to store any bank account, and you'll have an IBAN field in the table even for bank account that are not compatible with the iban. Of course, we could hide the field on the view.

[Cédric Krier]

On 26/06/12 12:16 +0200, Rom1 wrote:
> On Tue, Jun 26, 2012 at 10:10 AM, Cédric Krier <cedric...@b2ck.com>wrote:
>
> > On 25/06/12 10:10 -0700, sampac wrote:
> > > I think we should store only one number AND a type.
> > > Depending on the type, we can call different methods to interpret the
> > > account number differently : validate it, extract the bank code, the
> > > branche code, the account code,...
> >
> > I'm pretty sure that we must store all the different formats of an
> > account.
> >
>
> I don't know what are the information needed for each country.
> Do you think, we also need to store the country information (needed for the
> iban) or we juste need the Iban (that contains the country) ?
> If so, we could calculate the iban with an on_change on the other fields,
> otherwise if the account is a RIB I could calculate the IBAN but I don't
> know how I could go further.

I mean the "Bank Account" Model must contains a list of "Account Number"
with a type and the corresponding required fields.
Indeed I don't care about computing some of them or not, that's just a
minor feature. The important thing is the way data are stored.

[Fares Hantous]

Le 26/06/2012 11:32, Cédric Krier a écrit :
> I mean the "Bank Account" Model must contains a list of "Account Number"
> with a type and the corresponding required fields.

After reading [1] and [2], it seems that it is possible to do that:
field1 M2O : country
field2 : key
field3 : IID
field4 : account number

The IBAN is the concatenation : country.code + key + iid + account number
The RIB / BBAC is the concatenation : iid + account number

This seems to be generic for all countries.

[1] http://fr.wikipedia.org/wiki/ISO_13616
[2] http://fr.wikipedia.org/wiki/Basic_Bank_Account_Number

[Cédric Krier]

I really think that it will be a dead end if you try to be too smart and
too strict when storing such information.
So the account number should be stored in a simple Char field.

[Fares Hantous]

Le 26/06/2012 12:00, Cédric Krier a écrit :
> On 26/06/12 11:51 +0100, Fares Hantous wrote:
>> Le 26/06/2012 11:32, Cédric Krier a écrit :
>>> I mean the "Bank Account" Model must contains a list of "Account Number"
>>> with a type and the corresponding required fields.
>> After reading [1] and [2], it seems that it is possible to do that:
>> field1 M2O : country
>> field2 : key
>> field3 : IID
>> field4 : account number
>>
>> The IBAN is the concatenation : country.code + key + iid + account number
>> The RIB / BBAC is the concatenation : iid + account number
>>
>> This seems to be generic for all countries.
>>
>> [1] http://fr.wikipedia.org/wiki/ISO_13616
>> [2] http://fr.wikipedia.org/wiki/Basic_Bank_Account_Number
> I really think that it will be a dead end if you try to be too smart and
> too strict when storing such information.
> So the account number should be stored in a simple Char field.
>

Why?
This way, the user doesn't need to write twice (or 3 times) the account
number.
If you need the account number or the RIB or the IBAN, you get it.

[Cédric Krier]

Because you are just speaking about a specific cases and not about
general purpose.

[Fares Hantous]

Which case is not solved this way ?

[Cédric Krier]

Any case where RIB or IBAN is not involved.

[Rom1]

On Tue, Jun 26, 2012 at 12:32 PM, Cédric Krier <cedric...@b2ck.com> wrote:

On 26/06/12 12:16 +0200, Rom1 wrote:
> On Tue, Jun 26, 2012 at 10:10 AM, Cédric Krier <cedric...@b2ck.com>wrote:
>
> > On 25/06/12 10:10 -0700, sampac wrote:
> > > I think we should store only one number AND a type.
> > > Depending on the type, we can call different methods to interpret the
> > > account number differently : validate it, extract the bank code, the
> > > branche code, the account code,...
> >
> > I'm pretty sure that we must store all the different formats of an
> > account.
> >
>
> I don't know what are the information needed for each country.
> Do you think, we also need to store the country information (needed for the
> iban) or we juste need the Iban (that contains the country) ?
> If so, we could calculate the iban with an on_change on the other fields,
> otherwise if the account is a RIB I could calculate the IBAN but I don't
> know how I could go further.

I mean the "Bank Account" Model must contains a list of "Account Number"
with a type and the corresponding required fields.

what do you mean a "list", a O2M of item with a char and a type, or just 4-5 char on the bank account table?

How do you deal with required fields as it is different for each country?

You still havn't answered my question, do you think we need to store the country? (This way for a french account we won't need to say it's a RIB).

 

Indeed I don't care about computing some of them or not, that's just a
minor feature. The important thing is the way data are stored.

 

For you, maybe, but for the user this is a key feature. :)

[Cédric Krier]

On 26/06/12 14:25 +0200, Rom1 wrote:
> On Tue, Jun 26, 2012 at 12:32 PM, Cédric Krier <cedric...@b2ck.com>wrote:
> > I mean the "Bank Account" Model must contains a list of "Account Number"
> > with a type and the corresponding required fields.
> >
>
> what do you mean a "list", a O2M of item with a char and a type, or just
> 4-5 char on the bank account table?

A One2Many

> How do you deal with required fields as it is different for each country?

For now, from all the different kind of bank account number I know, a
simple char field is enough.

> You still havn't answered my question, do you think we need to store the
> country? (This way for a french account we won't need to say it's a RIB).

I think a "Bank account" should have an address but it should be
investigated to know what is the common form for it.

> > Indeed I don't care about computing some of them or not, that's just a
> > minor feature. The important thing is the way data are stored.
> >
> >
> For you, maybe, but for the user this is a key feature. :)

Early overfeatured requirements is the best way to fail.

[Rom1]

On Tue, Jun 26, 2012 at 2:41 PM, Cédric Krier <cedric...@b2ck.com> wrote:

On 26/06/12 14:25 +0200, Rom1 wrote:
> On Tue, Jun 26, 2012 at 12:32 PM, Cédric Krier <cedric...@b2ck.com>wrote:

> > I mean the "Bank Account" Model must contains a list of "Account Number"
> > with a type and the corresponding required fields.
> >

I'm not sure, I understood correctly. What do you have in the O2M ?

account 

   ->RIB

   ->IBAN

   ->any account number

or

account

   ->bank code

   ->branch code

   -> account number

   -> key 

>
> what do you mean a "list", a O2M of item with a char and a type, or just
> 4-5 char on the bank account table?

A One2Many

> How do you deal with required fields as it is different for each country?

For now, from all the different kind of bank account number I know, a
simple char field is enough.

> You still havn't answered my question, do you think we need to store the
> country? (This way for a french account we won't need to say it's a RIB).

I think a "Bank account" should have an address but it should be
investigated to know what is the common form for it.

I don't know for other countries, but in France, you have a repos for each bank code/branch code with the address, you don't specify the address each time you enter a new RIB, as it is the same for all the customer of the branch. I suppose it's the same wherever you have a branch code. But you'll need the country first the restrict the search, because branch code are only unique per country.

> > Indeed I don't care about computing some of them or not, that's just a
> > minor feature. The important thing is the way data are stored.
> >
> >
> For you, maybe, but for the user this is a key feature. :)

Early overfeatured requirements is the best way to fail.

thank you.

[Cédric Krier]

On 26/06/12 15:03 +0200, Rom1 wrote:
> On Tue, Jun 26, 2012 at 2:41 PM, Cédric Krier <cedric...@b2ck.com> wrote:
>
> > On 26/06/12 14:25 +0200, Rom1 wrote:
> > > On Tue, Jun 26, 2012 at 12:32 PM, Cédric Krier <cedric...@b2ck.com
> > >wrote:
> > > > I mean the "Bank Account" Model must contains a list of "Account
> > Number"
> > > > with a type and the corresponding required fields.
> > > >
> >
> I'm not sure, I understood correctly. What do you have in the O2M ?
> account
> ->RIB
> ->IBAN
> ->any account number

This one.

> > I think a "Bank account" should have an address but it should be
> > investigated to know what is the common form for it.
> >
> > I don't know for other countries, but in France, you have a repos for each
> bank code/branch code with the address, you don't specify the address each
> time you enter a new RIB, as it is the same for all the customer of the
> branch. I suppose it's the same wherever you have a branch code. But you'll
> need the country first the restrict the search, because branch code are
> only unique per country.

Indeed, I think the best is to just link the bank account to the bank (a
party) and to an address of the party.

[sampac]

On 26 juin, 15:50, Cédric Krier <cedric.kr...@b2ck.com> wrote:
> On 26/06/12 15:03 +0200, Rom1 wrote:
>

> > On Tue, Jun 26, 2012 at 2:41 PM, Cédric Krier <cedric.kr...@b2ck.com> wrote:
>
> > > On 26/06/12 14:25 +0200, Rom1 wrote:

> > > > On Tue, Jun 26, 2012 at 12:32 PM, Cédric Krier <cedric.kr...@b2ck.com

> > > >wrote:
> > > > > I mean the "Bank Account" Model must contains a list of "Account
> > > Number"
> > > > > with a type and the corresponding required fields.
>
> > I'm not sure, I understood correctly. What do you have in the O2M ?
> > account
> >    ->RIB
> >    ->IBAN
> >    ->any account number
>
> This one.
>
> > > I think a "Bank account" should have an address but it should be
> > > investigated to know what is the common form for it.
>
> > > I don't know for other countries, but in France, you have a repos for each
> > bank code/branch code with the address, you don't specify the address each
> > time you enter a new RIB, as it is the same for all the customer of the
> > branch. I suppose it's the same wherever you have a branch code. But you'll
> > need the country first the restrict the search, because branch code are
> > only unique per country.
>
> Indeed, I think the best is to just link the bank account to the bank (a
> party) and to an address of the party.
>

I did something here: https://github.com/sampaccoud/tryton-bank

So if we want to allow storing different numbers for a same bank
account I can refactor to make a separate object for the bank number.
Then we can add several account numbers to a bank account.

But I don't think it is necessary because a given bank account only
works with a given number. RIB and IBAN are just the same thing with a
different checksum...

The way I did the account number is very generic and we can write as
many methods to validate and split the account number depending on the
country case...

Looking forward to your comments / pull requests.

[Rom1]

On Tue, Jun 26, 2012 at 5:14 PM, sampac <*@sampaccoud.com> wrote:
>
>
>
> I did something here: https://github.com/sampaccoud/tryton-bank
>
> So if we want to allow storing different numbers for a same bank
> account I can refactor to make a separate object for the bank number.
> Then we can add several account numbers to a bank account.
>
> But I don't think it is necessary because a given bank account only
> works with a given number. RIB and IBAN are just the same thing with a
> different checksum...
>
> The way I did the account number is very generic and we can write as
> many methods to validate and split the account number depending on the
> country case...
>
> Looking forward to your comments / pull requests.
>

Very nice job, much better than what I did.
Just a few comments :
BankAccount
Who is "party" ? The owner or the bank agency (because I don't
understand the domain on the address). For me, you have the party
(the owner), the bank agency (party.bank), the address (with domain on
the bank agency).

The RIB key could be calculated with stdnum.iso7064.mod_97_10


Bank
Why is it an inherit of address and not of party?
The bank code shouldn't it be stored in parent of the bank?
I think there is not one BIC per agency, but you have one BIC for
several agency within the same region.

I

[Fares Hantous]

OK, if i understood you well,
The advantage of having a simple char field is to be able to add a new
kind of accounts (IBAN, RIB, ...).
in my opinion, this can happen but not within the next years, because
setting a new way of writing accounts
needs many years of discussions.

In my opinion, making things easier for the user (one account => one
entry) is the thing that should be focused.

[Cédric Krier]

On 26/06/12 17:26 +0100, Fares Hantous wrote:
> The advantage of having a simple char field is to be able to add a
> new kind of accounts (IBAN, RIB, ...).

Yes.

> in my opinion, this can happen but not within the next years,
> because setting a new way of writing accounts
> needs many years of discussions.

You are just looking at 2 format (RIB and IBAN), just by reading the
wikipedia page of IBAN, I can see there are 2 others formats.

> In my opinion, making things easier for the user (one account => one
> entry) is the thing that should be focused.

That's bad because we already know that there are at least 2 format for
1 account (which is common 1 for country locale usage and 1 for
international usage).

[sampac]

On 26 juin, 18:17, Rom1 <rom1.try...@gmail.com> wrote:

> On Tue, Jun 26, 2012 at 5:14 PM, sampac <*...@sampaccoud.com> wrote:
>
> > I did something here:https://github.com/sampaccoud/tryton-bank
>
> > So if we want to allow storing different numbers for a same bank
> > account I can refactor to make a separate object for the bank number.
> > Then we can add several account numbers to a bank account.
>
> > But I don't think it is necessary because a given bank account only
> > works with a given number. RIB and IBAN are just the same thing with a
> > different checksum...
>
> > The way I did the account number is very generic and we can write as
> > many methods to validate and split the account number depending on the
> > country case...
>
> > Looking forward to your comments / pull requests.
>
> Very nice job, much better than what I did.

Thanks, I built on yours ;-)

> Just a few comments :
> BankAccount
> Who is "party" ? The owner or the bank agency (because I don't
> understand the domain on the address).  For me, you have the party
> (the owner), the bank agency (party.bank), the address (with domain on
> the bank agency).
>

Ok let me refactor and propose something like this.

> The RIB key could be calculated with stdnum.iso7064.mod_97_10

A bit overkill ? It's just 15 lines of code so maybe we keep it like
this ?

> Bank
> Why is it an inherit of address and not of party?
> The bank code shouldn't it be stored in parent of the bank?
> I think there is not one BIC per agency, but you have one BIC for
> several agency within the same region.

bank code: I will propose a parent on bank which will be a inherit of
party (same scheme as "company.company" in fact). Bank code will be
available with required = false.
BIC : the field is not marked as unique so should be ok.

[sampac]

Here is a new version : https://github.com/sampaccoud/trytond_bank

I think there still misses a field "bank_address" on the bank_account
object to identify which one of the bank's addresses is registered for
this bank account:
so we will have on the bank_account object:

bank = fields.Many2One("bank.bank", "Bank")
bank_address = fields.Many2One("party.address", "Bank
address")

But I couldn't figure out what domain to set on the bank_address to
filter only addresses from the related bank object. I thought it
should look something like:

domain = [('party', '=', Eval('_parent_bank').get('party'))]

But it didn't work... probably because of the inherit on bank.bank :-
( or am I missing something ?

[Rom1]

On Wed, Jun 27, 2012 at 10:53 AM, sampac <*@sampaccoud.com> wrote:
>
>> The RIB key could be calculated with stdnum.iso7064.mod_97_10
>
> A bit overkill ? It's just 15 lines of code so maybe we keep it like
> this ?
>

Not overkill, if you could use an existing API instead of
reimplementing one (I would be very surprised if we can't find one
public lib for this calculation) but the one I gave you is really not
sufficient enough, your algorithm is much better. I'm no regex expert,
but don't you think we could replace the alpha by numbers with one
regex?

>> Bank
>> Why is it an inherit of address and not of party?
>> The bank code shouldn't it be stored in parent of the bank?
>> I think there is not one BIC per agency, but you have one BIC for
>> several agency within the same region.
>
> bank code: I will propose a parent on bank which will be a inherit of
> party (same scheme as "company.company" in fact). Bank code will be
> available with required = false.

So you could deal with a hierarchy?

> BIC : the field is not marked as unique so should be ok.
>

Yes you are right, I was more on the idea to store the BIC code on a
parent bank of several banks, but I'm not sure this idea make a lot of
sense.

[Albert Cervera i Areny]

A Dissabte, 23 de juny de 2012 12:15:29, sampac va escriure:

> Does anyone know of a Tryton module to add bank information to a party

> (something like bank.partner.bank in OpenERP) ?

> If not I will code it so please give me any requirements you would

> have for such module

 

Please, take a look at this:

 

https://bitbucket.org/ukoma/party_bank/

--

Albert Cervera i Areny

http://www.NaN-tic.com

Tel: +34 93 553 18 03

 

http://twitter.com/albertnan

http://www.nan-tic.com/blog

 

[Rom1]

On Wed, Jun 27, 2012 at 3:51 PM, sampac <*@sampaccoud.com> wrote:

> I think there still misses a field "bank_address" on the bank_account
> object to identify which one of the bank's addresses is registered for
> this bank account:
> so we will have on the bank_account object:
>
>        bank = fields.Many2One("bank.bank", "Bank")
>        bank_address = fields.Many2One("party.address", "Bank
> address")
>

I'm still asking myself, why do we need the address on the bank
account. Nowadays (in France, I don't know else where) when you change
from one agency to another one within the same bank, the account
number doesn't change. So why store an information that could become
wrong. One explanation would be that the address is needed to send the
direct debit authorization, but I have the feeling that you don't send
this authorization to the agency, but to the back office of the bank,
look at the file I've found on the Internet :

http://entreprises.lcl.fr/Ressources/Pdf/adp_gu.pdf

You have only one address for the bank (which is not the main
address), and you have no agency.

This mean, that we need to store this address on the bank with a
particular type.
In conclusion, why do we need to store the address, just to make a
visual check between the account entered and the address in the
database? Just for one country, you may have thousands of agency, is
it really worth it? And where do we find such a file to build the
repo?
Well, I thought it was worth sharing.

[Raimon Esteve]

@b2ck team: Do you have any news/are working about bank module? Or
what bank module will be "oficial release"?

In Spanish localization we need bank management data (and extra
modules to generate files import/export bank)

Thanks.

raimon

[Cédric Krier]

On 02/10/12 12:47 +0200, Raimon Esteve wrote:
> @b2ck team: Do you have any news/are working about bank module? Or
> what bank module will be "oficial release"?

Nothing was submitted.

[Raimon Esteve]

> I did something here:https://github.com/sampaccoud/tryton-bank

This module don't found. 404

Finally I think is good design party_bank module from Mathias. Good work!

We are working party_bank_es. This module add default values from
Spanish banks. Also we need number validation. This afternoon we talk
about this point.

bye

--
Si us plau, NO adjunti arxius a les seves respostes. Li preguem que
integri el text al cos del missatge. Pot respondre usant NetEtiquete
que li ajudarà a seguir la conversa.
http://es.wikipedia.org/wiki/Netiquette

Por favor, NO adjunte archivos a sus respuestas. Le rogamos que
integre el texto en el cuerpo del mensaje. Puede responder usando
NetEtiquete que le ayudará a seguir la
conversación.http://es.wikipedia.org/wiki/Netiquette

Please, DO NOT send attachment files with your answers, just copy and
paste only the text you need to send into the body of your mails.
Repply using NetEtiquete. http://en.wikipedia.org/wiki/Netiquette

[Raimon Esteve]

2012/10/5 Raimon Esteve <raimon...@gmail.com>:

> Finally I think is good design party_bank module from Mathias. Good work!

About validation Bank Account Number, we think is similar about VAT number.

Create a python library (bank_account_number?) and add validators
methods by countries.

In tryton, when you add new account number in party, you can select a
prefix country and this account number is validate by this country
(only list countries avalable in methods)

Do you know if exists python library account number validation or we start it?

Good weekend,

Raimon

[Cédric Krier]

On 05/10/12 19:09 +0200, Raimon Esteve wrote:
> 2012/10/5 Raimon Esteve <raimon...@gmail.com>:
> > Finally I think is good design party_bank module from Mathias. Good work!
>
> About validation Bank Account Number, we think is similar about VAT number.
>
> Create a python library (bank_account_number?) and add validators
> methods by countries.
>
> In tryton, when you add new account number in party, you can select a
> prefix country and this account number is validate by this country
> (only list countries avalable in methods)

I don't understand why you want to link to the country.
There are just kind of account number like IBAN.

[Raimon Esteve]

2012/10/5 Cédric Krier <cedric...@b2ck.com>:

>> In tryton, when you add new account number in party, you can select a
>> prefix country and this account number is validate by this country
>> (only list countries avalable in methods)
>
> I don't understand why you want to link to the country.

validate bank number (code)

https://twitter.com/raimonesteve/status/263593447573843968/photo/1

Same as vat number

Now banknumber python library only have spanish validation.

It's available add some others countries... if there is a validation.

Raimon