Dimension defaulting - Part 6 (Common pattern APIs)
Continuing this series of blog posts, this post describes APIs used for most common defaulting patterns.
This blog post series includes:
- Financial dimensions discovery
- Control uptake and storage
- Copy patterns
- Merging patterns
- Ledger dimension creation
- Common pattern APIs (this post)
- Advanced topics
The dimension defaulting service provides the APIs needed for defaulting scenarios. The methods are highly optimized for performance.
The serviceMergeDefaultDimensions() API is the most commonly used API for default dimensions. It should be called whenever a new default dimension needs to be created from 2 to 4 other default dimensions. If more default dimensions need to be merged than 4, it can be called multiple times with the result of the prior call used as the first parameter to the subsequent call.
Figure 1: DimensionDefaultingService.serviceMergeDefaultDimensions()
The serviceReplaceAttributeValue() API is useful in the case that a single dimension value needs to be copied from one default to another default set. The value specified will replace whatever value already exists in the source set.
Figure 2: DimensionDefaultingService.serviceReplaceAttributeValue()
The serviceCreateLedgerDimension() API is the most commonly used API for ledger dimensions. It should be called whenever a new ledger account combination needs to be created from a default account or existing ledger account combination and 0 to 3 default dimensions. If more default dimensions need to be merged than 3, it can be called multiple times with different sources taking the result of the prior call as the first parameter to the subsequent call. The MainAccount dimension is only retrieved from the supplied ledger dimension.
Figure 3: DimensionDefaultingService.serviceCreateLedgerDimension()
The serviceCreateLedgerDimensionForType() API is similar to the previous API but rather than creating a ledger account combination, it can create other ledger dimension types such as budget accounts or budget planning accounts specified by the LedgerDimensionType parameter.
Figure 4: DimensionDefaultingService. serviceCreateLedgerDimensionForType()
The serviceCreateLedgerDimForDefaultDim() API is similar to the previous APIs, but the values from the default dimension are copied directly to the new ledger dimension, while the dimension values from the ledger dimension are merged afterwards. In the previous APIs, the ledger dimension values were copied, and the default dimension values were merged.
Figure 5: DimensionDefaultingService.serviceCreateLedgerDimForDefaultDim()
The serviceLedgerDimensionFromLedgerDims() API is similar to the previous APIs but uses only ledger dimensions as sources to construct a new ledger dimension. The main account will only be retrieved from the first ledger dimension.
Figure 6: DimensionDefaultingService.serviceLedgerDimensionFromLedgerDims()
The serviceMergeLedgerDimensions() API is similar to the previous API but is optimized to combine just 2 ledger dimensions.
Figure 7: DimensionDefaultingService.serviceMergeLedgerDimensions()
The serviceCreateLedgerDimFromLedgerDim() API is useful when copying ledger dimensions from a historic posted document onto a new unposted document to ensure that it uses the current account structure configuration. This will avoid validation errors when validating the new ledger dimensions during posting.
Figure 8: DimensionDefaultingService.serviceCreateLedgerDimFromLedgerDim()
In the next blog post, additional defaulting patterns and APIs that can be used in advanced scenarios will be described.