Funny, portal type have to be configured in project BT5.

This will be no-op in case of divergence testers which are not automatic, and
is required again as invoice and transaction lines are merged.

SPLs does not share root applied rule.

Its total price related with use/trade/sale shall match related packing list
total price.

SPLs does not share root applied rule.

SPLs can have more lines which shall end up in same invoice.

Nonetheless SPLs have only one resource, so there is no need to merge them on
invoice.

hosting_subscription is not needed.

Also update rule to allow automatic solving.

Sale Packing List and Sale Invoice Transaction which are specialised by
getPreferredAggregatedSaleTradeCondition shall be managed in same way.

Disable obsoleted code and mark lack of implementation.

Realtime accounting does not change owner of resources.

Note: for now leave dirty strings, as refactoring is failing in case of too much
manipulation.

This allows to store all consumption/invoicing data from external parties.

Well, okay, implementation of tests are still dirty.

Uses portal integrations to store mappings of current delivery for person.

Uses hand crafted order builder to update quantity by adding.