EftAccount versus new entity

[Anne Jessel]

I'm trying to work out the best way to get OFBiz to support Australian direct-entry payments. This is where a customer makes a payment by directly transferring the money to the company's bank account, usually via online banking. This is currently a very common payment method.

The same system is also used to allow a company to debit regular payments directly from the customer's bank account, or for the company to pay its bills.

For storing the relevant bank details, the EftAccount entity seems to be closest. However it is not a good match. I am unsure whether my best approach would be to use the existing EftAccount entity in some way, or to create a new entity.

The fields that are relevant to Australian transactions are:

BSB: a number denoting which branch of which bank
Account number: the account number
Account name: the name (person or organisation) associated with the bank account
SWIFT code: a code denoting which bank - this is only relevant when one of the banks involved in the transaction is outside Australia, e.g. the customer is paying from an overseas bank account.
Bank name: not usually needed, but handy to record

Some of these fields map to the existing EftAccount entity, some don't:

Account name -> nameOnAccount
Account number -> accountNumber
BSB -> ? (perhaps routingNumber? I don't know what routingNumber is really for)
SWIFT code -> ?
Bank name -> bankName

What approach is likely to be the best option?

Also, I'll need to add support for a new payment gateway to support an Australian provider. It would be nice if all I had to do was create the payment gateway interface code, following the examples for the other third party gateways, and then somehow it all just magically fitted together and worked with the existing code. Is this asking too much? :-)

Cheers,
Anne.


--
Coherent Software Australia Pty Ltd
PO Box 2773
Cheltenham Vic 3192
Phone: [phone]
Fax: [phone]
Web: http://www.cohsoft.com.au/
Email: [hidden email]

[hans_bakker]

Hi Anne,

in general is is always better to extend and existing entity than to
create a new one where ever possible.

In your case all the fields fit except, as you state, the BSB and swift
code. I would suggest to put them both into the routing number field
separated by either a '/' or a blank. The routing code is the code which
identifies the bank in the international payment transfers.

Regards,
Hans

On Mon, 2009-08-03 at 19:27 +1000, [hidden email] wrote:

> I'm trying to work out the best way to get OFBiz to support Australian
> direct-entry payments. This is where a customer makes a payment by
> directly transferring the money to the company's bank account, usually
> via online banking. This is currently a very common payment method.
>
> The same system is also used to allow a company to debit regular
> payments directly from the customer's bank account, or for the company
> to pay its bills.
>
> For storing the relevant bank details, the EftAccount entity seems to
> be closest. However it is not a good match. I am unsure whether my
> best approach would be to use the existing EftAccount entity in some
> way, or to create a new entity.
>
> The fields that are relevant to Australian transactions are:
>
> BSB: a number denoting which branch of which bank
> Account number: the account number
> Account name: the name (person or organisation) associated with the
> bank account
> SWIFT code: a code denoting which bank - this is only relevant when
> one of the banks involved in the transaction is outside Australia,
> e.g. the customer is paying from an overseas bank account.
> Bank name: not usually needed, but handy to record
>
> Some of these fields map to the existing EftAccount entity, some
> don't:
>
> Account name -> nameOnAccount
> Account number -> accountNumber
> BSB -> ? (perhaps routingNumber? I don't know what routingNumber is
> really for)
> SWIFT code -> ?
> Bank name -> bankName
>
> What approach is likely to be the best option?
>
> Also, I'll need to add support for a new payment gateway to support an
> Australian provider. It would be nice if all I had to do was create
> the payment gateway interface code, following the examples for the
> other third party gateways, and then somehow it all just magically
> fitted together and worked with the existing code. Is this asking too
> much? :-)
>
> Cheers,
> Anne.
>
>
> --
> Coherent Software Australia Pty Ltd
> PO Box 2773
> Cheltenham Vic 3192
> Phone: [phone]
> Fax: [phone]
> Web: http://www.cohsoft.com.au/
> Email: [hidden email]
>

--
Antwebsystems.com: Quality OFBiz services for competitive rates

[Scott Gray-2]

My vote (if we were voting) would be for separate fields because each  
identifier (routing number, SWIFT code, BSB) ultimately serves a  
different purpose.

If I'm not wrong (and I could be) I thought the routing number was  
used to store this: http://en.wikipedia.org/wiki/Routing_transit_number
Whereas a SWIFT code is this: http://en.wikipedia.org/wiki/ISO_9362

If you use the field for anything other than a routing number then you  
run the risk of conflicting with any new functionality implemented in  
OFBiz and you also wouldn't be able to contribute the code back (if  
desired) because the use of the field would be specific to your  
circumstance.

Regards
Scott

HotWax Media
http://www.hotwaxmedia.com

On 3/08/2009, at 10:22 PM, Hans Bakker wrote:

> Hi Anne,
>
> in general is is always better to extend and existing entity than to
> create a new one where ever possible.
>
> In your case all the fields fit except, as you state, the BSB and  
> swift
> code. I would suggest to put them both into the routing number field
> separated by either a '/' or a blank. The routing code is the code  
> which
> identifies the bank in the international payment transfers.
>
> Regards,
> Hans
>
> On Mon, 2009-08-03 at 19:27 +1000, [hidden email] wrote:
>> I'm trying to work out the best way to get OFBiz to support  
>> Australian
>> direct-entry payments. This is where a customer makes a payment by
>> directly transferring the money to the company's bank account,  
>> usually
>> via online banking. This is currently a very common payment method.
>>
>> The same system is also used to allow a company to debit regular
>> payments directly from the customer's bank account, or for the  
>> company
>> to pay its bills.
>>
>> For storing the relevant bank details, the EftAccount entity seems to
>> be closest. However it is not a good match. I am unsure whether my
>> best approach would be to use the existing EftAccount entity in some
>> way, or to create a new entity.
>>
>> The fields that are relevant to Australian transactions are:
>>
>> BSB: a number denoting which branch of which bank
>> Account number: the account number
>> Account name: the name (person or organisation) associated with the
>> bank account
>> SWIFT code: a code denoting which bank - this is only relevant when
>> one of the banks involved in the transaction is outside Australia,
>> e.g. the customer is paying from an overseas bank account.
>> Bank name: not usually needed, but handy to record
>>
>> Some of these fields map to the existing EftAccount entity, some
>> don't:
>>
>> Account name -> nameOnAccount
>> Account number -> accountNumber
>> BSB -> ? (perhaps routingNumber? I don't know what routingNumber is
>> really for)
>> SWIFT code -> ?
>> Bank name -> bankName
>>
>> What approach is likely to be the best option?
>>
>> Also, I'll need to add support for a new payment gateway to support  
>> an
>> Australian provider. It would be nice if all I had to do was create
>> the payment gateway interface code, following the examples for the
>> other third party gateways, and then somehow it all just magically
>> fitted together and worked with the existing code. Is this asking too
>> much? :-)
>>
>> Cheers,
>> Anne.
>>
>>
>> --
>> Coherent Software Australia Pty Ltd
>> PO Box 2773
>> Cheltenham Vic 3192
>> Phone: [phone]
>> Fax: [phone]
>> Web: http://www.cohsoft.com.au/
>> Email: [hidden email]
>>
> --
> Antwebsystems.com: Quality OFBiz services for competitive rates
>

[Anne Jessel]

Thank you Scott, Hans.

I do intend to contribute the code, provided I can work out how to write it
in a general enough way that it is useful.

After reading about the routing number via Scott's reference, I think it is
close enough in concept to a BSB number (
http://en.wikipedia.org/wiki/Bank_State_Branch) that it would make sense to
use that field. I could probably ignore the SWIFT code for now - the
existing functionality does not seem to support transactions between two
countries (unless I looked in the wrong places), so leaving it out wouldn't
reduce existing functionality.

I still need to work out how to hook it into the existing invoice payments
system, so I think it'll be a while before I have anything functional.

Cheers,
Anne.


2009/8/3 Scott Gray <[hidden email]>

> My vote (if we were voting) would be for separate fields because each
> identifier (routing number, SWIFT code, BSB) ultimately serves a different
> purpose.
>
> If I'm not wrong (and I could be) I thought the routing number was used to
> store this: http://en.wikipedia.org/wiki/Routing_transit_number
> Whereas a SWIFT code is this: http://en.wikipedia.org/wiki/ISO_9362
>
> If you use the field for anything other than a routing number then you run
> the risk of conflicting with any new functionality implemented in OFBiz and
> you also wouldn't be able to contribute the code back (if desired) because
> the use of the field would be specific to your circumstance.
>
> Regards
> Scott
>
> HotWax Media
> http://www.hotwaxmedia.com
>
>
> On 3/08/2009, at 10:22 PM, Hans Bakker wrote:
>
>  Hi Anne,
>>
>> in general is is always better to extend and existing entity than to
>> create a new one where ever possible.
>>
>> In your case all the fields fit except, as you state, the BSB and swift
>> code. I would suggest to put them both into the routing number field
>> separated by either a '/' or a blank. The routing code is the code which
>> identifies the bank in the international payment transfers.
>>
>> Regards,
>> Hans
>>
>> On Mon, 2009-08-03 at 19:27 +1000, [hidden email] wrote:
>>
>>> I'm trying to work out the best way to get OFBiz to support Australian
>>> direct-entry payments. This is where a customer makes a payment by
>>> directly transferring the money to the company's bank account, usually
>>> via online banking. This is currently a very common payment method.
>>>
>>> The same system is also used to allow a company to debit regular
>>> payments directly from the customer's bank account, or for the company
>>> to pay its bills.
>>>
>>> For storing the relevant bank details, the EftAccount entity seems to
>>> be closest. However it is not a good match. I am unsure whether my
>>> best approach would be to use the existing EftAccount entity in some
>>> way, or to create a new entity.
>>>
>>> The fields that are relevant to Australian transactions are:
>>>
>>> BSB: a number denoting which branch of which bank
>>> Account number: the account number
>>> Account name: the name (person or organisation) associated with the
>>> bank account
>>> SWIFT code: a code denoting which bank - this is only relevant when
>>> one of the banks involved in the transaction is outside Australia,
>>> e.g. the customer is paying from an overseas bank account.
>>> Bank name: not usually needed, but handy to record
>>>
>>> Some of these fields map to the existing EftAccount entity, some
>>> don't:
>>>
>>> Account name -> nameOnAccount
>>> Account number -> accountNumber
>>> BSB -> ? (perhaps routingNumber? I don't know what routingNumber is
>>> really for)
>>> SWIFT code -> ?
>>> Bank name -> bankName
>>>
>>> What approach is likely to be the best option?
>>>
>>> Also, I'll need to add support for a new payment gateway to support an
>>> Australian provider. It would be nice if all I had to do was create
>>> the payment gateway interface code, following the examples for the
>>> other third party gateways, and then somehow it all just magically
>>> fitted together and worked with the existing code. Is this asking too
>>> much? :-)
>>>
>>> Cheers,
>>> Anne.
>>>
>>>
>>> --
>>> Coherent Software Australia Pty Ltd
>>> PO Box 2773
>>> Cheltenham Vic 3192
>>> Phone: [phone]
>>> Fax: [phone]
>>> Web: http://www.cohsoft.com.au/
>>> Email: [hidden email]
>>>
>>>  --
>> Antwebsystems.com: Quality OFBiz services for competitive rates
>>
>>
>

--
Coherent Software Australia Pty Ltd
PO Box 2773
Cheltenham Vic 3192
Phone: [phone]
Fax: [phone]
Web: http://www.cohsoft.com.au/
Email: [hidden email]

Bonsai ERP, the all-inclusive ERP system
http://www.bonsaierp.com.au/