If, for any reason, a MainBoss session disconnects from SQL Server, MainBoss doesn't attempt to establish the connection again. A disconnect can happen for many reasons; for example, the computer where SQL Server is running may go down or may be temporarily unplugged from your network. Also, if you do nothing with MainBoss for a long time (at least half an hour), SQL Server may "time you out", which means that SQL Server cuts your connection because you've been idle too long.
In such cases, MainBoss should probably try to reestablish its connection; the current version doesn't. Instead, you'll just get an error message: "Unable to refresh browser list contents; click the Refresh button to try again." If you click the "Details" button on the message window, you'll see something like "A transport-level error has occurred when sending the request to the server. (provider: Shared Memory Provider, error: 0 - No process is on the other end of the pipe.)" In some cases, you may get a different message that may not be very clear on what has actually gone wrong. The only way to fix the problem is to quit your current MainBoss session and start a new one.
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.
If, for any reason, you decide to uninstall MainBoss Service, you can't just re-install the software the way you originally did. The problem lies with the Microsoft Installer (MSI) which "remembers" software that was previously installed and takes shortcuts if you try a re-installation. In particular, MSI won't ask you to specify the name and server of your MainBoss database. Because of this, MSI ends up in an error state; furthermore, the messages it issues aren't helpful when you're trying to figure out what's gone wrong.
After you uninstall and before you re-install, you have to clean up your system to "fool" MSI into installing MainBoss Service from scratch. For instructions, click here.
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.
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.
Due to a bug, a task listing does not include work descriptions, work categories, and/or work order priorities.
Requests, work orders and purchase orders are numbered automatically based on a starting value given in the "Defaults" section of the table viewer (e.g. "Defaults for Requests" in the Requests table viewer). You specify the number in the "Number Sequence" field; this number increases every time you create an automatically-numbered request, work order or purchase order.
If "Number Sequence" ever comes to a number that has already been used, you will get an error when you try to create a request, work order or purchase order with that number. The error message begins with the string "Violation of UNIQUE KEY constraint". When this happens, "Number Sequence" will not be increased (because MainBoss didn't manage to create anything with that number). Therefore, the next time you try to create an automatically-numbered request, work order or purchase order, you'll get the same error message because of the duplicate number.
To get "unstuck", go to the appropriate defaults section and click "Edit Defaults". Set the "Number Sequence" to 1, then click "Save defaults". Immediately, set the "Number Sequence" to a value higher than any numbers that are already in use. Click "Save defaults" again. From this point on, you should have no trouble creating automatically-numbered requests, work orders or purchase orders.
If you order a number of items, but a particular receipt contains less than the number you ordered, the Receiving Report displays incorrect values for the cost of the number received. Note that the problem is only in the calculations performed for the Receiving report; the MainBoss database correctly records the true costs of the items.