Supplier Schedule Price maintained in 5.7

[Chris Kelleher]

Please reply to pkiefer@lweng.com

MFG/PRO V8.6D

I have found an issue with QAD PO pricing that is stated in Solution Publisher ID #1.0.17531506.2392676.

In a nutshell, if you create a supplier schedule (5.5.1.13), but "inadvertently" maintain the line item price using 5.7 (I had a user do a lot of these), the PO price must always be maintained using 5.7. Once you maintain the price in 5.7 for a supplier schedule, any change you make in 5.5.1.13 is not used when parts are received even though the maintenance screen appears correct.

Based on QAD's solution publisher, the fix is "Sorry Buddy - Do it once in 5.7, do it always in 5.7".

I have poked around the database and it appears that something is being written to field pod_qad__09 when you set the price in 5.7. I have tried resetting this field to null and got some mixed results - there must be more to the fix.

Does anybody know a good way to recover from this problem so that we can start using 5.5.1.13 to maintain our prices on supplier schedules. Right now, QAD is standing by the fix that is stated in the solution publisher.

Thanks for any help.

Paul Kiefer
L&W Engineering Company

 

[Chris Kelleher]

Hi,

We faced this exact problem few days back...

The problem occurs because of this situation:
a) A Scheduled PO is created using 5.5.1.13 and a Line Item is entered with PO
cost and other details. During this entry, only the PO cost field(pod_pur_cost)
is updated. Lets say the cost is $1.00.
The values that are stored in the following fields:
pod_pur_cost = 1.00
pod__qad09 = ?
pod__qad02 = ?.
b) Now, the cost needs to be changed. Instead of using the screen 5.5.1.13, the
PO maintenance 5.7 is used to change the cost. When the cost is changed using
this screen, it not only updates the PO Cost field but also the additional QAD
fields.
Now, the values that are stored in the following fields:
pod_pur_cost = 2.00
pod__qad09 = "2" (integer value of the cost stored in character format)
pod__qad02 = "0" (decimal value of the cost stored in character format).
c) A receipt is made against the PO and the transaction registers the cost as $2
which is correct.
d) Now, the cost is again changed. But this time, it is changed using the screen
5.5.1.13. The cost is changed back from $2 to $1. (the program updates the cost
field but ignores the two QAD fields).
Now, the values that are stored in the following fields:
pod_pur_cost = 1.00
pod__qad09 = "2" (integer value of the cost stored in character format)
pod__qad02 = "0" (decimal value of the cost stored in character format).
e) A second receipt is made against the PO. This time, transaction registers the
cost as $2 instead of $1 which is incorrect. This is because of those two
fields. the receiver program initially takes the PO cost and then reads these
two fields and if the values stored in these fields are different from the
actual cost, the transaction is created using the cost from these two fields.
This affects the costing, ledger...everything!!

We fixed the issue for the existing POs by doing the following:
f) wrote a query to extract all the POs which has different values in the cost
field and the two QAD fields (pod__qad09 and pod__qad02). The extracted file
contains the PO Number, the Line Item and the correct value of the Cost.
g) Then, went to the PO maintenance screen and opened each PO and changed the
cost of the affected line items to $0.00. this in turn automatically updated the
value of the two QAD fields to "0".
h) then, went to the 5.5.1.13 screen, recalled that PO and the line item and
entered the correct PO cost. And the cost is updated into the PO cost field, but
the two QAD fields remained 0.
i) Now, when a receipt is made against the PO, the transaction posts the cost
from the PO cost field and ignores the two QAD fields.

We can't say that the problem has been solved permanently. The users might
repeat the same mistake again. But we had given them a clear documentation of
the issues and asked them to use the 5.5.1.13 screen (and not 5.7) to do any
changes for the Scheduled Orders.

HTH,

Vittal PR

 

[Chris Kelleher]

Hi;
Thanks for the explanation from Vittal PR. We noticed in our environment
(Mfg/Pro 8.5G) that values in pod__qad02 under 50 cents are stored as
positive values, whereas values above are stored as negative values.
E.G.
pod_pur_cost pod__qad09 pod__qad02

2.40 2 4000
2.70 3 -3000

My question then is, can anybody shed any light as to why this method is
utilized? What are the advantages? The disadvantages seem to be obvious.
Thanks in advance.