Due to a bug, seasonal exceptions in PM Work Order scheduling do not currently work. This will be corrected with a new release in the near future.
Some table viewers on the control panel are filtered. For example, Work Orders | Open Work Orders filters out any work orders that aren't open.
If you use the Print button on such a table viewer, you end up with a report window where you can select filter values that apparently conflict with the filter on the original window; for example, you could start with Work Orders | Open Work Orders and then specify that you want to print closed work orders. However, when MainBoss prepares the final report, it will re-impose the original filter (i.e. open work orders only). As a result, the report will be blank, because an open work order cannot also be closed.
This behavior can be confusing if you forget that you originally started in the Open Work Orders table viewer. One problem is that the report window doesn't have any indication that it's only going to print open work orders.
Similar effects happen with requests and purchase orders. For example, if you start in Requests | In Progress Requests, the resulting report will never show anything except "in progress" requests, even if you specify filtering criteria that should include other types of requests.
If you are using a computer with no printers installed, MainBoss will not be able to give you an on-screen preview of any reports. This is due to a problem in Microsoft Report Viewer. To fix this problem, define any sort of printer on the computer. Once you do this, MainBoss will be able to provide previews.
Before you install MainBoss Advanced 4.1 Udpate 3, you should stop and uninstall MainBoss Service (as described on the web page for installing the new software). If you don't do this, the newly installed MainBoss 4.1.3 will detect the existence of the old service and will not install a new one.
In this case, you must "force" the newly installed MainBoss to delete the service. To do this, you must use the command line version of MainBoss Service with the +Force option. For more information, see Invoking MainBoss Service from a Command Line .
You can edit the defaults for work orders and purchase orders to change what text is automatically added to the bottom. Specifically, you can go to the Printed Form section of the defaults and change any of the text.
If you change the text in this manner, it does not change the text in any customizations you have saved previously. Customizations save their own copies of the "Printed Form" information, and these copies are independent of any changes you might make in the main defaults. This can be confusing; when you use a customization, you will not see your new text, but rather the old text that was active when the customization was saved.
If MainBoss Service gets an error while writing to SQL Server, MainBoss Service will "hang" (i.e. stop doing anything). In this case, you will have to stop and restart MainBoss Service.
Note that this situation should be relatively rare. It may happen, for example, if someone stops SQL Server while MainBoss Service is running on a different computer.
When you are creating a record for the Users table, you are asked to specify a Contacts record for the user. You can create such a contact record by dropping the second arrow on the user record's Contact field and choosing the menu entry Create from Active Directory. This creates an appropriate contact record using information from your Windows Active Directory entry for the user. However, when you return to the user record from the contact record, MainBoss does not fill in the Contact field with the record you just created. You must click the "..." button and choose the contact record manually.
As soon as you install a new set of license keys, MainBoss assigns names to the keys. If you installed a set of MainBoss 4.0 or 4.1 keys in an older database, one or more of the keys will be labelled as "unrecognized" (since MainBoss 4.0 introduced new keys). When you upgrade an old database to mainBoss 4.1, the license key names are not changed; therefore, you'll still see an "unrecognized" name in the list, even though MainBoss 4.1 recognizes all the keys.
MainBoss 4.1 will work perfectly well even if one of the keys is labelled as unrecognized. However, if you want to get rid of the "unrecognized" label, you can delete the license keys and reinstall them again. MainBoss 4.1 will recognize all the keys and label them appropriately. (Note that you shouldn't delete the existing keys until you have found the original email message that contained the keys in the first place.)
If you try to create a database from backup, and you specify a backup file name that does not end with ".bak", MainBoss adds ".bak" anyway. This means that if the file name really doesn't end with ".bak", MainBoss won't be able to find the file.
Also, when you try to create a database from backup, MainBoss will ask you to specify the backup file. This file must be on the computer where SQL Server is running, and it must be accessible to the SQL Server. If it isn't, the database creation won't work.
To export data to Excel, MainBoss uses Microsoft Report Viewer. Excel spreadsheet may have the Row Height set too small for some data fields. With some reports (e.g. Unit Maintenance Plans), the resulting
To solve the problem, select the entire spreadsheet then use the AutoFit Row Height operation. This is typically found on the Home ribbon; use the drop-down arrow associated with the Format button in the Cells section, then select AutoFit Row Height from the menu.
If you try to create a chart based on too much data, the chart may end up looking garbled. This problem is due to a deficiency in Microsoft Report Viewer; note that it appears on some versions of Windows (e.g. Windows 10) but not on others (e.g. Windows 8.1).
Note also that the maximum height for any bar in a chart is the height of the printed page; there is no way to create a chart with bars longer (higher) than a single page. If you have this kind of trouble with a particular chart, consider using filters and grouping to break up the chart into several smaller charts.
If an expense model has no associated expense categories, it will not be displayed in an Expense Model report.
With earlier versions of MainBoss, importing item information from MainBoss Basic 2.9 did not correctly set the cost centers in storage assignment records associated with the item. This problem has been fixed in this release; however, any databases created with earlier releases will still need to be corrected manually.
If you create a customized filter for a table based on active filter selection, the filter does not change if you change your active filter selective time.
For example, let's say that you create a filter for the "Work Orders" table viewer so that it only shows active work orders, and let's say that your "Company Information" definitions say that work orders become inactive after six months. Then suppose that later, you change your "active" definition so that work orders become inactive after eight months. MainBoss won't change the old filter; it will still work as if work orders become inactive after six months.
If your table viewer is set to "All" rather than "Active", you will be able to see non-active work orders and purchase orders (i.e. ones that are so old, they are considered inactive, even if they're still open). If you choose to edit one of these work or purchase orders, the resulting editor window will open in "Active" mode. These means that you may not see old information contained by the record that you're editing. For example, you might not see demands or actuals that are old enough to be considered inactive.
To see old information, you must change the editor window from "Active" to "All" (by double-clicking on the word "Active" in the bottom right corner of the window).
MainBoss uses Microsoft's ReportViewer to produce reports. In a small number of cases, ReportViewer will treat "#" followed by a string of characters as if it has a special meaning. For example, "#TOTAL" stands for the sum-total of values contained in the report.
This causes problems if anything in your data contains "#TOTAL", e.g. if some inventory item has "#TOTAL" in its name. If that item appears in a report, ReportViewer automatically prints out the calculated total in place of "#TOTAL", even though the number makes no sense in the name of an item.
Fortunately, there are only a few special cases like "#TOTAL". An arbitrary string like "#AYNX" has no special meaning, so ReportViewer leaves it as is. Nevertheless, we recommend that you do not use the "#" character in any type of data, including identification codes and descriptions.
If you delete a storeroom record, MainBoss does not delete any storeroom assignment records associated with that storeroom. You will have to delete each of those separately.
If a task includes item demands in its resources, there are three options for determining the actual cost of the item: "Manual Entry", "Current value calculation", and "Demanded". The "Demanded" option tells MainBoss to calculate the item's actual cost based on price information as of the time when the demand is created.
This leads to problems if the item doesn't have any associated price information. In this case, MainBoss can't calculate a price for the item, and therefore can't create a work order from the associated task. MainBoss will issue an error message saying that the work order couldn't be created.
This problem doesn't occur if MainBoss can determine a price for the item, either from price quotes, previous purchases, or from a value on a non-zero inventory count. Thus, the problem usually occurs when you have recently started using MainBoss (so you don't have information on past purchases) and when the physical count for the item is zero.
To work around this problem, create a price quote for the item.
If you've already created a receipt for all or part of a purchase order line item, you can't delete the line item from the purchase order, even if you cancel the receipt. (This problem may arise, for example, if you accidentally attribute a received item to the wrong purchase order.)
One way to deal with this problem is to edit the original line item to have a zero value, and to change the "Purchase Order Text" to something like "Line item deleted due to error". This isn't ideal, but at least it makes sure that your accounts are handled correctly and you have a note telling you what happened. You could use the associated "Comments" field to provide a more complete explanation of what happened.
If a task record contains a demand that is linked to a purchase order template, the demand cannot be removed from the task and the template cannot be disconnected from the task. Instead, you must go to Coding Definitions | Unit Maintenance Plans | Purchase Order Templates and edit the purchase order template in order to remove the demand from the template. Save the template. After that, you will be able to unlink the template from the task, and then remove the demand from the task.
If you delete a user from the Users table, that user's SQL Server permissions on the MainBoss database are not deleted. Furthermore, the user record is not completely deleted; it is merely hidden (as is usually the case with records deleted from a table).
If you try to create a new record for a previously deleted user, and if you try to use the same contact record, the operation doesn't work—you'll be told that the contact record for the user is already linked to another user (i.e. the deleted user record). Instead, use the Restore operation to restore the deleted user record. (In order to see the deleted record, double-click the word "Active" in the bottom right hand corner of the window. The word will change to "All" and the table will change to display deleted user records as well as active ones.)
In the MainBoss Users table, a user name that doesn't have a value in the "Scope Name" field is intended to refer to all instances of that name, whatever the actual scope is. For example, if the user name is "jsmith" and "Scope Name" is blank, MainBoss will use that user record for any one with the login name "jsmith", regardless of the user's domain.
However, if the Users table contains a "scope-less" user record, and a record for the same user name with a scope, the record with the scope will always be used for users with the specified login name and domain. For example, if the Users table contains an entry for "DOMAIN\jsmith", that entry will always be used for someone logging in under DOMAIN\jsmith, even if the Users table also has a scope-less entry for "jsmith".
Some users have run into problems with this by accidentally creating multiple records for the same user: one scope-less, and one with an explicit domain name. The security roles associated with the explicit domain name record will always take precedence over the roles in the scope-less one, which may cause unexpected behaviors.
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.
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.
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.
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.
When you first go to a report preview, the zoom mode is set to 100% and the page layout is set to list mode. Due to a problem with Microsoft Report Viewer, if you set the zoom mode to "Whole Page", the result is typically unreadable; "Whole Page" is only suitable for use if you set the page layout to page mode.
A problem occurs if you were previously running MainBoss Service using an unencrypted POP3 interface. The upgrade process going from any Version 3 release of MainBoss (e.g. 3.4.2) to any Version 4 release mistakenly changes the configuration to encrypted POP3. It also deletes the port number associated with the connection.
To fix the problem, change your MainBoss Service configuration record back to unencrypted POP3 (or else change your mail server to accept one of the encrypted POP3 protocols).