Financial Accounts - Deposits & Withdrawals

[Bob Morley]

I am really hoping someone can shed some light on the best way to handle the following scenario:

Dude comes into the store and slaps $1000 on the desk as a deposit for some Christmas shopping he will be doing in the future.  At some point later, same Dude comes in and buys some fancy stuff and uses that $1000 deposit to pay for it.

What we do now is create a financial account of type DEPOSIT_ACCOUNT when he comes into the store.  We then make a payment to the financial account of type "CUSTOMER_DEPOSIT" for the $1000.  Ultimately, when the customer comes in to make the sale we use this financial account as form of payment.  Theoretically the dude can come back in and withdrawal the funds from this deposit account.

However, the payment never seems to be getting completed.  If I attempt to go through the payment workflow I am forced to apply it to either a billing account, payment, invoice, or tax authority.  Moreover, the workflow for the financial account transaction was equally frustrating -- I could not actually get the $1000 to apply to the guys account unless I ran some form of financial account reconciliation.  I have tried to read all of the available documentation in the financial and billing account area; but I feel I must be missing something.  The only way I could get the reconciliation to work was to zap my database assigning the gl reconciliation id on the fin_account_trans (I think putting that transaction into the reconciliation pool).

Can anyone comment on this use case -- am I using the proper entities and/or is there configuration or some other fanciness that could streamline this process.

[David E. Jones-2]

Bob,

You're not the only person I've heard from recently who is having problems with financial accounts, and billing accounts too. I haven't had a chance to look into this, but it does seem like some basic things (such as updating financial account totals, and applying payments to invoices in billing accounts) are not working, or have been changed so that what is normally expected isn't happening and some hidden/obscure thing needs to be done in order finish the process.

What I think needs to be done is to do a gap/overlap analysis between the UBPL stories and what exists in OFBiz, and this can be used to document what exists and how to do things.

For this case the first step would be to make sure that everything you want to do is represented in the UBPL stories, and if not then let me know and I'll work you to make some edits.

BTW, I started a gap/overlap effort for UBPL, but I simply haven't had enough time to make progress on it.

-David


On Dec 10, 2009, at 4:00 PM, Bob Morley wrote:

>
> I am really hoping someone can shed some light on the best way to handle the
> following scenario:
>
> Dude comes into the store and slaps $1000 on the desk as a deposit for some
> Christmas shopping he will be doing in the future.  At some point later,
> same Dude comes in and buys some fancy stuff and uses that $1000 deposit to
> pay for it.
>
> What we do now is create a financial account of type DEPOSIT_ACCOUNT when he
> comes into the store.  We then make a payment to the financial account of
> type "CUSTOMER_DEPOSIT" for the $1000.  Ultimately, when the customer comes
> in to make the sale we use this financial account as form of payment.
> Theoretically the dude can come back in and withdrawal the funds from this
> deposit account.
>
> However, the payment never seems to be getting completed.  If I attempt to
> go through the payment workflow I am forced to apply it to either a billing
> account, payment, invoice, or tax authority.  Moreover, the workflow for the
> financial account transaction was equally frustrating -- I could not
> actually get the $1000 to apply to the guys account unless I ran some form
> of financial account reconciliation.  I have tried to read all of the
> available documentation in the financial and billing account area; but I
> feel I must be missing something.  The only way I could get the
> reconciliation to work was to zap my database assigning the gl
> reconciliation id on the fin_account_trans (I think putting that transaction
> into the reconciliation pool).
>
> Can anyone comment on this use case -- am I using the proper entities and/or
> is there configuration or some other fanciness that could streamline this
> process.
> --
> View this message in context: http://n4.nabble.com/Financial-Accounts-Deposits-Withdrawals-tp960589p960589.html
> Sent from the OFBiz - User mailing list archive at Nabble.com.

[Bob Morley]

Hi David,

I have done a quick review of the UBPL documents and have not really seen anything that matches our use case.  We have quite a bit of functionality targeted for brick and mortar stores; and Ofbiz tends to view things with a more web-centric focus.  As a result, customers typically make sales through a web sales channel (either direct or through a portal) or with a CSR.  Having said this, with a model as robust as what we have it should not be a problem to model our scenario even if it means writing a few more services.

I can create an entry in the UBPL that more closely matches what we want to do here; but my fundamental question is that if a customer is managing their own financial account and is going to make deposits and withdrawals from it, how do you handle the application of the associated payment.  Specifically, should there be an ability to apply the payment directly to the financial account or should we be creating an invoice for the customer deposit.

The current application allows you to make a "customer deposit payment" for the financial account, but it leaves you with a payment that still has to be applied to something so it can be completed.  It appears the only viable option would be to create an invoice (seems odd for a non-sale) or to enhance the capability of the payment application to account for this financial account deposit.

David E Jones-4 wrote

Bob,

You're not the only person I've heard from recently who is having problems with financial accounts, and billing accounts too. I haven't had a chance to look into this, but it does seem like some basic things (such as updating financial account totals, and applying payments to invoices in billing accounts) are not working, or have been changed so that what is normally expected isn't happening and some hidden/obscure thing needs to be done in order finish the process.

What I think needs to be done is to do a gap/overlap analysis between the UBPL stories and what exists in OFBiz, and this can be used to document what exists and how to do things.

For this case the first step would be to make sure that everything you want to do is represented in the UBPL stories, and if not then let me know and I'll work you to make some edits.

BTW, I started a gap/overlap effort for UBPL, but I simply haven't had enough time to make progress on it.

-David

[David E. Jones-2]

The only time I can think of that you would need an invoice when putting money into a financial account is if there was an order with a product that represented putting money in, and the invoice would be for the source of the money (cash, CC, whatever) and not for the target of the money (the fin account). If the money comes in through some other means an invoice shouldn't be necessary, and if it comes in through an order the invoice part should be pretty automatic.

About the UBPL stories, there should be general things in there for some of these basic operations, and hopefully you wouldn't have to write too much. Anyway, my hope was that it would be an asset, and if not at least the approach of the overlap documentation based on the story would be helpful.

-David


On Dec 10, 2009, at 5:03 PM, Bob Morley wrote:

>
> Hi David,
>
> I have done a quick review of the UBPL documents and have not really seen
> anything that matches our use case.  We have quite a bit of functionality
> targeted for brick and mortar stores; and Ofbiz tends to view things with a
> more web-centric focus.  As a result, customers typically make sales through
> a web sales channel (either direct or through a portal) or with a CSR.
> Having said this, with a model as robust as what we have it should not be a
> problem to model our scenario even if it means writing a few more services.
>
> I can create an entry in the UBPL that more closely matches what we want to
> do here; but my fundamental question is that if a customer is managing their
> own financial account and is going to make deposits and withdrawals from it,
> how do you handle the application of the associated payment.  Specifically,
> should there be an ability to apply the payment directly to the financial
> account or should we be creating an invoice for the customer deposit.
>
> The current application allows you to make a "customer deposit payment" for
> the financial account, but it leaves you with a payment that still has to be
> applied to something so it can be completed.  It appears the only viable
> option would be to create an invoice (seems odd for a non-sale) or to
> enhance the capability of the payment application to account for this
> financial account deposit.
>
>
> David E Jones-4 wrote:
>>
>>
>> Bob,
>>
>> You're not the only person I've heard from recently who is having problems
>> with financial accounts, and billing accounts too. I haven't had a chance
>> to look into this, but it does seem like some basic things (such as
>> updating financial account totals, and applying payments to invoices in
>> billing accounts) are not working, or have been changed so that what is
>> normally expected isn't happening and some hidden/obscure thing needs to
>> be done in order finish the process.
>>
>> What I think needs to be done is to do a gap/overlap analysis between the
>> UBPL stories and what exists in OFBiz, and this can be used to document
>> what exists and how to do things.
>>
>> For this case the first step would be to make sure that everything you
>> want to do is represented in the UBPL stories, and if not then let me know
>> and I'll work you to make some edits.
>>
>> BTW, I started a gap/overlap effort for UBPL, but I simply haven't had
>> enough time to make progress on it.
>>
>> -David
>>
>>
>
> --
> View this message in context: http://n4.nabble.com/Financial-Accounts-Deposits-Withdrawals-tp960589p960656.html
> Sent from the OFBiz - User mailing list archive at Nabble.com.