CAPITAL Service Manager Mobile Field Service is now available as an add-on to either the CAPITAL Business Manager or CAPITAL Sales Force Manager, iX Release. The Service Manager and Service Manager Scheduler components are required.

CAPITAL Business Manager, Warehouse Manager and Sales Force Manager generate various diagnostic logs as required, during application runs. The purpose of each log is explained below.

CAPERR.TXT

This is the error trace log. It contains detailed information on the state of the system and the run-time environment when an error state is detected.

INTERR.TXT

These contain special internal cross checks and validation alerts. These alerts are supplementary to the error system and do not indicate run-time errors, but rather anomalous conditions such as alerting users to transactions that do not correctly balance.

CBSERR.TXT

Errors detected and logged by the CBS (CAPITAL Business Script) language. Script writers should use this log to review and correct errors in their scripting and custom hooks.

LOGERR.TXT

This is a summary of an error that caused an application to unexpectedly close. It will log the date and time, machine and user. A more detailed log will be found in CAPERR.TXT for the particular incident.

NETERR.TXT

A log of dead lock events. These relate to events where multiple users are attempting to change the same or related data at the same time and are prevented from proceeding.

TBLERR.TXT

These relate to table access errors and usually indicate data access or corruption issues.

AGENTERR.TXT

Similar to CAPERR.TXT but this is the log specific to the CAPITAL Server Agent application.

MAIL.LOG

Diagnostic information on the last email sent, including any email server reported errors.

REPAIR.LOG

If an automatic repair process fails this log is useful in identifying the point of failure, such as the damaged file that could not be repaired.

LICLIMIT.TXT

If license limits have been reached, the system will write a log of all currently licensed users either active in the system or who have previously consumed a license.

UPGRADEERR.TXT

Similar to CAPERR.TXT but this is the log specific to the CAPITAL Upgrade application.

Note: The major logs are forwarded to CAPITAL Office Business Software when a user selects Help|Email Tech Support System Info, from the menu system.

With the introduction of manufacturing capabilities added to CAPITAL Business Manager in the next release, this topic discusses some conceptual differences between traditional reorder points versus lead times, for restocking inventory.

A typical business that carries stock will (most of the time) work off a reorder point. When carry levels drop below the reorder point, this triggers the system to order more stock. A reorder that has been specified correctly, should take into account safety stock levels and some sort of estimate of sales over the period where stock has dropped below the reorder requirement.

Let’s say your reorder point is 45 units and your max stock level is 100. And you reorder this item when it drops below the reorder point. What we generally don’t think about, but which is a factor which goes into determining the reorder point, is the supplier lead time. If we know this supplier takes 7 days to process an order and ship goods to you, a reorder point of 45 is really coverage for 7 days plus whatever safety buffer you want to add to that. That might mean you’re selling 40 units a week and you’re carrying an extra 5 for safety in case you get an order that is greater than 40 over that week or it takes you an extra day or so longer to raise your PO.

The point of this explanation, which will be obvious to some, is to highlight the role of the lead time in the above scenario. Although its role is not necessarily explicit.

Given the above (typical) process for inventory management, many or most users will take the lead time into account when setting up their reorder points and this usually gets the job done, so they may not bother to also specify on the stock record what the actual lead time is, i.e., 7 days.

MRP is different in this fairly important respect. The reorder process is not driven by reorder points, but by lead times. For MRP to work efficiently every item has to have a lead time on it. CAPITAL MRP will let you specify a global/default lead time if an item doesn’t have a lead time against it, but obviously that is not ideal. As the global lead time will generally try to cover all worst case scenarios, which means you will be ordering more stock and holding it longer, than would otherwise be necessary. In an ideal scenario you only want to hold the stock you will use in manufacturing for only a short period before it is consumed.

If your manufacturing requirements are greater than your Free Stock plus stock already ordered, then you need to order the difference (called the Short Fall) prior to the scheduled manufacture date. In CAPITAL this Short Fall, less what has already been ordered, is referred to as the Procurement quantity. (This is what gets placed as the order quantity on your purchase orders.)

While things are actually a little more complicated than this, for the sake of this discussion complicating factors need not be addressed here.

Therefore, if you’re asking the system to schedule when you can build an XYZ, the system needs to consider two core requirements:

1. When do I have the capacity to build it (i.e., available labour time)
2. When can I acquire those goods I can’t immediately draw from stock?

And in this case, the system is going to look at when there is capacity to make those goods, and then next, what is not in stock and what the lead times are for those missing components. Even if you can theoretically start manufacture next Wednesday, if the lead time on a particular component is 14 days, then the schedule date is going to push out to the week following next.

The moral of this story is that MRP is largely driven by lead times rather than reorder points. If you’re thinking about setting up MRP inside CAPITAL, you need to assess your raw material and component codes and establish and add missing lead times. These may never have been entered – or at least maintained – when your original inventory was first created.