Gross Profit Reporting Incorrectly

[integrity1]

We're having an issue that Mitchell's support team just can't seem to figure out, and we need some advice.

The "Invoice Profit Summary" report is incorrectly reporting appropriated labor on multiple jobs each week, with no identifiable pattern or cause. For example, if there is one labor hour on a job, that line correctly reflects 1 hour charged to our customer, one hour assigned to a specific technician, and the gross profit on the job (Check Profit) indicates the correct number of dollars in labor cost associated with that, reflecting the profit on the job correctly.

However, when that job is invoiced out, and the "Invoice Profit Summary" report is run, the labor assigned to the job is exactly 4 times the correct amount, causing the reported profit on that job to plummet, affecting the weekly totals in that report also. Keep in mind, it is a seemingly random occurrence, showing up on different technicians, different types of work, etc.

I unposted one of these anomalies, removed all the parts from the order & reposted it. The invoice profit summary report then reported the labor cost correctly. Unposted it again, re-added the parts on the job, and the labor cost quadrupled again. (??) The parts lines were looked at by support one at a time, and found that they were all setup correctly with the accounting category of "Parts Revenue - Taxable".

VERY frustrating, as we can no longer trust the 2 reports we run so very often & count on....the Invoice Profit Summary Report, and the Business Summary report....it then becomes skewed by the same anomaly.

Any advice or help with this would be REALLY appreciated...we dont know what to do when it comes down to recapping our weeks now besides going back over every invoice. We've had to re-create jobs from scratch (doing nothing differently) in order for it to report correctly.

Please help,

Tina

[ricmorin]

The first thing that comes to my mind is a Service Writer who is setup with a labor commission in the program. If you checked profit while the invoice is open and an SW not yet assigned, it would not reflect those additional amounts. Check all your Service Writers in Technician Setup and make sure none are set to a labor commission.

[integrity1]

...Check all your Service Writers in Technician Setup and make sure none are set to a labor commission.

There's two service writers setup in our system, along with a default SW. None of them have anything bu zeros in the commission boxes, and we've never used that particular function in the past. I checked, though...I was hopeful!

On a sample invoice, I "moved" all the "Pay Hours" from every labor line to a new "test" labor line. It reads the zeros in the actual lines correctly, and multiplies the "test" line labor by 4 in the report.

Whats frustrating is that we'll post 40 or more cars a week (sometimes as high as 60).....and we've only just begun seeing this in the last month or so...and it's random, on only 3 or 4 invoices a week.

[ricmorin]

Weird.

Can you post some screen shots so we can see? That sometimes triggers things in our heads.

[integrity1]

Weird.

Can you post some screen shots so we can see? That sometimes triggers things in our heads.

Of course. Never did this before, hope picture helps....

badreport.jpg (97.97 KiB) Viewed 6504 times

[Silky7]

Tina,

We are looking into this issue. Our current development resources are committed for a few weeks, but as soon as they're free we'll begin investigating this in earnest. Please keep a record of examples you have for the next few weeks. We'll follow up with you as soon as we can.

[ricmorin]

I am assuming that you leave the tech, 'assign, tech' on the order when posting? Yes?

Indeed strange. Exactly four times the labor cost is causing me to think there is some calculation error on the report side of things, or the order is somehow corrupted, causing the error. Just for the record, what version of 5.9 are you on where the reports are generated? And at the bottom of the reort itself there should be a report id. Mine says 05.03.04 smpft103

I run that report daily as part of my End of Day pachage. I look at that report EVERY day and I've never noticed such a marked error, but I will keep your issue in mind from here on out and double check the labor costs on each.

[integrity1]

Tina,

We are looking into this issue. Our current development resources are committed for a few weeks, but as soon as they're free we'll begin investigating this in earnest. Please keep a record of examples you have for the next few weeks. We'll follow up with you as soon as we can.

Please realize that some of my VERY important business reports have to be calculated manually, so for the next few weeks while YOU'RE busy, we'll surely be busier, too... Keeping track of the examples won't be altogether too hard. It's Wednesday now, and there's 5 out of 12 that are reporting incorrectly. I can't believe this is an altogether isolated reporting of this happening, so someone HAS to know SOMETHING.

I'm sorry, but the self-help/user forum & community has been more helpful anytime I had a technical issue than dialing the toll-free number and wasting an hour of my time.

Please fix this and call me as soon as you can, after all...I'm paying for this.

[ricmorin]

I've checked every posting since our last interaction and each is reported correctly....so far. I have not heard of anything like this on the forum before, but support may have records of it.

Did you have a chance to check the report version? and the version of 5.9?

[integrity1]

Did you have a chance to check the report version? and the version of 5.9?

We're running 6.4 right now, but I'm not sure how I would check the version number of my reports. Has there been any software sent out that represents an update to our installation recently? I can't even remember the last time I did that...

[ricmorin]

Ahhh. This was originally posted under the 5.9 section, so my reports and program are different than yours.

The report version, as stated previously, is at the bottom in tiny digits; usually on the bottom right.

[integrity1]

Ahhh. This was originally posted under the 5.9 section, so my reports and program are different than yours.

The report version, as stated previously, is at the bottom in tiny digits; usually on the bottom right.

It says "InvProfitSum.rpt 11.29.06"

I hope there's been an update to that....it would be SUCH an easier thing to try....can you let me know if you think there's been an update?

[ricmorin]

There may be. That's likely what support is working on now. Since this is 6.4, the report you are using is a newer version than mine. My advice is to sit tight and let support determine the root cause. Likely this will corrected with an updated version of that report.

[Silky7]

I understand you may be frustrated with this situation, and I may not have been entirely clear in my remarks. It's not that we were not working on this issue at all, but our Tech Support has spent many hours with it. We believe at this point the issue is due to anomalous data present in your database. We've never seen or heard of such a case. When our software development team has to become involved, it's the highest level of escalation available, so please do not feel we're trivializing or dismissing this.

Also, a friendly reminder — we understand how difficult it can be to have problems, but please be mindful of your tone in your posts. The administrator has not had much tolerance lately. http://managerforum.net/viewtopic.php?f=171&t=3

[integrity1]

I understand you may be frustrated with my tone, and I may not have been entirely clear the way I worded my response. It's not that I don't appreciate that you're working on this issue, it's just that I've spent a great deal of time struggling for an answer, and often times, the "live" tech support personnel has been (unfortunately) unable to assist me. I also believe at this point that the issue is due to a problem with the data in my database, which leaves me wondering why we can't simply reinstall & import my data from prior to the anomalies. I appreciate that your software development team has become involved, because it gives us the highest possibility that you'll find an answer for us. So please, do not feel offended by my tone as though I am trivializing your efforts.

[Silky7]

Restoring an old database prior to the existence of the issue is always an option. However, bear in mind what that details. None of the information — RO's, scheduled work, payments — that you've entered since that date (approximately 3 weeks?) would be present.

[integrity1]

Restoring an old database prior to the existence of the issue is always an option. However, bear in mind what that details. None of the information — RO's, scheduled work, payments — that you've entered since that date (approximately 3 weeks?) would be present.

{Then that may be reason not to wait any longer, of course.)

To avoid that predicament, however, what about importing (or re-creating) a clean copy of JUST the Technician table into the existing database. I'd assume that the "anomolous" data must be present where the technician's rate of pay is stored, to be calculating exactly 400% of the correct figure. Seems a clean copy of that table might be in order. Data entering the very small number of technicians for my shop won't take long, afterall.

Just trying to be pleasantly helpful, of course.

[integrity1]

...what about importing (or re-creating) a clean copy of JUST the Technician table into the existing database.

All fixed, I believe, thanks to the call we got yesterday at the end of the day. Apparently, they ran a query against my data that went into the Technician Setup table and cleaned up the anomaly. (Kind of like a flu shot) It didn't take all that long, and will, of course, be easier for any of you that have a similar issue. The name of the SQL doc they used was "populateCommissionRepairOrders.sql"

Thanks for getting to this fix in a much shorter timeframe than 3 weeks!