David E. Jones wrote:
Hold on a minute there.... did you actually test and find this to be a
problem? The +/- notation is an entity engine ONLY thing and should
never make it to the database.
This patch should be reverted and if +/- are making it to the database
instead of being replaced with an ASC/DESC by the entity engine then
THAT bug should be fixed.
This is a slippery slope and we should backup to the top before it
gets going...
-David
On Feb 2, 2007, at 6:16 PM, [EMAIL PROTECTED] wrote:
Author: sichen
Date: Fri Feb 2 17:16:36 2007
New Revision: 502824
URL: http://svn.apache.org/viewvc?view=rev&rev=502824
Log:
Fix a pretty significant bug with sequence of inventory item
reservations for orders: FIFO and LIFO were reversed (I checked this)
and the +/- notation does not work well with PostgreSQL
Modified:
ofbiz/trunk/applications/product/script/org/ofbiz/product/inventory/InventoryReserveServices.xml
Modified:
ofbiz/trunk/applications/product/script/org/ofbiz/product/inventory/InventoryReserveServices.xml
URL:
http://svn.apache.org/viewvc/ofbiz/trunk/applications/product/script/org/ofbiz/product/inventory/InventoryReserveServices.xml?view=diff&rev=502824&r1=502823&r2=502824
==============================================================================
---
ofbiz/trunk/applications/product/script/org/ofbiz/product/inventory/InventoryReserveServices.xml
(original)
+++
ofbiz/trunk/applications/product/script/org/ofbiz/product/inventory/InventoryReserveServices.xml
Fri Feb 2 17:16:36 2007
@@ -42,23 +42,26 @@
<entity-one entity-name="OrderHeader"
value-name="orderHeader"/>
<!-- before we do the find, put together the orderBy list
based on which reserveOrderEnumId is specified -->
+ <!-- FIFO=first in first out, so it should be order by
ASCending receive or expire date
+ LIFO=last in first out, so it means order by DESCending
receive or expire date
+ -->
<if-compare value="INVRO_GUNIT_COST" operator="equals"
field-name="reserveOrderEnumId" map-name="parameters">
- <set value="-unitCost" field="orderByString"/>
+ <set value="unitCost DESC" field="orderByString"/>
<else>
<if-compare value="INVRO_LUNIT_COST" operator="equals"
field-name="reserveOrderEnumId" map-name="parameters">
- <set value="+unitCost" field="orderByString"/>
+ <set value="unitCost ASC" field="orderByString"/>
<else>
<if-compare value="INVRO_FIFO_EXP" operator="equals"
field-name="reserveOrderEnumId" map-name="parameters">
- <set value="+expireDate" field="orderByString"/>
+ <set value="expireDate ASC" field="orderByString"/>
<else>
<if-compare value="INVRO_LIFO_EXP"
operator="equals" field-name="reserveOrderEnumId" map-name="parameters">
- <set value="-expireDate"
field="orderByString"/>
+ <set value="expireDate DESC"
field="orderByString"/>
<else>
<if-compare value="INVRO_LIFO_REC"
operator="equals" field-name="reserveOrderEnumId" map-name="parameters">
- <set value="+datetimeReceived"
field="orderByString"/>
+ <set value="datetimeReceived DESC"
field="orderByString"/>
<else>
<!-- the default reserveOrderEnumId is
INVRO_FIFO_REC, ie FIFO based on date received -->
- <set value="-datetimeReceived"
field="orderByString"/>
+ <set value="datetimeReceived ASC"
field="orderByString"/>
<set value="INVRO_FIFO_REC"
field="parameters.reserveOrderEnumId"/>
</else>
</if-compare>
David,
I worked on this with Leon, and we did test this a few times, and the
inventory reservation sequence was wrong. Previously when using the
FIFO reservation, the last item received was being reserved against
orders. It seems that "-datetimeReceived" was ordering them by
descending order of date time received, and as a result reservations
were done in the wrong sequence.
We did not realize that the + or - notation were an entity engine thing,
but please test the actual reservation of inventory before and after
this patch and let us know which behavior you feel is correct. I
realize this is a pretty basic fix to an existing feature, and I had
trouble believing that something like this could be broken, but we did
try it several times ourselves.
Si
