[EMAIL PROTECTED] 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:[EMAIL PROTECTED]
Sent: Monday, October 29, 2007 11:50 AM
To: dev@ofbiz.apache.org
Subject: Re: Accounts Receivable


Hi Skip,

[EMAIL PROTECTED] 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 <[EMAIL PROTECTED]> wrote:
[EMAIL PROTECTED] 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


Reply via email to