You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@ofbiz.apache.org by "skip@theDevers" <sk...@thedevers.org> on 2007/09/13 22:44:58 UTC
Billing Accounts
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
Re: Billing Accounts
Posted by Jacopo Cappellato <ti...@sastau.it>.
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
Re: Billing Accounts
Posted by Rashko Rejmer <rr...@iguanait.com>.
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
>
>
Re: Billing Accounts
Posted by Jacopo Cappellato <ti...@sastau.it>.
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
RE: Billing Accounts
Posted by "skip@theDevers" <sk...@thedevers.org>.
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:rrejmer@iguanait.com]
Sent: Thursday, September 13, 2007 3:56 PM
To: user@ofbiz.apache.org
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.
RE: Billing Accounts
Posted by Rashko Rejmer <rr...@iguanait.com>.
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
--
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.
RE: Billing Accounts
Posted by "skip@theDevers" <sk...@thedevers.org>.
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:jonesde@hotwaxmedia.com]
Sent: Thursday, September 13, 2007 5:08 PM
To: user@ofbiz.apache.org
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:jonesde@hotwaxmedia.com]
> Sent: Thursday, September 13, 2007 2:00 PM
> To: user@ofbiz.apache.org
> 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
>>
>>
>
Re: Billing Accounts
Posted by David E Jones <jo...@hotwaxmedia.com>.
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:jonesde@hotwaxmedia.com]
> Sent: Thursday, September 13, 2007 2:00 PM
> To: user@ofbiz.apache.org
> 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
>>
>>
>
RE: Billing Accounts
Posted by "skip@theDevers" <sk...@thedevers.org>.
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:jonesde@hotwaxmedia.com]
Sent: Thursday, September 13, 2007 2:00 PM
To: user@ofbiz.apache.org
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
>
>
Re: Billing Accounts
Posted by David E Jones <jo...@hotwaxmedia.com>.
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
>
>