Good afternoon,
 
Our shipping department has reported a problem when running PI-C, though I have noticed that the issue persists in all menus between PI-A and PI-E.
 
The values for the Year field and the Physical Inventory Number field are defaulting to 2021 and 01, respectively as if there was a frozen inventory that needs attention.  When tabbing through past the second field, an error pops up stating 'This is not an existing Physical Inventory number.'
 
Based on my understanding, these ghost cycle counts have plagued us many times, and are usually resolved by ensuring that the BKPIPHYS and BKPIMSTR tables do not have any blank rows (generally via Maintain DB).
 
Unfortunately, this time we have examined these two tables, along with BKICLOC, BKICLOCM, BKICMSTR, BKPIFROZ, BKPILCNT, ISBINLOC, ISBNMSTR and MTICMSTR since they were open in Pervasive when accessing this menu item.  We found no blank entries to delete, and so the issue persists.
 
Just to verify behavior, we checked our other company, and have verified that this behavior of defaulting those two fields is not occurring.
 
Our operations director ran PI-A, C, G and H using these defaulted values, in the hopes that doing so would clear out whatever is responsible for setting the default field values.  After running this, we did note an appropriate entry with those values in BKPIMSTR.  We removed the row, but the issue has unfortunately not gone away.
 
Using lookup in the year field shows an empty table, and any attempt to print or access this inventory number simple returns a "There is no such physical inventory" message.  Generally, once this or the original error message are shown, the current PI application becomes unresponsive and shows the error again with any click.
 
The only progress we have made, is that after the operations director attempted to PI-A, C, G and H, we gained access to the Add/Edit/Delete buttons (which previously were not clickable due to the error).  Trying to delete resulted in the message "ERROR: BKPIFROZ record not found for this part/location!"
 
At this point we are effectively stuck.  Any suggestions?
 
Thank you and best regards,
Beau

Quote from prophet on 08/20/21 at 11:52:12:

 
Yes, that is our expectation.  It normally defaults when there is a PI already in process, but there are none and the fields should be blank.
 
This is in EVO.  We are on 2019.1 currently.  It certainly is strange.  In the past when something like this has happened we've been able to clear it out through BKPIMSTR, but no dice this time.  I just created a test company mirroring the existing company where this is occurring and will continue to dig through the various tables that are opened when accessing PI-C, etc. in hopes of finding something we missed, but for now we haven't been able to get rid of it.
 
Regards,
Beau

Have you tried reindexing the BKPIMSTR file?

if the file is completely blank because it was re-initialized then the in PI-C would default to 2021 01 and you will get the This is not an existing Physical Inventory number.' message. But you shouldn't be in PI-C or any other PI program other than PI-A if the BKPIMSTR has been initialized. Thats a big no-no. P.S. that came directly from the programmers.  So to sum it up if nothing is in that file it will display the 2021 01 by default not be blank, thats just how the program is. That being said, now if you do have the BKPIMSTR file populated then it should default to the most recent PI if it doesn't the re-indexing should fix it.