> No billing account, no AR. Stated differently, the sum of billing account
>
> Skip
>
> -----Original Message-----
> From: Jacopo Cappellato [mailto:
[hidden email]]
> Sent: Monday, October 29, 2007 11:50 AM
> To:
[hidden email]
> Subject: Re: Accounts Receivable
>
>
> 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
>