Known Problems: MainBoss Advanced 3.2, Update 2

1. Microsoft Report Viewer:

   MainBoss Advanced requires the Microsoft Report Viewer. If you are attempting to install MainBoss on a system that doesn't have Report Viewer installed, the MainBoss installation procedure will attempt to obtain Report Viewer from Microsoft and install it.

   Unfortunately, Microsoft recently changed the web location of the Report Viewer software. Therefore, when the MainBoss installation procedure attempts to download the software, the process fails. To get around this problem, you must download and install Report Viewer yourself before running the MainBoss installation procedure. You can get the Report Viewer software from https://www.microsoft.com/downloads/details.aspx?familyid=6aaa74bd-a46e-4478-b4e1-2063d18d2d42&displaylang=en .

   The above web page for downloading Report Viewer says that the software is a security update. However, it's actually the full Report Viewer software package. This is the package that MainBoss needs.

   You must download and install this version of Report Viewer on any computer where you wish to install MainBoss Advanced.

2. Bugs in Microsoft Report Viewer:

   Report Viewer 2008 has several known bugs that affect MainBoss.

   • Report Viewer sometimes misbehaves if a single record (e.g. a single work order) is longer than a page. Information at the beginning of the record may appear one line per page until the remainder of a block of information will fit on a single page.
     This problem affects print-outs and PDFs, but not the usual MainBoss preview. Therefore the preview may look fine but a print-out will have the problem. The problem does appear if you click the print layout button at the top of the MainBoss preview.
   • If you use Report Viewer's facilities for exporting to Excel, the exporting process sometimes generates the error “Data Regions within table/matrix cells are ignored.” Note that MainBoss's own "Export Data" facility does not get this error, so you can use it as a workaround if Report Viewer gets this error.
   • If you ask Report Viewer to create a pie chart with no data, you get a box with the message "Value was either too large or too small for a Decimal". This can happen, for example, in the Work Order History Report if you specify the option "Show summary chart for each Work Order" and some work order has no actuals or demands.

   Microsoft corrected these problems in Report Viewer 2010, but unfortunately, MainBoss 3.2 Update 2 doesn't work with Report Viewer 2010. The next release of MainBoss will use Report Viewer 2010, at which point the problems will go away.

3. Error in Microsoft Excel:

   When you use Report Viewer to export information to Excel, Excel may issue the message "File error: data may have been lost". This is a known problem in Excel (not Report Viewer). To the best of our knowledge, no data is actually lost—Excel is simply issuing a false error message.

4. Transferring Inventory to Another Storeroom:

   The Item Transfer To operation uses the wrong unit cost for the transferred inventory. For example, if you use Item Transfer To to transfer item X from storeroom A to B, MainBoss should use the unit cost from storeroom A, but instead it uses the unit cost from storeroom B. The greatest problem occurs when storeroom B starts out with none of the item being transferred; in that case, the unit cost in storeroom B is zero, so the unit cost for the transferred items will also be zero. To get around the problem, use Item Transfer From and manually set the unit cost of the transferred inventory.

5. Errors in Closing Web Work Orders:

   This problem only occurs when you are closing work orders through the Web Access (MainBossRemote) web interface.

   Suppose you make a mistake when closing a work order (e.g. you fill in a date field with something that isn't a valid date). MainBoss displays a new version of the same web page, with an error message telling what the mistake was. You might think you can use this new page to correct your mistake; however, it won't work.

   You must click your browser's button for going back to the previous web page (the page where you originally made the mistake). You can then correct the mistake on that page.

6. Organization Name Can't Match Any Building or Vendor Name:

   If you are importing data from MainBoss Basic, your database's organization name must be different from the names of all the buildings in your MainBoss Basic Buildings table and all the vendors in your Vendors table. Otherwise, the importing process runs into problems.

7. Purchase Order History Gives Incorrect Amounts:

   For each purchase order, the Purchase Order History report lists all the items ordered and all the items received. The final sums adds up the costs of both lists. Unfortunately, if an item was ordered and then received, it appears in both lists and therefore its cost is counted twice. As a result, the final sums may be twice what they ought to be.

   There was a reason why MainBoss has separate lines for what was ordered and what was received. For one thing, there may be discrepancies in the price: the price charged by the vendor might be different than you thought it would be when you created the order. Furthermore, there may be discrepancies in quantity: you may have ordered a quantity of 5 items and only received 3. Therefore, it’s useful to be able to compare the cost and quantity ordered vs. the cost and quantity received. Unfortunately, MainBoss should be doing the addition process in such a way that each item is only counted once, even if it has been both ordered and received. This problem will be fixed in the next release.

8. Sequence Count Getting Blocked:

   If you enter your own ID number for a request, work order or purchase order, a problem may arise if the number you enter has the same format as automatically-generated numbers and if it is higher than the current number.

   For example, suppose the current work order number is WO 09999 and you manually give a work order the number WO 10002. MainBoss will automatically assign new work orders the numbers WO 10000 and WO 10001. However, when MainBoss tries to assign a number to the next new work order, an error occurs because WO 10002 is already taken.

   To correct this problem, you have to reset the number sequence for work orders. To do this, go to Work Orders in the MainBoss control panel, and go to the Defaults for Work Order section. Click the Edit Defaults button and set the "Number Sequence" field to the next number past the highest number used. (In our example, this would be 10003.) Click Save Defaults & Close and MainBoss should work properly again.

   The same principle applies to requests and purchase orders.

9. Error in the Units section of Expense Model Records:

   If you are editing an expense model record and you go to the Units section, MainBoss may stop working because of an unhandled exception. The same problem happens if you use the Expense Model table viewer and look at the Units section of specific table entries.

   The problem is due to a bug that arises when unit A is a sub-unit of unit B, and A has an associated expense model but B does not. The bug will be fixed in the next release of MainBoss. To work around the problem in the meantime, make sure that every unit which contains one or more sub-units has an associated expense model.

   Note that the bug does not damage your data in any way. It causes MainBoss to quit, but the only real drawback is that you can't use the Units section of the expense model record to look at units until you've fixed the problem (as described above). In other words, the bug is inconvenient but not harmful.

10. Show Detail in Work Order History:

    The "Show Detail" checkbox in the Work Order History report is supposed to control how much detail is printed for each work order. In particular, if you blank out "Show Detail", a lot of resource details should not be printed. However, in the current release, full details are still printed; the only information that isn't printed is the headings for the detail sections. This will be fixed in the next release.

11. Adding a Specification to a New Unit:

    Suppose you start creating a unit record, and before saving the record, you attempt to add a specification to it. MainBoss lets you open the specification form and fill it in, but when the time comes to save the data, you'll get an error message. The problem is that the unit doesn't really exist yet because you haven't saved the main record; therefore when you try to save a specification for the unit, MainBoss runs into problems.

    To avoid the problem, just save the unit record before you try adding specifications to it.

12. Confusing Order in Labor History Reports:

    This problem applies to the labor history reports (e.g. the Hourly Inside Labor History Report). Depending on the grouping and sorting options you specify, demands and actuals may be grouped and sorted in very different ways, making it difficult to see which demands go with which actuals. Furthermore, Actuals display "0:00" in the Estimated Hours column when the entry should just be blank (actuals don't have estimated hours, they have actual hours).

    In future releases of MainBoss, actuals and demands will be grouped and sorted in the same order to make it easier to see which matches with which.

13. Expense Categories in Demands:

    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.

14. Multiple Copies of the Same Incoming Email Request:

    If an incoming e-mail request has an attachment, and the attachment has any line beginning with a "+" character, MainBoss will not process the message correctly. Furthermore, MainBoss will not delete the message from the mailbox, so everytime MainBoss attempts to process e-mail messages, MainBoss will trigger an error. The most obvious result is that you get multiple copies of the message that has the problem, leading to multiple new requests from the same message.

    This bug was fixed in later versions of MainBoss, so the easiest way to deal with it is to upgrade. If there's some reason you can't do that, you'll have to delete the problem message manually (e.g. use some normal e-mail program to open the MainBoss mailbox and delete the message).

    (Technical note: It may not be obvious when a line in an attachment begins with "+"—the way that lines are transmitted in an e-mail message may differ from the way lines are shown when the attachment is displayed. This means it is sometimes difficult to determine which e-mail message is causing the problem. The main symptom is that submitted requests may repeat (generating a new request every time MainBoss Service does its work), or that some messages generate no requests at all, or that the service stops without being told to do so. In any case, messages are not deleted from the mailbox.

    The service log may include a diagnostic message that tells you the service can't fetch or delete a particular e-mail, and the diagnostic may be followed by a fragment of an e-mail instead of the details of the error. The e-mail fragment may just be gobbledygook, especially if the attachment is not a text file.

    Typically, if MainBoss Service complains it cannot delete message #1, the problem is actually being caused by the last message in the mailbox. If MainBoss Service complains it cannot fetch message #N, the problem is being caused by message #(N-1). This numbering counts both read and unread messages. In either case, the message causing the problem will likely be the last one you see in the MainBoss's Administration | MainBoss Service | E-mail Requests, and this message will be truncated when viewed in the window.)

Known problems in other releases of MainBoss Advanced.