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.

To learn more click here:


Maintenance Release G has been published today for the following applications:

CAPITAL Business Manager V8
CAPITAL Sales Force Manager V8

This update is a general housekeeping release.


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.


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.


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.


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.


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.


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.


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


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


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


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.


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.


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.

Maintenance Release E has been published today for the following applications:

CAPITAL Business Manager V8
CAPITAL Sales Force Manager V8
CAPITAL Server Agent V8

This update addresses various miscellaneous issues including:


  • Stressed servers (overloaded or low memory) may have suffered from performance related problems when opening the Stock Activity & Transaction Activity tabs.
  • Customer related columns in the Back Order Control Centre may not have displayed correctly due to an issue related to maintenance D.
  • Zooming in the Back Order Control Centre, Account Manager tab, opened stock instead of customers.
  • Prompt for shipping dockets setting did not respond to request to open them from the Back Order Control Centre.
  • Credit note number sequence may have changed when altering the transaction type from credit note to a different type from within a credit note under certain circumstances.
  • Inside Hire Manager, R-HILINE.MAC script did not fire for goods returned from hire.

Maintenance Release D has been published today for the following applications:

CAPITAL Business Manager V8
CAPITAL Sales Force Manager V8
CAPITAL Server Agent V8

This update addresses various miscellaneous issues including:

  • Automatic Bank Reconciliation might not pick up banking file from user specified folder.
  • An error may have occurred when trying to query the owner of a locked transaction in Corporate Edition.
  • Stress Test tool updated to support later versions of Windows releases.

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.

An MRP requirement is essentially based on these elements:

* Free Stock + Stock On Order (your base stock)
* Manufacturing requirement quantity
* Lead time

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.

A new whitepaper is available describing the features new to CAPITAL Business Manager V8 and CAPITAL Sales Force Manager V8, release 8.8.

The whitepaper can be found here:

Version 8.8 of CAPITAL Office has been released today. Updated applications include:

CAPITAL Business Manager V8
CAPITAL Sales Force Manager V8
CAPITAL Server Agent V8

DIFOT stands for Dispatched-In-Full-On-Time (analysis)

This is a variation on a metric that couriers use. Their version is Delivered-In-Full, etc. But since we can’t capture in CAPITAL when the goods actually arrived at someone’s door, the CAPITAL system measures when the final paperwork, i.e., invoice was raised, ready for dispatch.

If you’re dealing with government accounts or corporates, one of the conditions of the supply deal is that you can deliver up to 95% of what the customer orders within 3 days, or whatever the arrangement is.

Or in other words, CAPITAL DIFOT measures the ordering, picking and processing efficiency of your warehouse. It also measures the impact overall, by individual customer, and by individual product.

DIFOT requires CAPITAL Corporate Edition.

Dispatched In Full On Time

« Older entries