Functional Enhancements (Development)

Automatic master data resource selection (»From Range« construct)

This feature can be used to have the system automatically select the first machine in a query-based drop-down list. The automatic selection is triggered by the cost engineer changing any of the other properties of the same business object marked as trigger properties.

Further Information Cost# manual on trigger properties

Query controlled input ranges for calculations

Query controlled input ranges can now also be used for calculations. One use case for this feature is to improve usability for a multi-level supply-chain functionality.

Further Information Cost# manual for details

Allow to specify allocations in signatures extensions

It is now possible to specify (loosely and tightly) allocate-able resources in signatures extensions. This can be used to implement step-by step costing where a step can add new possible objects to use under the current resource.

Nested detail view extensions are now AND-connected

The visibility conditions for detail view extensions are now automatically connected by a logical »AND« if they are nested. This avoids duplicate entries in detail views. If the condition of a »parent« extension is false, the »child« extensions are automatically excluded, even if they appear in other places in the detail view because their condition is true.

Detail view extensions can depend on a property being NOT provided

It is possible to activate detail view extensions when a certain property is not provided. Up to 10.3 it was only possible to activate it only when a property was provided. This is useful to include detail view extensions for older versions of the costing logic configuration.

A global property can depend on different dimension sets

This feature can be used to have the same global property depend on different dimension sets in different types of calculations.

For example: An overhead rate can depend on a specific plant in one type of calculation and on a Benchmark location in a different type of calculation.

Further Information Cost# manual for details

A property of a resource can depend on different dimension sets

This feature can be used to have the same resource property depend on different dimension sets in different types of calculations.

For example: A material price can depend on a specific plant in one type of calculation and on a Benchmark location in a different type of calculation.

Further Information Cost# manual for details

Improved condition expressions for signature extensions

It is now possible to provide a value for a dimension of a global property on a local resource, while still switching between different sets of dimensions on the calculation level. See also A global property can depend on different dimension sets.

Further Information Cost# manual for details

Breaking Changes for Solution Developers

Localizations of the calculation signature must include the quantity type

A localization XML entry for calculation signatures must now include the quantity type, otherwise the entry has no effect.

Example:

Property View was removed from the FACTON UI

The property view was removed from the FACTON UI as this is considered an obsolete feature.

The breaking change for solution designers is: If you have specified privileges for the property view in the solution, you need to remove these definitions, otherwise your solution import will fail.

For example, if you have a definition like this:

you need to remove the highlighted text »Customizing.PropertyView,«.

Exchange Rates Signature definition logic changed

In versions before 10.3, the platform had a pre-defined signature »ExchangeRates«. It was possible to extend this signatures in Cost# such that it depends on custom properties, e.g.

Signature Global ExchangeRates
{
Provides ExchangeRate [Number] Depends On CustomProperty_1, CustomProperty_2;
}

In 10.3, this signature is

  • no longer pre-defined, and
  • must have a different type: “ExchangeRates” instead of “Global”.

Solution designers must adapt solutions accordingly. There are two cases:

A: The signature was not extended in Cost#

A binary update to 10.3 will automatically add the following definition to the Cost# schema of all databases:

Signature ExchangeRates ExchangeRates

{

Provides ExchangeRate [Number] Depends On _SourceCurrency, _TargetCurrency;

}

 

Solution designers needs to add this exact definition to the solution, otherwise there will be no exchange rates after the solution is updated in a system.

Also, the solution designer needs to add localizations for this signature, as they will no longer be provided with the FACTON platform.

B: The signature was extended with custom properties in the Cost# schema

A binary update to 10.3 will automatically rename »Global« in »ExchangeRates«.

Solution designers will have to also rename this in their solution, e.g.

Signature Global ExchangeRates ExchangeRates
{
Provides ExchangeRate [Number] Depends On CustomProperty_1, CustomProperty_2;
}

Also, the solution designer needs to add localizations for this signature, as they will no longer be provided with the FACTON platform.

Known Issues

Issue, Workaround
SDE: Solutions which localize local list item signatures or global value signatures for calculations will receive a warning message on building a configuration.

The localizations will not work in the built configuration. This issue can be resolved by changing the signature name which is localized. In this example from:

LocalList::SingleCalculation::Attachments zu

LocalList::SingleCalculation:Piece^1::Attachments

Piece^1 being the quantity type of the calculation.
The CMD still needs Visual Studio 2015 to be installed, though using Visual Studio 2015 is never required when creating cost models with the CMD. The CMD still uses components only available after a Visual Studio 2015 installation.

Workaround:

Install Visual Studio 2015 before installing the CMD.