Rashko: I saw your reply and it looks good... thanks for commenting on this.
Skip: I'd say definitely keep the distinction between orders and invoices, in
general for business and especially with OFBiz as there are dozens of services
and thousands of lines of code treat them that way. In short orders are what
you receive from customers as a commitment to buy something and invoices are
what you send to customers to request that they pay for it.
Actually I'm a little amazed by what you're describing: no separation between
orders and invoices, but managing stuff that involves large transactions and
legal proceedings. If you're looking for ONLY an accounting system that's
actually fine, they only care about the financial transactions (like
QuickBooks), but pretty much any ERP or CRM system would (or should!) make this
distinction.
In theory OFBiz can be used as just an accounting system, ie invoices and
payments but no orders or shipments or anything, but as Rashko described not
everything has been implemented for these sorts of business processes.
-David
[EMAIL PROTECTED] wrote:
I am using the very latest Ofbiz code downloaded from svn yesterday
(575134).
And, yes, I would agree with your comment "isn't it better to understand the
intent and usage of something".
Would anyone care to enlighten me?
What I see is this. OrderPaymentPreference is tied to an orderId, not an
invoiceId. When you receive payments, you apply them against Invoices, not
orders. I do understand the the difference between "available balance" and
"net balance" in that orders can be in a state where invoices have not yet
been generated. However, the code in getBillingAccountBalance() uses
OrderPaymentPreference.maxAmount exclusively to compute available balance.
In fact, in my view, it should compute all of uninvoiced orders, credits,
and unpaid invoices.
While I do have problems with using invoices in that some companies do not
distinguish between orders and invoices, there needs to be some way of
tracking everything against a billing account. My customers have customers
with accounts in the hundreds of thousands of dollars involving hundreds and
thousands of transactions. It is frequently necessary to regurgitate
exactly what transactions made up the current balance, sometimes for
extended time periods. PaymentApplication serves this purpose perfectly.
To use it effectively, it is required to apply a payment to an invoice/order
as opposed to the billing account generally in order to compute interest
charges (which frequently require documentation in court proceedings). It
is possible to apply a payment to a billing account, but the underlying code
must apply the payment to Invoices to know how to age them.
Just my two cents based on ancient business practices. I would be happy to
hear alternatives. I would also be happy to hear from those who have
already solved this problem.
Skip
-----Original Message-----
From: David E Jones [mailto:[EMAIL PROTECTED]
Sent: Thursday, September 13, 2007 2:00 PM
To: [email protected]
Subject: Re: Billing Accounts
Which version/revision of OFBiz are you working with?
Also, in general, isn't it better to understand the intent and usage of
something like OrderPaymentPreference before deciding to throw it out, and
the same with the other code you are looking at?
-David
[EMAIL PROTECTED] wrote:
I think billing accounts are broken (or at least underimplemented).
Try this experiment.
1. Create a party with a billing account.
2. Sell something to him. (Use Account - Billing Accounts and check
available balance)
So far so good.
3. Quickship order. Again, so far so good.
4. Receive a payment.
5. Apply the payment to the invoice created above
You will note that the payment is not reflected in the available
balance.
6. Refund the entire order
You will note that neither the payment nor refund are reflected in the
available balance.
The opentaps folks have made some strides in making this better, but they
are still dealing with "legacy" Ofbiz code.
My customer needs to have this working and in a bullet-proof and intuitive
way. Every transaction on a billing account needs to be recorded and
reportable, especially including refunds and credits. I would like to go
back to the model shown on page 257 if the Data Model Resource Book.
Specifically, ofbiz makes use of the OrderPaymentPreferences entity which
is
no where to be found in this model in relation to payments received, is
confusing and error prone.
I am going to write my own services to handle all this replacing much of
the
code in BillingAccountWorker.java.
Is it possible to submit this back to Ofbiz so I can get updates in other
areas?
Skip
