Sage 100

we have a client on version 2013. suddenly they can't print the accounts payable invoice payment selection listing (the report you print out after selecting invoices for payment) they get the attached error referencing and error in a formula. when we open the crystal report ""AP_InvoicePaymentSelectionListing.rpt"" if we verify database we get a crystal reports error with Vendor Code:133 (attached). this is the only table we get the error on, I've tried replacing the crystal report, manually reinitializing the table AP_InvoicePaymentListingWrk At this point, I'm basically out of ideas on how to fix this. since it is 2013 I can't call Sage Support.

Can they clear and re-select? We have also had some error similar to this when we had a bad date in the invoice file - had to do DFDM and fix it.

This is an excerpt from a Sage knowledgebase article. Verify there are no values in the Session ID field of the SOTAMAS90 User DSN 1.Open the 32-bit ODBC Data Source Administrator: ODBCAD32.EXE (In Windows Explorer, explore ""C:\Windows\System32"" in 32-bit Windows operating systems, or explore ""C:\Windows\SysWOW64"" in 64-bit operating systems, to locate the ODBCAD32.exe program) 2.Select the SOTAMAS90 Data Source (User DSN) and click Configure 3.Select the Logon tab 4.Verify that all fields are blank. The SOTAMAS90 DSN should not have any values in those fields.

Does the work table actually exist in the AP### company directory with the proper permissions?

We have cleared and reselected a single invoice. I should note that this is happening across multiple company codes. yes the table does exist. This is an advanced install and they are using CSODBC Service. I looked and there is nothing in the User DSN on the logon tab

Do all the AP Divisions have a valid description? Any changes to ODBC security? Maybe turn ODBC Security off and back on again?

Have you restarted the CSODBC service?

We have restarted the CSODBC service. This is so oddly random! worked fine yesterday. We have not rebooted the server, but that is happening tonight. hopefully that will be the magical solution.

Can you see the field in the table while in Crystal?

@MichelleTaylor1 - if I don't try to verify database the fields show on the database explorer tab. If we refresh or verify database we get the Vendor Code: 133 error.

Can you see the wrk file in Windows, or DFDM? Does Windows create the temporary wrk file when the report is being printed - AP_InvoicePaymentListingWrkUSERDATETIME.m4t? Wondering is the file doesn't exist, that field has been remove from the table/file (can't fathom how), or if there is a corrupt vendor record.

Sounds like bad data in a date field. You indicated above that it works when selecting ONE invoice. Do your aging or TB reports work? Try dumping the open invoice table data into Excel via query. That might fail as well. If it does, then dump the date fields via VI Export into a CSV file. Then open in Excel and search for a bad date field (s).

I may not have been clear when we select a single invoice that was to test and it did fail even on one invoice. the work file is created (the one with the user code/date added) and we can use DFDM to look at the data and it seems to look ok but we still get the crystal errors

Doesn't CSODBC cache the reports on the local workstation? Maybe there is an old version floating around with the invalid field?

@GregStiles - Great thought. I was just reading about that last week. Now if I could only remember where. Here it is. Not quite what I saw earlier but maybe helpful. For Sage 100 Advanced, reports are cached in the following client workstation hidden folder: **C:\ProgramData\Sage Software\Cache\MAS 200\Reports**

If it is not the cached local RPT as Greg and Jeff mentioned, it could be dictionary is off for this table OR dict is correct but the physical file needs to be updated because it's not matching the dict. One way to do that is switch into test company first (where I presume issue still occurs), File / Run / SYZCON and at prompt type the following: ` tablename$=""AP_InvoicePaymentListingWrk"" ` ` CALL ""*dict/dd_updt;Update_Physical"",tablename$,$$,$$,error$ ` ` print error$ ` If it worked successfully then error$ will be blank. Now trying the listing. If it works, switch into live company, and re-reun. Also as an alternative to this method, in past I've mentioned doing this below as resolution for other issues. It does above commands for you but updates every A/P table and thus requires everyone to be out of A/P. ` o = new(""SY_Activation_bus"", %sys_ss) ` ` print o'Activate(""A/P"",""ABC"") ! substitute ABC with your company ` If successful it will return a 1

@AlnoorCassim I think your onto something. First I tried running the ""Call ""*dict/dd_updt;Update_Physical"" and the error is NOT blank. I get: PHYSICAL UPDATE ABORT: APInvoicePaymentListingwrk - File path <> is blank then I tried running the SY_Actiation_bus and it did not correct the error. I have a feeling that the problem is in the dictionary and not the physical file. is there a way to update or correct the Dictionary? for this table?

David - If you guys are still doing the M/D thing, then yes with Nomads. Otherwise reinstall A/P module and the product update and any related mods.

Yes we are still M/D. I guess I could make a quick install file to put that table back in. Thanks for all your help!

Couldn't you restore the DD files from backup?

Maybe, are they the SY0DDx (2,3,4) files in the SOA directory?

I'm not sure exactly where business framework DD's are located. Alnoor Cassim might know what file(s) to restore..

I asked our M/D and he thought the SY0DDx sounded right, but get confirmation. Possibly easier than reinstalled a module. Could it be possible one of those files are missing?

No it's DDE and DDF but I don't recommend restoring those if you think new UDFs and such may have been added since then to dict (But could always go back to UDF Maintenance and re-update it). Up to you. I would just use Data Dict Maint in Nomads. You could alternatively DFDM DDF and search by the alternate key for the name. It sounds like problem is the path expression is missing or altered. You could copy that from another table then change the table name, then do the Update Physical again

Thanks @AlnoorCassim that was an easy fix with your guidance! for the group, I used DFDM to look at the record in the providex.ddf table. found the record for the AP_InvoicePaymentListingWrk.m4t I could see that field #2 where the path should be was blank. it was actually numeric for some reason, and I had to change it to alpha (prompted when I edited it). I could see the other records had a path that translates to the populated work table so I copied the text in field #2 from another record, changed the table name within the string and PRESTO, life is good again for my client. they can process checks again. before and after screenshots of the DFDM are attached if anyone is curious.