> 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:
[hidden email]]
> Sent: Thursday, November 01, 2007 3:43 AM
> To:
[hidden email]
> 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 <
[hidden email]> 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
>>>