I have this mostly working now and I want to run this past you guys to be
sure there are no objections or thoughts on the methods used. I would be
especially interested in hereing about any testing in out-of=the=way areas I
need to do.
1. First, billing accounts are based entirely on the existance of Payments
and Invoices against the billing account (we also take into account unbilled
Orders for available balance computations). We do not use
PaymentApplication alone or OrderPaymentPreference at all. There are flaws
and complications in the latter in that tax and shipping are not taken into
account and shipping charges added later seem to be ignored.
2. A customer can have multiple billing accounts.
3. Billing account net balance is the sum of the unpaid portion of all
Invoices against the billing account (including any credits).
3. Billing account available balance is the billing account limit - ((sum
of unpaid porting of invoices) + (unbilled Orders))
This has a flaw TODO (I think) in that if an Order is created with back
orders on it and part has been shipped and an invoice created for that part,
the whole Order will still subtract from the available balance.
4. When payments are made, they are never applied to just the billing
account. They are applied to an invoice belonging to the billing account.
If there is an unapplied balance, a new credit Invoice is created to hold
the unapplied balance.
This all works with Ofbiz code if I manually apply the payments to invoices.
There are many other possible ways to create a billing account
payment/application and I would have to remove them all except for one which
calls my new receiveBillingAccountPayment() service and automatically
applies the payment to the oldest invoice(s).
This also works with opentaps code if I comment out Si's
captureBillingAccountPayments and let the Ofbiz service run. There is one
screen to change in Opentaps code in viewCustomerBillAcct."Customer Billing
Account Transactions" where outstanding invoices are not being displayed. I
also had to modify the Opentaps ftl calls to com.openstragegies.xxx to call
the same named (and modified) Ofbiz routines.
TODO is a SECA to automatically apply any available credits when a new
billing account invoice is created.
Can anyone see any holes in this or have any comments?
Skip
-----Original Message-----
From: Scott Gray [mailto:[EMAIL PROTECTED]
Sent: Thursday, November 01, 2007 3:43 AM
To: dev@ofbiz.apache.org
Subject: Re: Accounts Receivable
Yeah I guess it would help with that, although you still could still
pay an invoice directly with it (no billingAccountId on the Invoice),
but you couldn't associate the Payment with more than one billing
account unless you went for a many to many relationship. But that's
fine, I just thought I'd ask as it was the first thing I saw that
didn't make sense to me.
Thanks
Scott
On 01/11/2007, Jacopo Cappellato <[EMAIL PROTECTED]> wrote:
> Hi Scott,
>
> Scott Gray wrote:
> > Hi Jacopo
> >
> > I decided to have a look at this stuff and it doesn't make sense to me
> > why we have the billingAccountId on PaymentApplication rather than on
> > Payment itself?
>
> I agree with you that having the billingAccountId in the Payment entity
> would have made things simpler. I did not design this, it was already
> there when I've refactored/fixed the billing account processes.
> However, having the billingAccountId in the PaymentApplication improve
> the flexibility: I could receive a Payment and use one part of it to pay
> an invoice (not associated to a billing account) and use the remaining
> to 'fill' a billing account.
>
> Jacopo
>
> > It seems like the logic is pretty much the same
> > except we're doing it in a roundabout sort of way by creating a
> > PaymentApplication with null invoiceId just to maintain the link.
> >
> > Thanks
> > Scott
> >
>
