David For some businesses, orders=invoices. Actually, you never get an order, you get an invoice immediately when the sale is made. This I think is a matter of semantics. If you have only an invoice, the invoice date changes as the order is shipped. If you have an invoice and order, the invoice itself is created when the order is shipped.
I will indeed keep the distinction between orders and invoices clear (although mostly hidden from this customer). For the current customer, they don't need orders and their accounting is rigorous. However, the next customer may have different needs and so keeping the flexibility seems wise. As I dig deeper into the code base, I see that the code to implement the accounting I need is there (or mostly so). I guess I just need to go through the UI and expose only those screens that handle it right (or fix those that don't). You are also right in your comments "but pretty much any ERP or CRM system would..". However, this customer wants to now have a web presense as well. So my task is to first bring them up on Ofbiz (using only the back office tools) and keep their accounting needs managed, and then implement a public online presense. That is why I am focused so heavily on the correctness and reportability of these invoice transactions against billing accounts. I just don't want to stray from the Ofbiz model. If my changes are too drastic and cannot be worked back into the main code base, I'll be forever applying painful patches as new Ofbiz functionality comes out that I want. As far as legal proceedings go, it happens only rarely when companies get into trouble and cannot pay their bills. In these case though, an exact reproduction of all the transactions is required (for the highest success rate) to document your claim to the judge. Anyway, thanks for the input. Skip -----Original Message----- From: David E Jones [mailto:[EMAIL PROTECTED] Sent: Thursday, September 13, 2007 5:08 PM To: [email protected] Subject: Re: Billing Accounts 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 >> >> >
