fryeguy

I submitted a bug yesterday about the PO Request report.
When I use it, it appears that the cost and price per unit of wire type objects is displayed incorrectly.
Example: awire that costs $.20 per foot and sells for $.40 per foot shows up as $2.00 cost per unit and $4.00 price.

Is anyone else using this report with this result?

CJ976

Yes - I also experienced this. On 5/21/08 I brought this to D-Tools attention via a call to their office and spoke to someone about this. They could not believe that this was not caught earlier and was told this was going to be addressed right away - but it appears to still be happening.
I also mentioned my issue with the RI wiring not summarizing in my POs as mentioned in my post earlier.
Still have to use legacy reporting to product POs.

CJ976

Sooo - no one else has has problems with POs? I'm still waiting to see if this is addressed - no luck so far.

fryeguy

I have been meaning to dig into this report in the designer to see if this bug is something that can be dealt with in the report or if it is a bug in the schema that D-Tools needs to rectify on the data end...

RandyB

This was logged as a bug when first reported (#4468), and should be corrected in the next release. The issue is that the Cost field in the reporting XML shows the cost for the entire wire, rather than per unit length, for bulk wire.

I'm pretty sure I have corrected it in this custom report. Please download and see if it works. If it does, I'll post instructions for how I did it since it was pretty easy.

http://downloads.d-tools.com/si5/reports/Fixes/Purchase_Order_v2.zip

- Randy

fryeguy

Thanks Randy.

In my report I want Unit Cost, Total Cost, & Unit Price.

So I used your UnitEQCost & UnitEQPrice fields.
This works perfectly.

Now here is one more strange behavior:

On the PO 16/2 speaker wire shows up as 4 different line items.
I noticed the quantity is unique for each line item.
That is the only thing different about the lines.
Is this normal behavior?
Ideally on a PO instead of having four line items with quantities like 10, 150, 200, & 300 I would have one line item with a quantity of 660.

I notice in the same report when I look at speakers, I get a line item for a speaker model with qty. 26. I assume this is because each speaker is a line item in the data matrix.

What causes the data to be grouped by quantity in this report?

RandyB

Originally Posted by fryeguy

Now here is one more strange behavior: On the PO 16/2 speaker wire shows up as 4 different line items. I noticed the quantity is unique for each line item. That is the only thing different about the lines. Is this normal behavior? Ideally on a PO instead of having four line items with quantities like 10, 150, 200, & 300 I would have one line item with a quantity of 660. I notice in the same report when I look at speakers, I get a line item for a speaker model with qty. 26. I assume this is because each speaker is a line item in the data matrix. What causes the data to be grouped by quantity in this report?

The cause of this problem is that the data is grouped by the Cost field and not the UnitCost. For wires, the cost is equal to UnitCost * WireLength. This means that wires of the same length will be grouped, but wires with different lengths will each appear as a line item.

For now, your only option is to select the grpCost header and set DataField property to blank. This will fix the report for wires and cause all items to be grouped by Manufacturer and Model alone. Unfortunately, if you have identical products (Manu/Model) with different costs, they will get merged into one line since the report will no longer distinguish by cost. This may or may not be a problem for you, depending on how you track costs.

Going forward, we will fix this in 5.5 when there is a proper UnitCost data field. The Purchase Order report will be updated automatically when we do.

Sorry for the bug and the delayed response.

Best regards,

Randy

RandyB

Here are the instructions I promised previously:

http://downloads.d-tools.com/si5/reports/Docs/Add_Calculated_Data.htm

- Randy

fryeguy

Thanks Randy. We look forward to this fix. It will be a good time saver!