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 |
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 skip@theDevers 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 > > |
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:[hidden email]] Sent: Thursday, September 13, 2007 2:00 PM To: [hidden email] 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 skip@theDevers 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 > 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 > > |
Hi Skip,
I also noticed this problem and maybe this will help you. If you create order that is payed with billing account(BA) then in OrderPaymentPreference entity is created record with status PAYMENT_NOT_RECEIVED. The account balance is calculated considering this entries and payments that are applied to the billing account, but are not applied to the invoice. Everything is OK if you create order, then invoice it, then create payment and apply it only to the BA(the best UI is throught the new form and service that Jacopo created recently r574962 - https://demo.hotwaxmedia.com/accounting/control/BillingAccountPayments?billingAccountId=9010) and then use the capture ability from the BA -> invoices screen to apply this payment to the invoice too. In that case the the BA balance behaves as it should. This is because capture ability invokes the service "processCaptureSplitPayment" that takes care to update the status of the OrderPaymentPreference entries(changes it to PAYMENT_RECEIVED). The problem is if you apply payments to the invoice from another UI(E.g https://demo.hotwaxmedia.com/accounting/control/editPaymentApplications?paymentId=demo10000) the OrderPaymentPreference record is not updated - so BA balance is wrong. I was willing to fix this but had no time to do it. Regards, Rashko Rejmer |
In reply to this post by SkipDever
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 skip@theDevers 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:[hidden email]] > Sent: Thursday, September 13, 2007 2:00 PM > To: [hidden email] > 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 > > > skip@theDevers 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 >> >> > |
In reply to this post by Rashko Rejmer
Rashko
Thanks a load for this. I have been going through the code in OrderReturnServices and other places and see that it is thorough and well thought out. It appears as if the UI is not calling these services in some cases. You are exactly right, I was using editPaymentApplications to apply the payment to the invoice as this is how most of the other applications I have worked with expected you to do it. I'll have a look at this processCaptureSplitPayment service and see if I can use its code to fix editPaymentApplications. Thanks again Skip -----Original Message----- From: Rashko Rejmer [mailto:[hidden email]] Sent: Thursday, September 13, 2007 3:56 PM To: [hidden email] Subject: RE: Billing Accounts Hi Skip, I also noticed this problem and maybe this will help you. If you create order that is payed with billing account(BA) then in OrderPaymentPreference entity is created record with status PAYMENT_NOT_RECEIVED. The account balance is calculated considering this entries and payments that are applied to the billing account, but are not applied to the invoice. Everything is OK if you create order, then invoice it, then create payment and apply it only to the BA(the best UI is throught the new form and service that Jacopo created recently r574962 - https://demo.hotwaxmedia.com/accounting/control/BillingAccountPayments?billi ngAccountId=9010) and then use the capture ability from the BA -> invoices screen to apply this payment to the invoice too. In that case the the BA balance behaves as it should. This is because capture ability invokes the service "processCaptureSplitPayment" that takes care to update the status of the OrderPaymentPreference entries(changes it to PAYMENT_RECEIVED). The problem is if you apply payments to the invoice from another UI(E.g https://demo.hotwaxmedia.com/accounting/control/editPaymentApplications?paym entId=demo10000) the OrderPaymentPreference record is not updated - so BA balance is wrong. I was willing to fix this but had no time to do it. Regards, Rashko Rejmer -- View this message in context: http://www.nabble.com/Billing-Accounts-tf4438293.html#a12665336 Sent from the OFBiz - User mailing list archive at Nabble.com. |
In reply to this post by David E Jones
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:[hidden email]] Sent: Thursday, September 13, 2007 5:08 PM To: [hidden email] 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 skip@theDevers 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:[hidden email]] > Sent: Thursday, September 13, 2007 2:00 PM > To: [hidden email] > 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 > > > skip@theDevers 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 >> 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 >> >> > |
In reply to this post by Rashko Rejmer
Rashko,
thanks, this is interesting. I was pretty sure this was implemented in some ways (I don't remember how right now) but maybe there is something wrong with the logic; by the way I've created a Jira issue to keep track of your valuable comments: https://issues.apache.org/jira/browse/OFBIZ-1243 Jacopo Rashko Rejmer wrote: > Hi Skip, > > I also noticed this problem and maybe this will help you. If you create > order that is payed with billing account(BA) then in OrderPaymentPreference > entity is created record with status PAYMENT_NOT_RECEIVED. The account > balance is calculated considering this entries and payments that are applied > to the billing account, but are not applied to the invoice. > Everything is OK if you create order, then invoice it, then create payment > and apply it only to the BA(the best UI is throught the new form and service > that Jacopo created recently r574962 - > https://demo.hotwaxmedia.com/accounting/control/BillingAccountPayments?billingAccountId=9010) > and then use the capture ability from the BA -> invoices screen to apply > this payment to the invoice too. In that case the the BA balance behaves as > it should. This is because capture ability invokes the service > "processCaptureSplitPayment" that takes care to update the status of the > OrderPaymentPreference entries(changes it to PAYMENT_RECEIVED). > > The problem is if you apply payments to the invoice from another UI(E.g > https://demo.hotwaxmedia.com/accounting/control/editPaymentApplications?paymentId=demo10000) > the OrderPaymentPreference record is not updated - so BA balance is wrong. > > I was willing to fix this but had no time to do it. > > Regards, > Rashko Rejmer |
In reply to this post by Rashko Rejmer
Rashko,
is it possible that the error you are seeing, when applying a payment to a billing account using the generic screen, is happening only if you fill both the invoiceId and billingAccountId fields and submit the form? If you just fill the billingAccountId field it should work as expected. Could you please confirm if my guess is right? Jacopo Rashko Rejmer wrote: > Hi Skip, > > I also noticed this problem and maybe this will help you. If you create > order that is payed with billing account(BA) then in OrderPaymentPreference > entity is created record with status PAYMENT_NOT_RECEIVED. The account > balance is calculated considering this entries and payments that are applied > to the billing account, but are not applied to the invoice. > Everything is OK if you create order, then invoice it, then create payment > and apply it only to the BA(the best UI is throught the new form and service > that Jacopo created recently r574962 - > https://demo.hotwaxmedia.com/accounting/control/BillingAccountPayments?billingAccountId=9010) > and then use the capture ability from the BA -> invoices screen to apply > this payment to the invoice too. In that case the the BA balance behaves as > it should. This is because capture ability invokes the service > "processCaptureSplitPayment" that takes care to update the status of the > OrderPaymentPreference entries(changes it to PAYMENT_RECEIVED). > > The problem is if you apply payments to the invoice from another UI(E.g > https://demo.hotwaxmedia.com/accounting/control/editPaymentApplications?paymentId=demo10000) > the OrderPaymentPreference record is not updated - so BA balance is wrong. > > I was willing to fix this but had no time to do it. > > Regards, > Rashko Rejmer |
Hi Jacopo,
Yes, you are right. If you apply payment only to the billing account everything is OK. If you apply it to the invoice that is associated to the billing account the updatePaymenetApplication method will automatically apply this payment to the BA too. So the problem appear if you fill only invoiceId field too. Regards, Rashko Rejmer On Sat, 2007-09-15 at 09:20 +0200, Jacopo Cappellato wrote: > Rashko, > > is it possible that the error you are seeing, when applying a payment to > a billing account using the generic screen, is happening only if you > fill both the invoiceId and billingAccountId fields and submit the form? > If you just fill the billingAccountId field it should work as expected. > > Could you please confirm if my guess is right? > > Jacopo > > > Rashko Rejmer wrote: > > Hi Skip, > > > > I also noticed this problem and maybe this will help you. If you create > > order that is payed with billing account(BA) then in OrderPaymentPreference > > entity is created record with status PAYMENT_NOT_RECEIVED. The account > > balance is calculated considering this entries and payments that are applied > > to the billing account, but are not applied to the invoice. > > Everything is OK if you create order, then invoice it, then create payment > > and apply it only to the BA(the best UI is throught the new form and service > > that Jacopo created recently r574962 - > > https://demo.hotwaxmedia.com/accounting/control/BillingAccountPayments?billingAccountId=9010) > > and then use the capture ability from the BA -> invoices screen to apply > > this payment to the invoice too. In that case the the BA balance behaves as > > it should. This is because capture ability invokes the service > > "processCaptureSplitPayment" that takes care to update the status of the > > OrderPaymentPreference entries(changes it to PAYMENT_RECEIVED). > > > > The problem is if you apply payments to the invoice from another UI(E.g > > https://demo.hotwaxmedia.com/accounting/control/editPaymentApplications?paymentId=demo10000) > > the OrderPaymentPreference record is not updated - so BA balance is wrong. > > > > I was willing to fix this but had no time to do it. > > > > Regards, > > Rashko Rejmer > > |
Free forum by Nabble | Edit this page |