Making the Bill To address fit in a window envelope with Maxwell Systems Management Suite Invoice Printing

Maxwell Systems Management Suite offers the ability to print invoices on plain paper, but it is possible the Bill To address will not appear in the proper position when that invoice is stuffed into a #9 business window envelope.

Typically, on a #9 business window envelope, the window starts 7/8ths of an inch from the left side. But with Maxwell’s plain paper invoices such as Job Billing T&M Invoices, Service Ticket Invoices, and Service Contract Invoices, the Bill To information starts printing at about 5/8ths of an inch from the left side, causing the Bill To address to be obscured behind the left side of the envelope.

To overcome this problem, a change needs to be made to the X_BILL_TO variable in the print program for each type of invoice printing. Setting X_BILL_TO a value of 7.5 moves the print right about 1/2 of an inch and that solves the problem

If need to resolve this problem, don’t hesitate to contact me for the program changes.

HIRE Act Processing Guidelines for Maxwell Management Suite

With the introduction of the new Hiring Incentives to Restore Employment (HIRE) Act, employers are eligible for a payroll tax credit if eligible employees are hired during February 3 to December 31, 2010. The credit is 6.2% of FICA taxable wages, meaning the employer receives a credit of the employer portion of the FICA for those employees.

To institute this change in Maxwell Systems Management Suite (MSMS) entails setting up a new Fringe in Fringe/Deduction Maintenance, adding a new Calculation Method in Calculation Method Maintenance, and then assigning that new Fringe to the applicable employee(s).

Note that any changes to 941 or W-2 reporting have not been described by the IRS, and if required may necessitate a software update later this year.

Formatting Management Suite Dates for Microsoft Word Mail Merge

Maxwell Systems Management Suite (MSMS) has the ability to use “templates” to create documents, such as a Subcontract, via Microsoft Word mail merge. But when a date is required in the output, Maxwell exports that date as a string in the format of YYYYYMMDD (today would be 20091230), and unfortunately, Microsoft Word doesn’t see that as a date, and doesn’t allow you to format the date in the document correctly.

After doing a little detective work, I found that I could change the date format of the data Maxwell exports to Word. By changing the Date Format so that the date was exported as 12/30/2009, Word then allowed the date to be formatted correctly. Ultimately I had to add this line of code to CSCWMA to make the dates display properly in the merge document:

29701 LET CSCON2$[7]="04" ! force Date Format 04 MM/DD/YY for better mail merge dates

With this fix in place, in the Microsoft Word ‘template’ document, the date can be formatted in a number of ways including something like this:

{MERGEFIELD "SB1_Contract_Date" \@"MMMM d, yyyy"}

That would make the date appear as December 30, 2009.

Limiting display of Maxwell Office Manager Reminders

The Maxwell Systems Management Suite (MSMS) has the ability to remind users, when they login, about Office Manager Events that are open and past their “due” date. But because it can be cumbersome to mark those events as Closed, many users just neglect changing the status of those events. The result of that neglect means that the Office Manager Event Reminder screen is filled with too many older events, so the users just ignore that screen.

To overcome that problem, a change can be made to the CEVLI0 program that will only display a Open Events that are just recently due. For example this change causes the Office Manager Events Reminder to only display the last seven days, today and the six days prior, of Events that need to be addressed. Here is the change for CEVLI0:

45119 LET FIRST_DAY_OLD=6,FIRST_ACTIVITY_DATE$=DTE(FN%DTN(ACTIVITY_DATE$,"YYYYMMDD")-FIRST_DAY_OLD:"YYYYMMDD") ! determine oldest date to display, set FIRST_DAY_OLD=0 to display just today's activities
45120 SELECT CEVTR${ALL} FROM CEVTR,KNO=6 BEGIN "O"+FIRST_ACTIVITY_DATE$ END "O"+ACTIVITY_DATE$+$FE$

Reporting number of employees for Maryland Unemployment with Maxwell Systems Management Suite

As part of the quarterly payroll reporting, the state of Maryland requires employers to file the Maryland Quarterly Unemployment Insurance Contribution/Employment Report (DLLR / OUI 15) with a count of employees working on the 12th day of each month in the quarter. Specifically, line 20 of that report requires employers to

Enter the number of full-time and part-time workers (subject to the Maryland Unemployment Insurance Law) who worked during or received pay for any part of any payroll period which includes the 12th of the month.

But, the Maxwell Systems Management Suite (MSMS) State Unemployment Report does not provide the count of employees, so here’s how to gather that information.

The trick to getting the employees that worked on the 12th day of any month is to print the YTD Detail Payroll Register for the check date range that includes the 12th of each month. For example, for January 2009, figure out what check date include the pay for January 12th, then run the YTD Detail Payroll Register and use that check date as the beginning and ending check date.

Now for the hard part — print the report to the screen, then count how many employees are printed on the report. That’s the number to use when completing line 20 of the Maryland Quarterly Unemployment Insurance Contribution/Employment Report.

Another possible solution is to create a Payroll Formatted Report using Prefix PR7, define a Formatter Field called Counter with the definition simply as 1 (just the number 1), then print that report, for the date range that include the 12th day of pay for each month, and look at the total of the counter field at the end of the report.

Either way, to determine the information needed by Maryland requires printing a report for each month that includes that 12th day.

Reporting service call volume with Maxwell Systems Management Suite

The Maxwell Systems Management Suite (MSMS) Service Management Systems records all the service calls made by customers. Recently, someone wanted to track a customer activity to determine if a service technician had not visit a site in the last 60 days. Unfortunately, there is no reporting mechanism that would allow that kind of analysis.

But, with the use of the Formatted Report ability in MSMS, you can at least see all the calls that were made to customer site in the last 60 days. I know, not the same as seeing sites NOT visited in the last 60 days, but still useful.

The trick is using an Advanced Filter that only reports those calls marked as completed in the last 60 days. For this example, use the Formatted Report Prefix SPB and create a filter called Date Completed, and under the Advanced tab, add this filter:

NOT(NUL(DATE_COMPLETED$)) AND 
JUL(NUM(MID(X$,37,2)),NUM(MID(X$,31,2)),NUM(MID(X$,34,2))) - 
JUL(NUM(MID(DATE_COMPLETED$,3,2)),NUM(MID(DATE_COMPLETED$,5,2)),
NUM(MID(DATE_COMPLETED$,7,2))) < 60

Essentially that says, if the Date Completed field is not empty AND the Terminal Date minus the Date Completed is less than 60 days, include the Work Order on the report. Note the JUL function is used to convert the two dates to a Julian date so the dates can be subtracted from each other.

Not the cleanest method of analyzing call history, but certainly this method gives a service manager a meaningful tool to determine if a customer’s needs are being addressed.

Limits to where PDF files can be printed and stored

Some people try to be true to the whole “paperless” society concept by printing all reports to PDF. But, a problem can arise if the path and filename for that PDF exceeds too many digits.

A customer was trying to print an Open Accounts Payable Report to PDF and used the following Path/Filename: “F:\Mxw\PDF\Jason Builders and Service, Inc\Accounts Payable\2009\20090430\Open Accounts Payable Report.pdf” but kept getting a message that the file did not have an extension. It’s clear that .pdf is the extension.

After a bit of playing around, we changed the name of the folder “Jason Builders and Service, Inc” to just Jason, and sure enough the PDF successfully was created and saved.

So the moral of the story is, “keep the Path/Filename combination of PDFs to fewer than 100 characters”.

How to set the Aged AR Trial Balance default Aging Date

It’s always a pain to have to change the Default Aging Date field when printing the AR Aged Trial Balance by Job report. It’s an easy program change, but the Maxwell Management Suite requires adding a line of code to the standard CARRE0 program that prints that report. Here’s that line of code:

10041 IF X$(41,2)+X$(37,2)+X$(31,2)=FISCAL_YR.VAL$+FISCAL_PD.VAL$ 
THEN LET AGING_DATE.VAL$=X$(41,2)+X$(37,2)+X$(31,2)+X$(34,2)

This change will set the Default Aging Date to the current terminal date, only if the current terminal date is in the Period and Fiscal Year ending date selected for the report.

Reporting Actual Service Hours via SPD and SPI Prefixes

When trying to reconcile Actual Payroll Hours posted to Service Work Orders, Maxwell Management Suite software offers two Formatted Report Prefixes, SPD (History/Billed Tickets), and SPI (Current/Unbilled Tickets), that give you access to the Actual Payroll Hours spent on Work Orders.

The problem is field (F035) in the SPD/SPI Prefixes is called Actual Quantity/Hours, meaning Actual Hours shares the field with Actual Quantity. Actual Quantity is the quantity of material items used on that Work Order, for example, from an Inventory Material Requisition. So the question is, “How do you separate Actual Hours from Actual Quantity when trying to analyze Payroll hours?” Here are several solutions.

Using the Unit of Measure Field to determine if it is a Payroll transaction

The first method I used to isolate the Hours from the Quantity involved using the Unit of Measure (F023), which assmes all Payroll transactions have a Unit of Measure of “HR” (hours). I created a Formatter Field (F500) and tried to use this definition:

F035;IF F023="HR" THEN X7$="0"

Unfortunately, the program kept reporting a syntax error with that equation. A little detective work found the ‘code parser’ was converting the F023 into an invalid variable “J(-6)” and testing that numeric variable against a character string. The parser didn’t seem to like the “F023”. Here’s what Formatter Field Maintenance reported as the incorrect parsed code:

LET A=J(6);IF J(-6)="HR" THEN X7$="0"

So, remembering back to old days, found that Maxwell still kept a string array U$, where each element contained that particular field value (e.g. U$[23] is the Unit of Measure). So using that array allowed for a successful field definition. Essentially, the definition says, “assign the Actual Quantity/Hours (F035) to our variable, but if Unit of Measure (U$[23]) is NOT “HR” then zero out our variable (Actual Hours).” Note that X7$ is the current field. Here’s the completed definition that worked:

F035;IF U$[23]<>"HR" THEN X7$="0"

Using the Source Code Field to determine if it is a Payroll transaction

The problem with using the Unit of Measure field is that it is not completely accurate. Meaning, a Work Order could also contain subcontract hours that use the Unit of Measure of “HR”. The only other accessible field that signifies a Payroll cost, is the Ticket Actual Cost Source Field (F049). When the Payroll Journal posts the Actual Cost transactions to Service, it uses a “1” representing the Payroll Journal, plus the Journal Date, plus the Report ID, to form the Ticket Actual Cost Source Field. So the solution was to use the first digit of the field to find out if the transaction originated in Payroll. Here’s the definition that worked, and proved more accurate than using the Unit of Measure field:

F035; IF MID(U$[49],1,1)<>"1" THEN X7$="0"

One other note: With Version 6.5.3 of Maxwell Management Suite, the Formatter Field specification for Actual Quantity/Hours (F035) is only defined for a field length of 11, but is stated to be a length of 15 in the Data Dictionary. To make the above examples work, the “SPD 035” and “SPI 035” records in CSCOD and CSCFF need to be corrected to reflect the correct field length.