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 > >
