Hello Support:

A client has pointed out an inconsistency in costing. We have configured the PO module to allow 5 decimal places for costs. They rarely need that many but a cost of $0.525 per unit is common. It works very well.

But when they next create a new PO and add that item, the default cost (which comes from "Most Recent Cost") will appear as $0.53. This leads to the occasional error and requires constant vigilance because it's not obvious to the user that figure is a rounded cost.

This happens because the "Most Recent Cost" and related fields use the number of decimal places specified by the currency belonging to the dataset (dollars in most cases).

Request: Can the "Most Recent Cost" field track more decimal places? This would apply to a number of related fields like "Previous Most Recent" cost. This client uses Sundry items in PO but it would apply more importantly to Inventory and also to Order Entry.

Hi Bruce

I too have faced this problem. The way around it is to make the following changes in PurchaseOrders: 1) change the "Use as default unit cost" to Standard Cost in Company Profile, and 2) set the "Update second cost to" Standard Cost with Net Item Cost", also in Company Profile. Then in Inventory, create an Alternative Price List called 5D and add any item with more than 2 decimal unit costing to that APL, making sure to set the "Decimal places in unit price" to 5.

Back in PurchaseOrders, set the Price List field under "Define Entry Template" to default to 5D.

Now when you create a new PO, it will pull from the "Markup cost" field (which is really the Standard Cost, but badly named), and if you change the unit cost and post the PO, it will update that same Markup cost field for the next PO (as well as update the most recent cost field).

I hope Softrak realizes that this is a pretty ridiculous workaround, especially since the unit cost fields in Inventory are already stored internally out to 6 decimals. So I second your request.

Steve

PS - I just tested this out in PO 9.2B, and at least for Sundry Items, the unit cost goes out to the number specified in Company Profile, so for your client, who uses Sundry Items, just tell them to upgrade to 9.2B (when it is released)

Hi Steve,

The Unit Cost fields in Inventory are stored to two decimal places (actually the currency value). They are calculated out to 6 decimal places when used in the program.

Changing the stored precision would require concurrent releases of PurchaseOrders, Inventory, and SalesCQ.

Hi Steve:

The first part of your answer described a process so complex it would require an MIT graduate to understand. Oh wait, that's right - you genuinely are an MIT graduate!

But the second part of your answer appeals to my non-MIT mind. I checked and you are correct - in PO 9.2B the Sundry Items do have costs saved to the decimal places specified in the Company Profile. I re-read the Release Notes and found this change described at the bottom of page 4.

Thank you Steve.

Hi Andrew

Sorry, I was under the impression the costs fields were stored out to 6 decimals.

But it still is a pretty ridiculous workaround, which dampens the excitement when I tell clients and prospects that Adagio can handle unit costing out to more than 2 decimals.

At least if they don't use the Inventory module and use Sundry Items, I can now say it with enthusiasm.

Steve