Re: Accounts Receivable

Posted by Jacopo Cappellato on Oct 29, 2007; 7:49pm
URL: http://ofbiz.116.s1.nabble.com/Accounts-Receivable-tp184969p184970.html

Hi Skip,

skip@theDevers wrote:

> Okeydokey Jacques, moved the discussion here (in spite of the fact that I'll
> get another gazillion emails to sort through :).
>
> One final issue to deal with for me, and that is credits.  Right now, if you
> overpay, you get an orphan PaymentApplication (no Invoice).  This is fine
> for computing the balance, but there is no detail record when printing a
> statement.
>
> This may be fine (just printing an overpayment line or whatever), but in the
> past, I have always created a miscellaneous credit that was applied (for
> aging purposes) when the next order was received (similiar to the way a
> store credit works now).
>
> Does anyone see any harm in creating a store credit (so we can utilize the
> existing logic) for overpayments?
>

what about using a billing account to catch the overpayment amount? you
can associate the amount to the billing account and then use it later.

Jacopo

> Skip
>
>> Hi Scott,
>>
>> Scott Gray wrote:
>>> Hi Jacopo
>>>
>>> Our customers generally make payments for a specific invoice or group
>>> of invoices so this wouldn't work for us.  In our current system (non
>>> web UI) we log a payment and then use a screen with a list of open
>>> invoices to allocate the payment with the payment balance reducing as
>>> each invoice is selected.
>>>
>> I think that you have perfectly described what is currently implemented
>> in OFbiz :-)
>> Maybe I'm not been very clear on this: I was not suggesting to modify
>> the existing payment/payment application screens; instead I was
>> suggesting to add a new option, for billing accounts, to apply billing
>> account payments to billing account invoices by date; of course you can
>> continue, also in the billing account, to apply payments to specific
>> invoices.
>>
>> Cheers,
>>
>> Jacopo
>>
>>
>>> Regards
>>> Scott
>>>
>>> On 29/10/2007, Jacopo Cappellato <[hidden email]> wrote:
>>>> skip@theDevers wrote:
>>>>> Jacopo
>>>>>
>>>>> As the man with the plan,
>>>> uhm... me?  :-)
>>>>
>>>>> I wanted to throw this new plan past you.  I have
>>>>> dug pretty deeply into the existing payment/billing account  stuff and
> it
>>>>> all seems a bit arcane to me and mostly because it looks like payments
> are
>>>>> meant to be made from the company to a vendor and from a customer to
> the
>>>>> company, all with the same screens.
>>>>>
>>>>> I want to create a really easy to use AR payment system.  The user
> enters a
>>>>> payment and can then either apply the payment to individual invoices
> (and a
>>>>> store credit if too much is received) or he can apply it to the
> billing
>>>>> account, in which case we automatically apply it to the oldest
> invoices
>>>>> first and then to a credit if too much is received.
>>>>>
>>>> I'd suggest the following subtasks:
>>>>
>>>> a) implement a new service to automatically apply the payments
>>>> associated to a billing account to the older open invoices associated
> to
>>>> the same account; the new service will have one mandatory parameter
>>>> "billingAccountId" (and maybe one optional parameter "paymentId") and
> it
>>>> will:
>>>> - select the open invoices associated to the billing account and sort
>>>> them by date (older first)
>>>> - iterate on the list and for each of them call the service
>>>> capturePaymentsByInvoice passing in the invoice id and billingAccountId
>>>> (this is the service that is invoked when you click on the "capture"
>>>> link near the invoice in the billingaccoun-invoices screen)
>>>>
>>>> b) the new service can be invoked by a new link ("apply payments to
>>>> invoices") at the top of the billing account->invoices screen or (maybe
>>>> in your custom application) triggered every time you associate a
> payment
>>>> to a billing account.
>>>>
>>>> This should cover your requirements but it is also generic enough to be
>>>> a good fit for OFBiz.
>>>>
>>>> What do you think?
>>>>
>>>> Jacopo
>>>>
>>>>> Is this too simplistic for some reason I am missing?  Do others have
> AR
>>>>> needs outside this that would justify a more complicated transaction
> set?
>>>>> Skip
>>>>
>