Dev - returns price total problem and proposed solution

[Si Chen-2]

Hi everyone -

We've found this problem with [quick refund entire order]:

If you have an order with 4 items of $2 each and a promotional discount
of $1, you would get an error of "$2 exceeds order total of $7" when you
try to quick refund it.

What actually happens is that quickRefundEntireOrder will try to add
each return item price to the return one by one, then add the
adjustments.  Thus, the total of all return items would get to $8 before
the adjustment brings it back down to $7.

I think the *right* answer is to take the amount checking logic out of
createReturnItem and move it to the service which updates return
status.  As a result, all the return items and their adjustments could
be added first, and then only when the return is to be "Accepted" do we
check if the amounts go over the order amounts.

This has a few advantages:
1.  quick refund entire order would work without a hack
2.  users can create returns and add return items in a "working mode"
and then have it validated when it's ready.
3.  it would be possible to parametrize this so some stores don't
require return totals <= order totals

We could also change the returns interface so that it shows a warning
message "Return total exceeds order total" while the return is being
created and worked on.

What do you think?

Si


 
_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev

[Daniel Kunkel]

Hi Si

That sounds good to me. Will this service also alert when an item has
been returned that would disqualify any promos?

Thanks


On Fri, 2006-01-20 at 06:23 -0800, Si Chen wrote:

> Hi everyone -
>
> We've found this problem with [quick refund entire order]:
>
> If you have an order with 4 items of $2 each and a promotional discount
> of $1, you would get an error of "$2 exceeds order total of $7" when you
> try to quick refund it.
>
> What actually happens is that quickRefundEntireOrder will try to add
> each return item price to the return one by one, then add the
> adjustments.  Thus, the total of all return items would get to $8 before
> the adjustment brings it back down to $7.
>
> I think the *right* answer is to take the amount checking logic out of
> createReturnItem and move it to the service which updates return
> status.  As a result, all the return items and their adjustments could
> be added first, and then only when the return is to be "Accepted" do we
> check if the amounts go over the order amounts.
>
> This has a few advantages:
> 1.  quick refund entire order would work without a hack
> 2.  users can create returns and add return items in a "working mode"
> and then have it validated when it's ready.
> 3.  it would be possible to parametrize this so some stores don't
> require return totals <= order totals
>
> We could also change the returns interface so that it shows a warning
> message "Return total exceeds order total" while the return is being
> created and worked on.
>
> What do you think?
>
> Si
>
>
>  
> _______________________________________________
> Dev mailing list
> [hidden email]
> http://lists.ofbiz.org/mailman/listinfo/dev

 
_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev

[David E. Jones]

I agree. This sounds like a much more useful place to check it from a  
flexible but still safe perspective.

-David


On Jan 20, 2006, at 7:23 AM, Si Chen wrote:

> Hi everyone -
>
> We've found this problem with [quick refund entire order]:
>
> If you have an order with 4 items of $2 each and a promotional  
> discount
> of $1, you would get an error of "$2 exceeds order total of $7"  
> when you
> try to quick refund it.
>
> What actually happens is that quickRefundEntireOrder will try to add
> each return item price to the return one by one, then add the
> adjustments.  Thus, the total of all return items would get to $8  
> before
> the adjustment brings it back down to $7.
>
> I think the *right* answer is to take the amount checking logic out of
> createReturnItem and move it to the service which updates return
> status.  As a result, all the return items and their adjustments could
> be added first, and then only when the return is to be "Accepted"  
> do we
> check if the amounts go over the order amounts.
>
> This has a few advantages:
> 1.  quick refund entire order would work without a hack
> 2.  users can create returns and add return items in a "working mode"
> and then have it validated when it's ready.
> 3.  it would be possible to parametrize this so some stores don't
> require return totals <= order totals
>
> We could also change the returns interface so that it shows a warning
> message "Return total exceeds order total" while the return is being
> created and worked on.
>
> What do you think?
>
> Si
>
>
>
> _______________________________________________
> Dev mailing list
> [hidden email]
> http://lists.ofbiz.org/mailman/listinfo/dev

 
_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev