Payment method - direct debit

[Ray-91]

We are looking to add direct debit support and want to add a couple of
new payment method types and a new entity.

    <PaymentMethodType paymentMethodTypeId="DIRECT_DEBIT"
description="Direct Debit"/>
    <PaymentMethodType paymentMethodTypeId="P_DIRECT_DEBIT"
description="Paperless Direct Debit"/>

<entity entity-name="BankAccount"
package-name="org.ofbiz.accounting.payment"
        title="Bank Account Information Entity">
    <field name="paymentMethodId" type="id-ne"></field>
    <field name="accountNumber" type="long-varchar" encrypt="true"></field>
    <field name="sortCode" type="short-varchar"></field>
    <field name="nameOnAccount" type="name"></field>
    <field name="bankName" type="name"></field>
    <field name="contactMechId" type="id-ne"></field>

    <prim-key field="paymentMethodId"/>

    <relation type="one" fk-name="BNKACCT_PMETH"
rel-entity-name="PaymentMethod">
        <key-map field-name="paymentMethodId"/>
    </relation>
    <relation type="one" fk-name="BNKACCT_CMECH"
rel-entity-name="ContactMech">
        <key-map field-name="contactMechId"/>
    </relation>
    <relation type="one" fk-name="BNKACCT_PADDR"
rel-entity-name="PostalAddress">
        <key-map field-name="contactMechId"/>
    </relation>
</entity>

Any comments/questions about adding this to the accounting module?
Obviously there are CRUD services to add which we have started on but
I'll put it all up through JIRA if there is no objection to adding this
sort of functionality in principle.

Ray

[David E Jones]

This sounds like a good thing to add. Is there any reason to not  
expand the existing EftAccount entity to meet this need (ie add the  
new PaymentMethodType records, but when looked up have them use an  
expanded EftAccount instead of a new BankAccount entity).

-David


On Oct 8, 2008, at 3:40 AM, Ray wrote:

> We are looking to add direct debit support and want to add a couple of
> new payment method types and a new entity.
>
>    <PaymentMethodType paymentMethodTypeId="DIRECT_DEBIT"
> description="Direct Debit"/>
>    <PaymentMethodType paymentMethodTypeId="P_DIRECT_DEBIT"
> description="Paperless Direct Debit"/>
>
> <entity entity-name="BankAccount"
> package-name="org.ofbiz.accounting.payment"
>        title="Bank Account Information Entity">
>    <field name="paymentMethodId" type="id-ne"></field>
>    <field name="accountNumber" type="long-varchar" encrypt="true"></
> field>
>    <field name="sortCode" type="short-varchar"></field>
>    <field name="nameOnAccount" type="name"></field>
>    <field name="bankName" type="name"></field>
>    <field name="contactMechId" type="id-ne"></field>
>
>    <prim-key field="paymentMethodId"/>
>
>    <relation type="one" fk-name="BNKACCT_PMETH"
> rel-entity-name="PaymentMethod">
>        <key-map field-name="paymentMethodId"/>
>    </relation>
>    <relation type="one" fk-name="BNKACCT_CMECH"
> rel-entity-name="ContactMech">
>        <key-map field-name="contactMechId"/>
>    </relation>
>    <relation type="one" fk-name="BNKACCT_PADDR"
> rel-entity-name="PostalAddress">
>        <key-map field-name="contactMechId"/>
>    </relation>
> </entity>
>
> Any comments/questions about adding this to the accounting module?
> Obviously there are CRUD services to add which we have started on but
> I'll put it all up through JIRA if there is no objection to adding  
> this
> sort of functionality in principle.
>
> Ray
>

[Ray-91]

Glad you mentioned it as the thought did pass me by at some point but I
hadn't followed it up in detail yet. At the entity level I think there
is only an additional sort code field so pretty simple, but need to
check the service code to understand any usage differences i.e. sort
code is a required field for DD but routing number is not required
indeed there is no such thing for a UK bank account.

So do we create another service like "createBankAccount" that only
worries about it's required fields and let it reuse the EftAccount
entity, maybe with a new accountType (currently Checking and Savings) value?

We will also be adding additional modulus validation against account
numbers and there are lists for sort code validation and bank address
lookup.

Ray

David E Jones wrote:
>
> This sounds like a good thing to add. Is there any reason to not expand
> the existing EftAccount entity to meet this need (ie add the new
> PaymentMethodType records, but when looked up have them use an expanded
> EftAccount instead of a new BankAccount entity).
>
> -David
>
>