Re: EftAccount versus new entity
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 > 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, a...@cohsoft.com.au 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: (03) 9585 6788 >>> Fax: (03) 9585 1086 >>> Web: http://www.cohsoft.com.au/ >>> Email: sa...@cohsoft.com.au >>> >>> -- >> Antwebsystems.com: Quality OFBiz services for competitive rates >> >> > -- Coherent Software Australia Pty Ltd PO Box 2773 Cheltenham Vic 3192 Phone: (03) 9585 6788 Fax: (03) 9585 1086 Web: http://www.cohsoft.com.au/ Email: sa...@cohsoft.com.au Bonsai ERP, the all-inclusive ERP system http://www.bonsaierp.com.au/
Re: EftAccount versus new entity
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, a...@cohsoft.com.au 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: (03) 9585 6788 Fax: (03) 9585 1086 Web: http://www.cohsoft.com.au/ Email: sa...@cohsoft.com.au -- Antwebsystems.com: Quality OFBiz services for competitive rates smime.p7s Description: S/MIME cryptographic signature
Re: EftAccount versus new entity
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, a...@cohsoft.com.au 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: (03) 9585 6788 > Fax: (03) 9585 1086 > Web: http://www.cohsoft.com.au/ > Email: sa...@cohsoft.com.au > -- Antwebsystems.com: Quality OFBiz services for competitive rates
EftAccount versus new entity
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: (03) 9585 6788 Fax: (03) 9585 1086 Web: http://www.cohsoft.com.au/ Email: sa...@cohsoft.com.au signature.asc Description: OpenPGP digital signature
