Sage 100

After installing the 2012 941 on a 4.40.0.6 MAS 90 installation, client is unable to print 941. Receiving error: 941A.rpt:Failed to retrieve data from the database. Details:[Database Vendor Code: 1021}. When I tried to verify the data base in Crystal, there is an unknown for field in a formula, PR_33Crystal941.TaxDueOnUnreportedTips. I installed the update on a 4.40.0.6 system at our office and did not get this error, but got different error: Unable to locate Report file: .......###-###/PR941A.rpt. I copied the report for the Reports folder into the ###-### folder and this resolved the problem, but this did not work on the client's system. Any ideas?

Did you also rename the two rpt files? See http://goo.gl/l7t2j for instructions

Yes, I renamed all instances of these two rpt files in the Reports and ###-*** folders.

What does - database - verify database do ?

From your \MAS90\DDICTS folder copy the PR*.DD files into client's system (rename their files) and try again.

Did you try re-initializing the PR_33Crystal941 file? From this error description, it sounds like that field may be missing from the file. Since it is a Crystal Work file, re-initializing it should not hurt (make a backup, of course).

Wayne, after verifying database, I get the unknown field in formula message and then cannot save the file. I will try Alnoor and Chuck's suggestions, one at a time and see if I can get this figured out. Thanks all.

Alnoor's suggestion is the correct one as the data dictionaries the report is built on is not correct.

I thought it was because he is Alnoor?

Did the client have any UDF's in PR? If so, you need to update those UDF in user defined field and table maintenance. I always forget to do this for couple clients with PR udf's

Alnoor's suggestion worked. And there were no UDFs. Thanks all!

Of course it worked - looks like today is the day to ask questions - he seems to really be paying attention to everyone today! He's got answers all over the place.

Also today I did this update for the 941 on a 4.4.0.7 MAS90 and although I though the ###-### was supposed to be populated with 941a and 941p rpt files - it was not. I wound up copy/pasting them from \reports into the ###-###. This is an FYI only added in case someone is having issues with the 941 patch and stumbles across this message thread.

Actually, Wayne, if you simply rename (never delete) the files where they occur in ALL of the sub-directories (including the ###-###), the next time you run the Quarterly Reports the system will grab the ones from the ""Reports"" main folder. If you modify them at all, the system will drop the modified version into the specific company you are working in at the time.

I think that's what I did (renamed) and found that the reports did not get dropped into the ###-###. I cannot rule out that the customer somehow deleted a file however I logged back in and re-ran the 2012 941 after renaming the 941a and 941p in the ###-### and observed in my situation the files did not populate ###-### again which I thought they would.

I've seen that lately myself. The ###-### folder does not have the 941 reports. I also ran into a situation last week where the that folder only had the 941p template, not both. User encountered and error message that ###-### was missing the 941a report. When it finally dawned on me where to look, I deleted the 941p report and both reports copied properly to ###-xxx folder. Funky!

I'm not surprised, Jeff & Wayne. And, since Sage is moving away from the old ""Report"" folder with the Framework Modules, I don't think that they'll even address this. There is certainly no harm in copying those files into ###-###. I've only had to do that on a couple of occasions and always chalked it up to ""network issues.

Lol @ChuckPeddy! Sure, always blame it on the network!

UPDATE: I believe the reason for the initial error is due to installing the 941 update into MAS when people are in the system. I just had a customer where I could not get in touch with anyone to exit MAS and tried installing the 941. It will install but I immediately received the OP reported error message which I believe is a symptom of Sage trying to complete the install but not being able to update some ""in use"" files.

UPDATE: Reinstall of the 941 patch does NOT appear to fix the above message. This is all a WAG on what causes the problem. YMMV.

Copies of 4.40.4.7 PR*.DD

This is the responce I received from Sage as to why the PR DDICTS were incompatible with the 2012 941 Update. ""Where we see this error occuring is when the DDICTS files did not get updated with the 2011 941 Update. Therefore a recommended resolution would be to re-install the 2011 941 update then install the 2012 941 update and rename the files in the ###-### and ##-xxx folders.

That may be the actual reason for the DD issue. Unfortunately I am unaware of any realistic way Sage have provided to tell whether all the iRD have been loaded.

I totally agree. Does the 2012 941 Update, update the DDs?

I did not notice a date change on the DD files -- and the dates on my 4.4 that barfed had different (older) dates - which makes me think the issue may indeed be that a prior IRD was not applied. Now why Sage couldn't build in the logic to check the DD on subsequent IRD applications is beyond me.

I agree. Figuring out what has been installed and hasn't is a PITA especially for those self administered clients. They don't want to pay you to do it quickly and efficiently but you have no way of determining whether they took the right pill................

Again, I totally agree with you take on the logic to check the DD. It seems that Sage has gotten sloppy.

I believe my customer today had installed prior IRD since they always call to ask to have them done. Unfortunately there's really no great way of telling other than following a complex set of long winded nstructions to check to see if fields are in certain places.