Sage 100

error 81 invalid IOList specification Line 539 - during AP_Manual check register update or AP Invoice Register. Last file name is AP_Vendor.lck. MAS 200 4.5 SQL, this company has AP multi-company installed but not turned on and using - have updated company data, DSD conversion utility, and Custom Office AP_Vendor updated. Only happening in one company. Can't find anything too helpful on Sage.

Is it happening on the AP_ManualCheckRegister_upd.pvc program itself?

yes, that's the program, we're checking the rights on the SQL database on the backend - i wonder if that's the issue

not a SQL rights issue, wondering why it's just AP - sems like maybe related to DS multi-company, can preview registers from AR and GL

I get that error sometimes when I add a UDF in one company but then use it in another. It's like the physical file (table) for the current company got updated for current company but not the others. It can also happen with developer fields but easier to try UDF Update route first. IOW within the company you're getting the error try updating UDF Maint not in A/P but in G/L on both GL Daily Posting and GL Daily Transaction Register Work. If you've never added UDFs to these places there may be developer fields that are in the dictionary but not in the physical file.

was able to update the GL Daily posting - nothing int the Gl Daily Trans Reg work. Is there a way to update that even if there aren't any udf's?

try the old activation routine which also updates physical file to dict: o=new(""sy_activation_bus"", %SYS_SS) ? o'Activate(""G/L"",""ABC"") ! replace ABC with your company code

ran that - returned a 1, but no dice

Well I'm guessing you're going to find a AP_ManualCheckRegister_upd in the mas90\Links folder. Normally I would say temporarily rename it and restart the update to see if it finishes. But if this is DSD M/C then because it's pervasive througout many parts of MAS, better to contact DSD. I know you said it's not turned on but it might be used in some capacity anyway.

the table AP_DailyPostingWork was completely missing from the SQL company database - I guess it didn't get created properly during the SQL conversion. Anyway, we were able to copy one over and everything is working now.