Overstated costs on the Service Management Contract Analysis Report

The Maxwell Systems Management Suite (MSMS) Service Management Contract Analysis Report can be useful, but recently, in trying to reconcile service revenue and costs, I ran into a problem where the Contract Analysis Report was reporting actual costs twice, once as a current contract cost, and once as a historical contract cost.

The problem happens when you have current costs that are processed for a Work Order that is regarded as belonging to a historical contract. Here’s the particulars–first there’s a contract that expired December 31, 2008, and was renewed. Then Contract Closeout established the “current contract record” expiring December 31, 2009. And finally, a Work Order was created December 15, 2008, but the work was not completed and billed until January 2009. It is this Work Order that causes the confusion for the Contract Analysis Report.

In January 2009, the work on the December 15, 2008 Work Order was performed, and was billed. The Ticket Invoice Journal correctly updated the costs to the Historical Contract File, and also updated the Customer Contract Monthly Cost File for January 2009. But, the Contract Analysis Report adds those January 2009 costs into the Current Contact (the one dated January 1 to December 31, 2009) and it also reports those costs as part of the historical contract data. Thus the costs are overstated.

There is no real solution to this problem except to give each Contract a new number and that’s impractical in most cases.

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.

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.