Posted by
SkipDever on
Oct 29, 2007; 7:46pm
URL: http://ofbiz.116.s1.nabble.com/Accounts-Receivable-tp184969.html
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?
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
> >>
> >>
>