Sage 100

There is a Valuation field in open SO / PO transactions.  If you try a work-around (like count to zero and make the change manually instead of using the Sage utility), you could have subsequent transactions posted incorrectly.  (This is especially important when changing to / from a valuation including cost tiers... think: a Lot item posting a PO receipt with the line valuation incorrectly tagged as Standard valuation...).

Open Purchase Orders store the valuation method, the Valuation change Utility updates that field as part of the process. So, if you manually set the valuation method in DFDM that will not get updated.  

If you can verify that the items you are changing do not exist in the PO and SO batches, you might get away with renaming the data entry tables (if they are not on premium) and doing a manual reinitialization of them, then you could run the valuation change utility. After you run the utility, you could then rename the data entry tables back and rebuild sort files. I've not done this, it is just a theory that I've thought of in the past but never tried. 

There is a Valuation field in open SO / PO transactions.  If you try a work-around (like count to zero and make the change manually instead of using the Sage utility), you could have subsequent transactions posted incorrectly.  (This is especially important when changing to / from a valuation including cost tiers... think: a Lot item posting a PO receipt with the line valuation incorrectly tagged as Standard valuation...).

There are only a couple items.  If I adjust quantities to 0, then print the SO and PO open orders by item and these items are not in the open orders do you think it's safe to change ci_item valuation method?

Open Purchase Orders store the valuation method, the Valuation change Utility updates that field as part of the process. So, if you manually set the valuation method in DFDM that will not get updated.  

If you can verify that the items you are changing do not exist in the PO and SO batches, you might get away with renaming the data entry tables (if they are not on premium) and doing a manual reinitialization of them, then you could run the valuation change utility. After you run the utility, you could then rename the data entry tables back and rebuild sort files. I've not done this, it is just a theory that I've thought of in the past but never tried. 

There is a Valuation field in open SO / PO transactions.  If you try a work-around (like count to zero and make the change manually instead of using the Sage utility), you could have subsequent transactions posted incorrectly.  (This is especially important when changing to / from a valuation including cost tiers... think: a Lot item posting a PO receipt with the line valuation incorrectly tagged as Standard valuation...).

Unless anyone has any cautionary words - I tested this for an item not on any open transactions and didn't see an issue initially, but recommend that you try this on their system in a test company and then process at least one of each type of transaction to ensure you're getting the right results.

There are only a couple items.  If I adjust quantities to 0, then print the SO and PO open orders by item and these items are not in the open orders do you think it's safe to change ci_item valuation method?

Open Purchase Orders store the valuation method, the Valuation change Utility updates that field as part of the process. So, if you manually set the valuation method in DFDM that will not get updated.  

If you can verify that the items you are changing do not exist in the PO and SO batches, you might get away with renaming the data entry tables (if they are not on premium) and doing a manual reinitialization of them, then you could run the valuation change utility. After you run the utility, you could then rename the data entry tables back and rebuild sort files. I've not done this, it is just a theory that I've thought of in the past but never tried. 

There is a Valuation field in open SO / PO transactions.  If you try a work-around (like count to zero and make the change manually instead of using the Sage utility), you could have subsequent transactions posted incorrectly.  (This is especially important when changing to / from a valuation including cost tiers... think: a Lot item posting a PO receipt with the line valuation incorrectly tagged as Standard valuation...).

I've seen RMA transactions use the incorrect Valuation, but I am not sure if that is a general bug, or consequences of not using the utility.

Unless anyone has any cautionary words - I tested this for an item not on any open transactions and didn't see an issue initially, but recommend that you try this on their system in a test company and then process at least one of each type of transaction to ensure you're getting the right results.

There are only a couple items.  If I adjust quantities to 0, then print the SO and PO open orders by item and these items are not in the open orders do you think it's safe to change ci_item valuation method?

Open Purchase Orders store the valuation method, the Valuation change Utility updates that field as part of the process. So, if you manually set the valuation method in DFDM that will not get updated.  

If you can verify that the items you are changing do not exist in the PO and SO batches, you might get away with renaming the data entry tables (if they are not on premium) and doing a manual reinitialization of them, then you could run the valuation change utility. After you run the utility, you could then rename the data entry tables back and rebuild sort files. I've not done this, it is just a theory that I've thought of in the past but never tried. 

There is a Valuation field in open SO / PO transactions.  If you try a work-around (like count to zero and make the change manually instead of using the Sage utility), you could have subsequent transactions posted incorrectly.  (This is especially important when changing to / from a valuation including cost tiers... think: a Lot item posting a PO receipt with the line valuation incorrectly tagged as Standard valuation...).