ICWHSE record - Cost fields - extra pad appears

What I know -
Item was created on 01-28-18
PO receipt occurred on 02-02-18
ICWHSE record was padded on 02-02-18 with the following

Field 6 had 4 fields, when it should have had 3.

As found
BLANK 18.670 18.670 .000
Should have been

18.670 18.670 18.670

These were also visibly wrong in ICWHSE F/M as
Standard = BLANK
Average = 18.670
Last = "18.670 .000" (without the quotes)

You may ask, how do you know the condition happened on 02-02.
We run MITS report which does an ODBC call nightly and we know that it worked on 02-01.
We know that it broke on 02-02.

Running a data integrity tool identified the offending records.

FACTS 7.8.x

We know that this does not happen all of the time. We are trying to identify the condition under which this occurs.

Any insight is appreciated.

Find more posts tagged with

Comments

Legacy Contributor

Marty,

I have seen this at only one of our 7.9.2 clients as well. I have only had to correct this a couple of times & have never tied to track down the cause.

mcohen

It has been suggested to me that this is not 4 fields, but rather 3 fields as follows -

16 + 9 +9

The 16 coming from PORPOL.

This obviously does not happen often so I am trying to isolate the uniqueness of the items in question.

It is nice to know that others have seen this as well.

Thank you Jim and Bill for contributing to this question.

Customer also added

Item #WIDGET

Special Order Item

PO #aaaaaa / Vendor bbb

1st Item listed on PO / All other items appear to be Stock items

No other items on PO are tied to a sales order

PO Flag shows “SND!” (I’m not sure what this is)

Tied to S/O xxxxxx / Invoice yyyyyy / DSR zzzz

Customer 1275

I will update as soon as we figure something out.

Legacy Contributor

Marty,

Sequoia Group just moved a system to FACTS 9.1 this past weekend and their bad ICWHSE records caused errors in their background processes (for the curious, it was err 26, line 7165 of CSREPLENP.pvc).

In checking our other installations from 7.8 forward, I found only one other system with bad records. This does not seem to be very widespread.

Checking back to the previous 7.9 data for the recently upgraded system, I was able to backtrace at least one source for the bad records. Here are the steps to reproduce:

FACTS 7.9

SOE110 - Quote Entry (I believe OE will work as well)

Enter header fields

Select Add Line

At Item prompt of the new line, enter an item that will not be found on file

On Temporary Item dialogue, Click "QuickAdd"

Enter a Default Item, Click OK

Click Exit

Click Cancel

--> you should now have a brand new bad ICWHSE records

I have not gone farther to build a fix or see which versions are affected by this problem. Since this discussion is fresh, I figured getting the steps to reproduce out would be useful.

Chris Kukuchka

Sequoia Group, Inc.

Legacy Contributor

Marty,

FACTS 9.1 does not have this problem because it is properly handling the Cancel form QuickAdd function. It does, however, still have the same underlying issue that is causing the record to be written as FACTS 7.9.

This code fixes the underlying issue:

ICF070:

before

21540 mc$=fnman_cost$(f.manual_cost$,f.man_cost_basis$,f.man_cost_mult$,f.list_price$,icstat.cost_mask$,pc,cc)

after

21540 mc$=fnman_cost$(mid(f.manual_cost$,-9),f.man_cost_basis$,f.man_cost_mult$,f.list_price$,icstat.cost_mask$,pc,cc)

The other part of the fix is to not leave records behind when QuickAdd is cancelled. FACTS 9.1 does that properly, but it still has a time (while in ICF070) when it has bad records in ICWHSE.

Chris Kukuchka

Sequoia Group, Inc.

mcohen

Thank you Chris,

I am thinking that you may have identified a different but equally as bad issue.

In my case, the Item was created and a PO generated. The time between the create 01-26 and the time of the receive of the PO (02-02) the ICWHSE record was just fine. I know this because we do ODBC calls to the file 5 days a week, and it became broken on 02-02. So I don't think the cancel in the Quick Item add was the source, now could there be a condition in the PO Receipt process that involves a cancel... hmmm

Legacy Contributor

Marty,

Keep in mind this results in valid data for ODBC:

c8$=dim(9)+dim(9)+pad(".000",16,0)

That is how the record looked in my tests coming out of QuickAdd. ODBC is fine with the extra long data field since last_cost is a field end. Basically, ODBC treats the field the same as doing this:

print num(mid(c8$,19))

The data becomes a problem after something like this is done:

c8$(19,9)=pad("18.670",9,0)

That is the form I saw when we encountered the error in CSREPLENP.pvc.

From your description, I am not 100% clear exactly the character positions of your bad data. However, seeing the dangling .000 makes me think the problem may be similar. If your character positions do not match with 9+9+9+7, then most likely your issue is unrelated.

If you have the option of looking at the data by restoring a backup from before the Feb 02 receiving, you may be able to narrow down whether the problem event coincides with the time of PO receipt or if you were setup for the error from a previous event.

Chris Kukuchka

Sequoia Group, Inc.

Copyright © 2025 Infor. All rights reserved.