You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@ofbiz.apache.org by Anne <an...@cohsoft.com.au> on 2008/04/16 09:06:03 UTC
OrderReadHelper doubling some of the item subtotal calculations????
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi
I've been looking through OrderReadHelper.java and found something that
I think is wrong, but I don't understand what's going on well enough to
be sure I am right. Could someone please take a look and see if this is
a serious bug that needs fixing?
I'm looking at a recent version from svn a few days ago.
The main code of concern is the method
public static BigDecimal getOrderItemsSubTotal(List orderItems, List
adjustments, List workEfforts)
Essentially it calls
BigDecimal itemTotal = getOrderItemSubTotal(orderItem, adjustments);
for each orderItem and then, if workEfforts is not null and the item is
a RENTAL_ORDER_ITEM it does a
itemTotal =
itemTotal.multiply(getWorkEffortRentalQuantity(workEffort)).setScale(scale,
rounding);
However the initial call to getOrderItemSubTotal(orderItem, adjustments)
ends up calling
public static BigDecimal getOrderItemSubTotal(GenericValue
orderItem, List adjustments, boolean forTax, boolean forShipping)
and this method seems to repeat the same logic for RENTAL_ORDER_ITEMs.
If I am reading this correctly, that means the result of the first
method will count the workeffort for RENTAL_ORDER_ITEMs twice.
Cheers,
Anne.
- --
Coherent Software Australia Pty Ltd
PO Box 2773
Cheltenham Vic 3192
Phone: (03) 9585 6788
Fax: (03) 9585 1086
Web: http://www.cohsoft.com.au/
Email: sales@cohsoft.com.au
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFIBaVbtgv4pchABrERAkY7AKCasGjO/MsbDkXVU9E/XqPDrrXlKgCeIMh0
mHSNz8goO5lWSNpM4DSvJuo=
=a79E
-----END PGP SIGNATURE-----
Re: OrderReadHelper doubling some of the item subtotal calculations????
Posted by Scott Gray <le...@gmail.com>.
Quite possible, I don't the rental stuff is as robust as some of the other
order code. If you can create steps to reproduce the problem on a demo
server then I'm sure someone could get to the bottom of it pretty quickly.
Regards
Scott
On 16/04/2008, Anne <an...@cohsoft.com.au> wrote:
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi
>
> I've been looking through OrderReadHelper.java and found something that
> I think is wrong, but I don't understand what's going on well enough to
> be sure I am right. Could someone please take a look and see if this is
> a serious bug that needs fixing?
>
> I'm looking at a recent version from svn a few days ago.
>
> The main code of concern is the method
>
> public static BigDecimal getOrderItemsSubTotal(List orderItems, List
> adjustments, List workEfforts)
>
> Essentially it calls
>
> BigDecimal itemTotal = getOrderItemSubTotal(orderItem, adjustments);
>
> for each orderItem and then, if workEfforts is not null and the item is
> a RENTAL_ORDER_ITEM it does a
>
> itemTotal =
>
> itemTotal.multiply(getWorkEffortRentalQuantity(workEffort)).setScale(scale,
> rounding);
>
>
> However the initial call to getOrderItemSubTotal(orderItem, adjustments)
> ends up calling
>
> public static BigDecimal getOrderItemSubTotal(GenericValue
> orderItem, List adjustments, boolean forTax, boolean forShipping)
>
> and this method seems to repeat the same logic for RENTAL_ORDER_ITEMs.
> If I am reading this correctly, that means the result of the first
> method will count the workeffort for RENTAL_ORDER_ITEMs twice.
>
> Cheers,
> Anne.
>
> - --
> Coherent Software Australia Pty Ltd
> PO Box 2773
> Cheltenham Vic 3192
> Phone: (03) 9585 6788
> Fax: (03) 9585 1086
> Web: http://www.cohsoft.com.au/
> Email: sales@cohsoft.com.au
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.6 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iD8DBQFIBaVbtgv4pchABrERAkY7AKCasGjO/MsbDkXVU9E/XqPDrrXlKgCeIMh0
> mHSNz8goO5lWSNpM4DSvJuo=
> =a79E
> -----END PGP SIGNATURE-----
>
Re: OrderReadHelper doubling some of the item subtotal calculations????
Posted by Anne <an...@cohsoft.com.au>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Thank you Bilgin. I didn't understand that WorkOrderItemFulfillments
would be null if workEfforts was not null. It makes all the difference
to my reading of that code.
I'm not actually trying to use the rental options at this stage, just
trying to learn my way around well enough to make some modifications.
I'd prefer to change things the "right" way, if I can work out what the
right way is!
Cheers,
Anne.
Bilgin Ibryam wrote:
> Hi Anne,
>
> the code in these methods is very confusing and a refactoring is needed
> for sure.
> But at the moment it calculates the item subtotals right.
>
> If the workEfforts is not null, WorkOrderItemFulfillments is null and "
> itemTotal =
> itemTotal.multiply(getWorkEffortRentalQuantity(workEffort)).setScale(scale,
> rounding); " is not called at all. That's why it doesn't calculates it
> twice...
>
> And if the workEffort is null , then "itemTotal =
> itemTotal.multiply(getWorkEffortRentalQuantity(workEffort)).setScale(scale,
> rounding); " is called.
>
> Bilgin
>
- --
Coherent Software Australia Pty Ltd
PO Box 2773
Cheltenham Vic 3192
Phone: (03) 9585 6788
Fax: (03) 9585 1086
Web: http://www.cohsoft.com.au/
Email: sales@cohsoft.com.au
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFIBtcytgv4pchABrERAp0eAJoCHTvkvBSapzBtK1pze5TRcCjt1ACfVyl0
2ftx7ev9icC6+rmmg6DGFYc=
=enbO
-----END PGP SIGNATURE-----
Re: OrderReadHelper doubling some of the item subtotal calculations????
Posted by Anne <an...@cohsoft.com.au>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi Scott
Yes, I've already read most (all?) of the discussions. I like the idea
of splitting GST from VAT, but that's beyond my knowledge of ofbiz and
VAT, and also beyond the time I have available.
Fortunately I don't currently need full and proper support for GST, just
a system that looks like it knows about GST from the view of an
ecommerce customer. At this stage I'm assuming ofbiz does the right
thing for a VAT of 10%, and making changes where the displayed numbers
don't match. So far this approach seems to be working. But it is early days.
Cheers,
Anne.
Scott Gray wrote:
> Hi Anne
>
> I would suggest searching nabble (http://www.nabble.com/OFBiz-f2740.html) as
> GST/VAT has been discussed quite a few times.
>
> Regards
> Scott
>
- --
Coherent Software Australia Pty Ltd
PO Box 2773
Cheltenham Vic 3192
Phone: (03) 9585 6788
Fax: (03) 9585 1086
Web: http://www.cohsoft.com.au/
Email: sales@cohsoft.com.au
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFIBvrstgv4pchABrERAh+TAJ0R2ktSwrN6JzeYu/Ui0KvAbH8TOgCgwVgb
8qBBxkp2YcnosAozBu3fmnk=
=QFdj
-----END PGP SIGNATURE-----
Re: OrderReadHelper doubling some of the item subtotal calculations????
Posted by Scott Gray <le...@gmail.com>.
Hi Anne
I would suggest searching nabble (http://www.nabble.com/OFBiz-f2740.html) as
GST/VAT has been discussed quite a few times.
Regards
Scott
On 17/04/2008, Anne <an...@cohsoft.com.au> wrote:
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
> Hi Jon
>
> Thanks for your enlightening comments. OfBiz is a big system to try to
> learn, and when I find code in one area that does things the way I want,
> but can't find matching code in other places I expect it, I get worried
> the code is there but that I'm looking in the wrong place. Your comments
> reassure me that when I can't find the code I expect, it may well be
> because it doesn't exist.
>
> Yes, tax calculation (specifically GST) is proving very interesting.
> Currently I'm mainly looking through the code, trying to work out where
> I should make changes that will display the right (for me!) values in
> the ecommerce interface, without breaking existing functionality. If I
> can, I'd like to make the changes general enough that at least some of
> them can be incorporated into the main code base.
>
> I don't need to worry about the accounting side yet, so I'm leaving that
> area of GST madness until (and if) I really need to deal with it.
>
> Thanks for the heads up with order items. I'm just now starting to look
> at that code properly.
>
> Cheers,
> Anne.
>
>
> Jonathon -- Improov wrote:
> > Hi Anne,
> >
> > Yes, you're right. In fact, for just about EVERY project I did involving
> > rentals or similar, I've had to completely overhaul that Java file.
> >
> > I've found myself coding very unique order calcs and handling for every
> > unique business. Not sure how any of those can be rolled into OFBiz for
> > generic use.
> >
> > Be prepared to roll your own, re-writing much of the codes there.
> > Another problem is EFT payments, truly odd. I think you'll find some
> > taxes and payment stuff requiring some degree of rewrite, seeing how
> > you're in Australia. :)
> >
> > There are also some serious bugs in order item explosion codes. Beware.
> > The problems permeate many areas to do with order items, including and
> > especially tax calculations.
> >
> > Jon
> >
>
>
> - --
> Coherent Software Australia Pty Ltd
> PO Box 2773
> Cheltenham Vic 3192
> Phone: (03) 9585 6788
> Fax: (03) 9585 1086
> Web: http://www.cohsoft.com.au/
> Email: sales@cohsoft.com.au
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.6 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
>
> iD8DBQFIBt3Ytgv4pchABrERAvMIAKCeUJntvBTEx5SzR0XQcU024aBeQACfVP49
> 1WMEtJB30wR1Q0nKDikLCTQ=
> =pFsX
> -----END PGP SIGNATURE-----
>
Re: OrderReadHelper doubling some of the item subtotal calculations????
Posted by Jonathon -- Improov <jo...@improov.com>.
Anne,
> So it is worth me making some effort to make my code good enough to be
> integrated.
I'm sure your codes will be good enough to be integrated; good codes make bug-catching easier, so
that's a powerful incentive.
As you mentioned in another post, you're finding [integrating your codes with OFBiz's] not as easy
as you hoped (especially shipping inc tax).
I did start out trying to retain as much of OFBiz codes (in some areas like invoicing and taxes)
as possible. But I find myself writing a whole new chunk parallel to existing OFBiz codes, rather
than neatly splicing in enhancements. Well, at least my new chunks use almost exactly the same
coding style and methodologies as existing codes, so that's "in line with OFBiz".
The problem is that many codes in OFBiz are themselves "parallel chunks of repeated codes". Hard
to splice in enhancements in a central location; only possibly to riddle the enhancements into
existing codes.
Is "parallel chunks of repeated codes" wrong? I think not really. Over time, all my codes do end
up like that, until I have time to refactor (put common factors into reusable chunks).
Just don't get disheartened. Some of us here start off with huge refactoring projects, and get
really tired quickly. Whatever codes work for you, use them. I find making a refactoring TODO list
more cost-effective than actually doing the refactoring. I get to meet my deadlines, while still
clearly documenting potential problems so I catch bugs easier if they occur.
As my bosses always say: "Get the job done, now!" :)
Jonathon
Anne wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi Jon
>
> Thanks for the tips.
>
>>> If I can, I'd like to make the changes general enough that at least
>>> some of them can be incorporated into the main code base.
>> You are working full-time for a company? :)
>
> Yes. My company. :-) Though I'm not the only employee.
>
>> I don't have that luxury. I
>> just build the codes needed by my clients, and leave it at that.
>> Massaging those codes to fit into OFBiz will cost me too much. Many
>> parts in OFBiz are not neatly structured enough (need further
>> refactoring) to plug in enhancements. That particular Java file you
>> mentioned is one of them.
>
> In many areas this is what I also will be doing, because I just can't
> justify the time to make the functionality general. However I figure
> that if a change I make can be incorporated into the main code base,
> then I'll benefit as upgrading will be easier. Also, if something I
> write has a bug (heaven forbid!) that someone else finds and fixes, or
> if the functionality is extended further by someone else, I benefit from
> that too. So it is worth me making some effort to make my code good
> enough to be integrated.
>
>> Some parts of OFBiz are truly truly neat, though.
>
> Yes, I'm noticing. OFBiz is a great system. I'm impressed with the
> careful design and amount of thought that has obviously gone into it. It
> has its warts, but what software doesn't? At least, being open source, I
> can do something about the warts.
>
> Cheers,
> Anne.
>
> - --
> Coherent Software Australia Pty Ltd
> PO Box 2773
> Cheltenham Vic 3192
> Phone: (03) 9585 6788
> Fax: (03) 9585 1086
> Web: http://www.cohsoft.com.au/
> Email: sales@cohsoft.com.au
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.6 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iD8DBQFICsVPtgv4pchABrERAiHWAKCYco66lMYUcUNDg/ag5GhAfKnrNgCgjhkM
> w6Sbh29ycr/wAy2gFh4HdvU=
> =TuON
> -----END PGP SIGNATURE-----
>
>
Re: OrderReadHelper doubling some of the item subtotal calculations????
Posted by Anne <an...@cohsoft.com.au>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi Jon
Thanks for the tips.
>> If I can, I'd like to make the changes general enough that at least
>> some of them can be incorporated into the main code base.
>
> You are working full-time for a company? :)
Yes. My company. :-) Though I'm not the only employee.
> I don't have that luxury. I
> just build the codes needed by my clients, and leave it at that.
> Massaging those codes to fit into OFBiz will cost me too much. Many
> parts in OFBiz are not neatly structured enough (need further
> refactoring) to plug in enhancements. That particular Java file you
> mentioned is one of them.
In many areas this is what I also will be doing, because I just can't
justify the time to make the functionality general. However I figure
that if a change I make can be incorporated into the main code base,
then I'll benefit as upgrading will be easier. Also, if something I
write has a bug (heaven forbid!) that someone else finds and fixes, or
if the functionality is extended further by someone else, I benefit from
that too. So it is worth me making some effort to make my code good
enough to be integrated.
> Some parts of OFBiz are truly truly neat, though.
Yes, I'm noticing. OFBiz is a great system. I'm impressed with the
careful design and amount of thought that has obviously gone into it. It
has its warts, but what software doesn't? At least, being open source, I
can do something about the warts.
Cheers,
Anne.
- --
Coherent Software Australia Pty Ltd
PO Box 2773
Cheltenham Vic 3192
Phone: (03) 9585 6788
Fax: (03) 9585 1086
Web: http://www.cohsoft.com.au/
Email: sales@cohsoft.com.au
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFICsVPtgv4pchABrERAiHWAKCYco66lMYUcUNDg/ag5GhAfKnrNgCgjhkM
w6Sbh29ycr/wAy2gFh4HdvU=
=TuON
-----END PGP SIGNATURE-----
Re: OrderReadHelper doubling some of the item subtotal calculations????
Posted by Jonathon -- Improov <jo...@improov.com>.
Hi Anne,
> Your comments reassure me that when I can't find the code I expect,
> it may well be because it doesn't exist.
This is what I do in my exploration of OFBiz:
1. Tear through the codes to find something I need.
2. Expend reasonable effort to confirm a bug or missing stuff.
(grep is a good friend)
3. Send email to OFBiz ML to ask for confirmation about bug or missing stuff.
If you don't get an answer half the time, then you're like me, asking obscure questions, or those
touching on difficult and convoluted or under-developed parts of OFBiz.
I see many questions posted by others, and those are answered.
While OFBiz has many holes, they are mostly inconsequential to most people. You might need some
areas of OFBiz that are not fully developed, like many of us often do. We may curse and swear
about having to roll our own codes in some areas, but OFBiz's base framework is immensely useful,
possibly a good 80% of the infrastructure of a typical web application.
> Yes, tax calculation (specifically GST) is proving very interesting.
If I recall correctly, most of the tax codes do work. Problems only come when you have exploded
items, canceled items, etc.
> If I can, I'd like to make the changes general enough that at least
> some of them can be incorporated into the main code base.
You are working full-time for a company? :) I don't have that luxury. I just build the codes
needed by my clients, and leave it at that. Massaging those codes to fit into OFBiz will cost me
too much. Many parts in OFBiz are not neatly structured enough (need further refactoring) to plug
in enhancements. That particular Java file you mentioned is one of them.
Some parts of OFBiz are truly truly neat, though. You'll find out soon enough who does good Java
here. :) When in doubt or in argument about code quality and design decisions, bug David Jones.
> I don't need to worry about the accounting side yet, so I'm leaving
> that area of GST madness until (and if) I really need to deal with
> it.
You'll likely need to fix some bugs in the Invoice side of things. Some Java file with the string
"Invoice" in it.
> Thanks for the heads up with order items. I'm just now starting to look
> at that code properly.
Once you start looking through it properly, you'll likely learn it well enough to document it for
the rest of us. I think you're good. You'll learn OFBiz quickly.
Lastly, as the saying goes, "it takes all kinds to make the world go round". The OFBiz community
truly has many kinds. Just make friends and enjoy yourself. Note that some may be managerial staff
who suck at coding, but have a lot of ERP software know-how. This community is not intensely geeky
and hostile, like some other open-source communities I know. I try to be as patient with the
community as the community is patient with me. I can be intensely geeky at times. :P
Enjoy OFBiz.
Jon
Anne wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi Jon
>
> Thanks for your enlightening comments. OfBiz is a big system to try to
> learn, and when I find code in one area that does things the way I want,
> but can't find matching code in other places I expect it, I get worried
> the code is there but that I'm looking in the wrong place. Your comments
> reassure me that when I can't find the code I expect, it may well be
> because it doesn't exist.
>
> Yes, tax calculation (specifically GST) is proving very interesting.
> Currently I'm mainly looking through the code, trying to work out where
> I should make changes that will display the right (for me!) values in
> the ecommerce interface, without breaking existing functionality. If I
> can, I'd like to make the changes general enough that at least some of
> them can be incorporated into the main code base.
>
> I don't need to worry about the accounting side yet, so I'm leaving that
> area of GST madness until (and if) I really need to deal with it.
>
> Thanks for the heads up with order items. I'm just now starting to look
> at that code properly.
>
> Cheers,
> Anne.
>
> Jonathon -- Improov wrote:
>> Hi Anne,
>>
>> Yes, you're right. In fact, for just about EVERY project I did involving
>> rentals or similar, I've had to completely overhaul that Java file.
>>
>> I've found myself coding very unique order calcs and handling for every
>> unique business. Not sure how any of those can be rolled into OFBiz for
>> generic use.
>>
>> Be prepared to roll your own, re-writing much of the codes there.
>> Another problem is EFT payments, truly odd. I think you'll find some
>> taxes and payment stuff requiring some degree of rewrite, seeing how
>> you're in Australia. :)
>>
>> There are also some serious bugs in order item explosion codes. Beware.
>> The problems permeate many areas to do with order items, including and
>> especially tax calculations.
>>
>> Jon
>>
>
> - --
> Coherent Software Australia Pty Ltd
> PO Box 2773
> Cheltenham Vic 3192
> Phone: (03) 9585 6788
> Fax: (03) 9585 1086
> Web: http://www.cohsoft.com.au/
> Email: sales@cohsoft.com.au
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.6 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iD8DBQFIBt3Ytgv4pchABrERAvMIAKCeUJntvBTEx5SzR0XQcU024aBeQACfVP49
> 1WMEtJB30wR1Q0nKDikLCTQ=
> =pFsX
> -----END PGP SIGNATURE-----
>
>
Re: OrderReadHelper doubling some of the item subtotal calculations????
Posted by Anne <an...@cohsoft.com.au>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi Jon
Thanks for your enlightening comments. OfBiz is a big system to try to
learn, and when I find code in one area that does things the way I want,
but can't find matching code in other places I expect it, I get worried
the code is there but that I'm looking in the wrong place. Your comments
reassure me that when I can't find the code I expect, it may well be
because it doesn't exist.
Yes, tax calculation (specifically GST) is proving very interesting.
Currently I'm mainly looking through the code, trying to work out where
I should make changes that will display the right (for me!) values in
the ecommerce interface, without breaking existing functionality. If I
can, I'd like to make the changes general enough that at least some of
them can be incorporated into the main code base.
I don't need to worry about the accounting side yet, so I'm leaving that
area of GST madness until (and if) I really need to deal with it.
Thanks for the heads up with order items. I'm just now starting to look
at that code properly.
Cheers,
Anne.
Jonathon -- Improov wrote:
> Hi Anne,
>
> Yes, you're right. In fact, for just about EVERY project I did involving
> rentals or similar, I've had to completely overhaul that Java file.
>
> I've found myself coding very unique order calcs and handling for every
> unique business. Not sure how any of those can be rolled into OFBiz for
> generic use.
>
> Be prepared to roll your own, re-writing much of the codes there.
> Another problem is EFT payments, truly odd. I think you'll find some
> taxes and payment stuff requiring some degree of rewrite, seeing how
> you're in Australia. :)
>
> There are also some serious bugs in order item explosion codes. Beware.
> The problems permeate many areas to do with order items, including and
> especially tax calculations.
>
> Jon
>
- --
Coherent Software Australia Pty Ltd
PO Box 2773
Cheltenham Vic 3192
Phone: (03) 9585 6788
Fax: (03) 9585 1086
Web: http://www.cohsoft.com.au/
Email: sales@cohsoft.com.au
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFIBt3Ytgv4pchABrERAvMIAKCeUJntvBTEx5SzR0XQcU024aBeQACfVP49
1WMEtJB30wR1Q0nKDikLCTQ=
=pFsX
-----END PGP SIGNATURE-----
RE: OrderReadHelper doubling some of the item subtotal calculations????
Posted by "skip@thedevers" <sk...@thedevers.org>.
Jonathon
Haven't heard your dulcet tones in quite a while. Welcome back.
Skip
-----Original Message-----
From: Jonathon -- Improov [mailto:jonw@improov.com]
Sent: Wednesday, April 16, 2008 6:14 AM
To: user@ofbiz.apache.org
Subject: Re: OrderReadHelper doubling some of the item subtotal
calculations????
Hi Anne,
Yes, you're right. In fact, for just about EVERY project I did involving
rentals or similar, I've
had to completely overhaul that Java file.
I've found myself coding very unique order calcs and handling for every
unique business. Not sure
how any of those can be rolled into OFBiz for generic use.
Be prepared to roll your own, re-writing much of the codes there. Another
problem is EFT payments,
truly odd. I think you'll find some taxes and payment stuff requiring some
degree of rewrite,
seeing how you're in Australia. :)
There are also some serious bugs in order item explosion codes. Beware. The
problems permeate many
areas to do with order items, including and especially tax calculations.
Jon
Bilgin Ibryam wrote:
> Hi Anne,
>
> the code in these methods is very confusing and a refactoring is needed
> for sure.
> But at the moment it calculates the item subtotals right.
>
> If the workEfforts is not null, WorkOrderItemFulfillments is null and "
> itemTotal =
>
itemTotal.multiply(getWorkEffortRentalQuantity(workEffort)).setScale(scale,
> rounding); " is not called at all. That's why it doesn't calculates it
> twice...
>
> And if the workEffort is null , then "itemTotal =
>
itemTotal.multiply(getWorkEffortRentalQuantity(workEffort)).setScale(scale,
> rounding); " is called.
>
> Bilgin
>
>
No virus found in this incoming message.
Checked by AVG.
Version: 7.5.519 / Virus Database: 269.22.13/1377 - Release Date: 4/14/2008
9:26 AM
No virus found in this outgoing message.
Checked by AVG.
Version: 7.5.519 / Virus Database: 269.22.13/1377 - Release Date: 4/14/2008
9:26 AM
Re: OrderReadHelper doubling some of the item subtotal calculations????
Posted by Jonathon -- Improov <jo...@improov.com>.
Hi Anne,
Yes, you're right. In fact, for just about EVERY project I did involving rentals or similar, I've
had to completely overhaul that Java file.
I've found myself coding very unique order calcs and handling for every unique business. Not sure
how any of those can be rolled into OFBiz for generic use.
Be prepared to roll your own, re-writing much of the codes there. Another problem is EFT payments,
truly odd. I think you'll find some taxes and payment stuff requiring some degree of rewrite,
seeing how you're in Australia. :)
There are also some serious bugs in order item explosion codes. Beware. The problems permeate many
areas to do with order items, including and especially tax calculations.
Jon
Bilgin Ibryam wrote:
> Hi Anne,
>
> the code in these methods is very confusing and a refactoring is needed
> for sure.
> But at the moment it calculates the item subtotals right.
>
> If the workEfforts is not null, WorkOrderItemFulfillments is null and "
> itemTotal =
> itemTotal.multiply(getWorkEffortRentalQuantity(workEffort)).setScale(scale,
> rounding); " is not called at all. That's why it doesn't calculates it
> twice...
>
> And if the workEffort is null , then "itemTotal =
> itemTotal.multiply(getWorkEffortRentalQuantity(workEffort)).setScale(scale,
> rounding); " is called.
>
> Bilgin
>
>
Re: OrderReadHelper doubling some of the item subtotal
calculations????
Posted by Bilgin Ibryam <bi...@iguanait.com>.
Hi Anne,
the code in these methods is very confusing and a refactoring is needed
for sure.
But at the moment it calculates the item subtotals right.
If the workEfforts is not null, WorkOrderItemFulfillments is null and "
itemTotal =
itemTotal.multiply(getWorkEffortRentalQuantity(workEffort)).setScale(scale,
rounding); " is not called at all. That's why it doesn't calculates it
twice...
And if the workEffort is null , then "itemTotal =
itemTotal.multiply(getWorkEffortRentalQuantity(workEffort)).setScale(scale,
rounding); " is called.
Bilgin