Tag Archives: MAS 90

Suppressing Duplicate Crystal Labels

For our file folders at the end of the year we would run a Crystal report that would find all the vendors who were issued payments over the year.  These labels would only consist of the vendor name and number (and the fiscal year, but that was handled with a text and parameter field).  However, after a large upgrade our Mas90 install (to version ~4.something), the report would duplicate some vendors, and not print others at all.  Digging into it I discovered that the report was set to use a table that nominally tracked AP vendor payments per period and that in the past this table kept a cumulative total for each vendor over the course of a year.

In the new version though, the new periods were broken out by months, essentially making the table a dupe of the AP check history table in Mas90.  Now when the report was run, a label would be printed for every check issued to a vendor, and as a filter the report left payments out that were less than $100 (which was fine for a whole year, but bad for each month!).

I poked around and after consulting a couple different websites I came up with the following fix:

  • I put the vendor number field into a group
  • I suppressed the group header and footer sections (right click->suppress (no drill down))
  • Went to Report->Selection Formulas->Group
  • Added the following formula : {AP_CheckHistoryHeader.CheckDate}=Minimum ({AP_CheckHistoryHeader.CheckDate},{AP_CheckHistoryHeader.VendorNo})

What the last line does is it only picks out the first date that the vendor appears.  This can still lead to duplicates if the vendor was issued more than one check on that same day, but it’s much better than getting twelve labels for many of the vendors!

(By the way, there might be a better way to do this as I don’t know too much about Mas90, and even less when it comes to Crystal Reports; but I was given the evil eye for mentioning that I could do this up in .Net or, even worse, with an Excel/Word mail merge where the ‘remove duplicates’ function had been used in Excel).

MAS Client Issue

Part of my motivation for patching up the system was so that we would be running a version of MAS 90 that was officially supported on 64bit Windows 7.  An odd issue that’s possibly related to compatibility cropped up today though.

When going into one of our companies, MAS would crash/stop responding when going in to “reprint journals” under the general ledger reports.  It worked for every other company AND even worked for that same company if the report-program was run from a 32 bit system.

The big clue was that the UI for the report never launched after clicking OK for the accounting date, which usually tells me that an ‘output issue’ exists.  After comparing the settings under company maintenance it turned out that the one that didn’t work didn’t have “Use Workstation Default Printer for STANDARD Report Setting” or “Form Code” checked.  After checking those two boxes and accepting the changes “reprint journals” began working for 64 bit systems.

MAS 90 Patch Issue

I recently decided to be brave and install a hotfix rollup/service pack to our MAS 90 4.3 install.  I believe we were on patch 3 and I would be installing patch 20.  My goal was to clear up some oddball Windows 7 issues that we were having (the exact nature of which I cannot recall unfortunately).

After installing the patch everything looked okay.  It appeared that the client upgrade was somewhat optional since it only upgraded the help files (though I did it anyway just to be sure), and when opening some of the companies in the database I got an unexpected upgrade notice (unexpected since the system was patched and not upgraded):

For all but one of the companys, getting this “Data files have not been converted for this company” message wasn’t an issue.  However for one of the companies in our database we would receive this error, go through ‘Company Maintenance’ to upgrade it, then receive a message that said that there was nothing to upgrade, but then get the “have not been converted” message again when trying to go into the database.

What was odd was that under ‘Company Maintenance’, the ‘Common Information’ module for the company was listed as version “4.09” (which so far as I know, wasn’t even a production release version of MAS 90).  Every other module in every other company was listed as “4.30”.  I am unsure as to how MAS works in the background, but when I looked at the files through a hex editor it did appear that they reporting that they were version “4.09” (however in hindsight it would appear that this value was ‘pushed in’ rather than ‘pulled out’ of the tables).  Ordinarily it would probably be worth restoring the data and trying to figure out what went wrong, but for reasons I’ll not get into the application had already been used for more than two weeks (outside of that company of course).

As luck would have it, I needed to perform some operating system tests a couple weeks earlier and had a test copy of the virtual server that hosts our MAS installation and the data was from before the upgrade.  I tried copying the tables over and a couple other little things, but after nothing worked out I decided to try and upgrade the test copy of the database to see why the upgrade to that company failed, only…it didn’t.  It worked fine.  I then copied over that copy of the company over to the production MAS.

What happened next was rather odd, but MAS is a bit of an odd product.  The version number was still reported as “4.09”, but in poking around I opened the ‘Copy’ utility under ‘Company Maintenance’ with the thought that I would copy another company’s ‘Common Information’ set over to see if the version stayed the same.  I thought better of it again (this wasn’t the first time I mulled it over) and I canceled out and then for whatever reason the version number for ‘Common Information’ was properly reported and the upgrade error went away.