There are no additional details on the error message. The batch generation fails, and the editor form is left with the Generate button still enabled.
This problem is caused by a defective Maintenance Batch Detail record created by the 2.9 import. This will occur if a schedule in the 2.9 database was date-based at the time the data was exported for conversion, but was at some time in the past meter-based.
The problem is correctable, but the difficult part is finding the invalid Detail record. If you have a small number of unit maintenance plans, you can search and make corrections as follows:
This problem will be fixed in two ways in the next update of MainBoss Advanced. The process for importing MainBoss Basic databases will be corrected so that the problem doesn't arise in future. Also, if the PM generation error occurs on an existing MainBoss Advanced database, the error message will have details that will help you identify the task and schedule of the incorrect unit maintenance plan; this will make it much easier for you to find which plan is causing the problem and thereby correct it (as described above).
Suppose you are using a filter to look at Work Orders (e.g. you are only looking at work orders with a given priority). If you click the Print button, the resulting report ignores the filter you were using (e.g. you see work orders of all priorities).
You can, of course, set the filters for the report to match the filters you were using when looking at the table. However, we believe it would be better if the table viewer's filter carried over to the report in this situation. Such a facility may be implemented in a future release.
A similar problem happens with the Active filter on work orders. In a table viewer, the Active filter only applies to closed or void work orders; it never filters out open work orders, no matter how old they are. In a report, however, the Active filter is applied to all work orders, whether or not they're open. This may mean that you can see a work order in the table viewer, but when you try to print out that work order, the resulting report shows nothing. To get around this problem, go to the Advanced section of the report window and checkmark Suppress Active Filter restrictions. You can then print "old" work orders that show up in the table viewer but not in the report.
The same sort of problem occurs with requests and purchase orders.
When MainBoss starts up, it checks your monitor screen's resolution. From that point on, MainBoss sizes its windows to fit that resolution. If you change your monitor's resolution while using MainBoss, MainBoss's windows will not change to match the new resolution. This may have various effects, e.g. information disappearing off the bottom of the screen with no easy way to get it back. However, if you maximize any window (by clicking the maximize button in the window's upper right-hand corner), the maximization will be correct because that's handled by Windows rather than MainBoss.
If you run into window sizing problems because of this, just quit MainBoss and start it up again. MainBoss will then take note of the new screen resolution and size windows appropriately.
Note that the minimum supported resolution is 1024 by 768. Ideally, we recommend 1280 by 1024 or better.
In work order demands, there's a field for specifying an expense category. The drop-down menu and the "..." for that field make it possible to create a new expense category; however, if you use these facilities to make a new expense category it doesn't get you anywhere.
To understand why, remember that the expense categories available for a work order are dictated by the current expense model. If you create a new expense category, that category won't be part of the expense model already chosen for the work order. Therefore, you won't be able to use the category you just created.
Instead of the current behavior, MainBoss should make it possible to add a new expense mapping to the current expense model. This would make another expense category available for use on the work order; this is usually what you want, as opposed to a brand new expense category.
If you have the MainBoss Administration security role, you can use Administration | Users to try to add a new user to MainBoss. However, you must also have SQL Server Administration permissions for the operation to succeed. If you don't have these permissions, you'll get the error message
User does not have permission to perform this action. The statement has been terminated.
Since the problem is that you don't have SQL Server permissions, you can't fix it by giving yourself more MainBoss permissions.
There are several ways to fix the problem.
If a storeroom assignment doesn't have a preferred pricing record, the ItemFulfillment security role is not enough on its own to record physical counts—the "New Physical Count" button will be enabled, but you won't be able to save any information you enter. When you try to save, you'll see the error message DataBaseName.dbo.AccountingTransaction'; column does not allow nulls. INSERT fails. The statement has been terminated..
The reason for this problem is that physical counts require the recording of price information, and ItemFulfillment doesn't give you permission to view prices; if there isn't a preferred pricing record, MainBoss can't determine an appropriate price for the inventory. In order to record physical counts you need either ItemView, Item or AccountingView in additional to ItemFulfillment.
Several problems have arisen because of bugs in Microsoft's Report Viewer.
If an assignee to a request, work order or purchase order has received at least one notification message, notifications will continue to be sent to that person even if he or she is removed from the list of assignments.