It is better to have few failing tests on check consistency and false positive
alarms then accidentally confirmed Sale Orders.

Support correctly stop date.
Postpone new open order creation on start date update, until update is needed.

Start and stop dates are known from open order on first expand level.

Dates are document dependant.

Start date is moment when partition informed that got installed.
Stop date shall cover exactly one month.

It shall be extended always by one month.

Slave instance code is disabled.

Ordered orders can be without partition, but confirmed ones required it.
Also during confirmation check if partition was assigned correctly and
only then confirm order.

Since 2f05fe1b585d3ca736538b32269d36a410f5f7da getModificationDate does not
walk the whole workflow.

Do not catalog only Computer, Slave and Software instance modification and
creation dates. Other objects does not have such big histories so modification
and creation dates can be queried.

While *trying* to confirm order *try* to assign partition.

On asynchronous system there is no need that HS is immediately related to Open
Sale Order Line.

It minimises amount of Open Order versions and simplifies locking.

One Alarm to rule them all, One Alarm to find them,
One Alarm to bring them all and in the catalog bind them

Conflicts:
	master/bt5/vifib_slap/bt/revision