Sage 100

I am trying to update an IM_ItemCost UDF in an existing lot tier using VI. The VI job won't write out the UDF value because I get the message ""The record is not in an editable state"". I'm not trying to manipulate cost, quantity, date - or anything vital to the integrity of the Lot tier record. I just want to add some additional information to the Lot Tier in a UDF. HELP!

First thought - is the record open by something else that results in an uneditable state?

No, the records are not open. I am doing this first in a test company so no one else is in this company doing anything.

What version? I was just able to do this successfully on a 4.4.08 JobOps 4.4R3 (which was what I had with lot/serial UDFs).

4.40.10 regular MAS

@PhilMcIntosh can you export your Custom Office and email that to me, along with your exported VI job? I would like to see what is different.

here they are

Note that the UDF called cure date is not really a date, just 4 character field normally used as YYMM

Thanks for your help Phil. My problem ended up being that the VI job wants to zero fill the Group Sort field - I am assigning that from the Lot Number in my source file, and when the lot number is pure-numercis it's zero-filling the Group Sort value and therefore not finding a match and treating it like a new entry. Ugh.

Is there a way for me to modify the VI dictionary so that the IM_Item Cost, Group Sort field will not try to zero-fill?

Can you create a formula that will pad it with spaces before importing?

@PhilMcIntosh Were the lot numbers in your source file alpha or numeric?

alpha

That is why it worked for you. Try it with only numeric lot numbers and see what happens.

confirmed - I did it with a mix and the alpha lot number records worked and the numeric ones failed

Phil, Try the @pad formula on a temp field to see if that works.

Set temp field to read the group sort column in the data, then set group sort to PAD(Temp001$,16,"" ""), and get error: the groupsort field is required.

There just is no workaround. I had tried the pad logic too. I just got off the phone with Sage and my case is being escalated. Does anyone out there know how to modify the VI dictionary so that this field won't get zero filled??

I meant to add that you can't use the pad logic because the actual field in the data file is not zero filled.

This is one of several IM_ItemCost dictionary issues related to Lot/Serial in 4.4 that's resolved in 4.5 Basically in the dictionary GroupSort field is associated with a data class called CHARNUM and that is what zero-fills numbers (as well as ALPHANUM and MASTERNUM). You want to disassociate CHARNUM. Here's how you can via DFDM (see attached).

This worked perfectly, thanks so much @AlnoorCassim!

@AlnoorCassim - can something similar be done to allow for VI to update the average cost field in the itemwarehouse file? I have a customer with about 50 records with negative average cost, hoping to avoid DFDM drudgery.

Phil - Since no part of the key is changing with AverageCost yes definitely. Just follow same sequence of steps above but do it for IM_ItemWarehouse to figure out which record in DDE to DFDM modify.

Thanks!

You should really run the utility to fix average cost: IM_AverageCost_utl.m4p and then run the Recalculate Item History task.

The last time I ran that for a customer it actually made things worse. Also, these are not average cost valuation items, which is only what is processed by that utility, I think.

i've only had success with that utility, and I believe it does recalculate average cost for all items.

It fixed about half of them...

@AlnoorCassim, can that logic be used to fix this issue with the PO Vendor Price Level file in 4.5? I'm trying to import some edits to that file but am getting ""the record is not in an editable state"" - although it ""tests"" fine. Issue is happening on the client's system and my local system.

Brett I don't think so but will check. If you're seeing the numeric fields you want to edit with VI But getting this msg I think it means the restriction is in the business object itself (PO Vendor Price Level bus). You can prolly add new records but not edit existing. Will verify.

Thanks, @AlnoorCassim! But actually I appear to have a workaround. I was attempting to populate UDF data in that file for thousands of records but I didn't have the Pricing Type field data - so I just did a File Assign which appeared to work fine upon ""testing"" but not when running the actual import. However, if I include the Pricing Type data, the import works. So I'm doing a VLOOKUP-type function in Excel to look up the vendor #, product line, and item code - to return the pricing type: =INDEX($A$2:$E$44933,MATCH(B2&C2&D2,$B$2:$B$44933&$D$2:$D$44933&$E$2:$E$44933,0),3)