Posted by
SkipDever on
Nov 02, 2007; 7:42pm
URL: http://ofbiz.116.s1.nabble.com/Accounts-Receivable-tp184969p184996.html
Jacapo
With the current situation, there is no guaranteed way to report on the
details of a billing account, as in what invoices are unpaid, when an
invoice was payed, what payment was applied to what invoice, etc. It is
possible to apply a payment to an invoice, but not required.
The use of OrderPaymentPreference to compute billing account balances is
flawed in that it sometimes misses taxes, and shipping charges or other
miscellaneous charges. This is currently a minor issue because the amounts
are small and not seen by the customer unless they look closely. However,
it becomes a major issue when you start sending out billing statements and
especially dunn letters. Also, I just don't like accounting errors and that
to me is really the issue here.
These numbers are not taken from the underlying data and while they may be
right sometimes, because the raw data is not used to construct them, they
are guaranteed to be wrong sometime.
The raw data in this case are the invoices and payments on the account.
Things would be simple if Payments had a billingAccountId field, but alas,
because it does not, the PaymentAndApplication view entity can be used in
its place. It just makes the reporting a little harder.
The above is what this proposal accomplishes, i.e. moving the reporting away
from secondary data sources onto the primary.
It is accomlished by creating a new org.obfiz.accounting.ar package that
contains some new services and routines to replace some existing ones
currently found in BillingAccountWorker. I currently have this all in a
hot-deploy/ar directory.
What is not done is the Ofbiz GUI work. I have been testing the logic using
either java standalone applications or modified Opentaps.
After getting it running, I would test against Ofbiz, but making sure that I
"did the right thing". TODO in Ofbiz GUI is to remove the opportunity to do
the wrong thing, which in this case is applying a payment to anything but an
invoice. I have a single button click routine to apply a payment to
invoices beginning with the oldest, but I have not hooked it up to Ofbiz
code and won't unless this becomes mainsteamed.
Skip
-----Original Message-----
From: Jacopo Cappellato [mailto:
[hidden email]]
Sent: Thursday, November 01, 2007 11:09 PM
To:
[hidden email]
Subject: Re: Accounts Receivable
Hi Skip,
this looks interesting.
However, from your message, it is not completely clear to me when you
speak about existing features/issues or new features (and issues?) in
your upcoming contribution.
It would be great if you could split the message into two parts:
1) one that describes the current situation with focus on possible issues
2) one with your proposal and suggested changes; (and also with new
issues, if there are any)
This would help a lot to simplify the discussion.
Thanks,
Jacopo
skip@theDevers wrote:
> 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
>>>