> Thanks Jacopo, I'll implement it in this way and see how it goes.
>
> Skip
>
> -----Original Message-----
> From: Jacopo Cappellato [mailto:
[hidden email]]
> Sent: Monday, October 29, 2007 12:05 PM
> To:
[hidden email]
> Subject: Re: Accounts Receivable
>
>
> skip@theDevers wrote:
> > Jacopo
> >
> > The assumtion for me is that these are all dealing with billing accounts.
> > No billing account, no AR. Stated differently, the sum of billing account
> > invoices - (billing account payments + store credits) = Accounts
> Receivable.
> > Is there some billing account entity I missed to hold credits?
>
> If you get a payment from a customer, and you completely associate it
> (with a PaymentApplication record) to the customer's billing account,
> then you apply it to the invoices in the account and let's say that 10$
> are left (overpayment), these dollars will increase tha vailable amount
> in the billing account (because they are not applied to any invoice) and
> so you can use them for future orders
>
> Jacopo
>
> >
> > 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
> >
>
>
>