انتقل إلى المحتوى الرئيسي

Default Dimensions - Conceptual Flow

Overview​

Default dimensions provide a mechanism for master data entities (Customer, Vendor, Employee, etc.) to have a predefined set of financial dimension values that are automatically applied to transactions involving those entities.

Core Design Principle: Consumption-Time Constraints​

Key Principle: "No specific structure is associated with default dimensions, and in most instances, the consuming code constrains the set to the dimensions that are available for the current ledger." - Microsoft Dynamics 365 F&O

This means:

  • Setup Time: Users can set defaults for ANY active dimension attribute in the ledger
  • Consumption Time: Only relevant defaults are applied based on the account structure being used

Business Scenario​

Consider a Customer "ACME Corp" with the following default dimensions:

  • Department: SALES
  • CostCenter: CC001
  • Project: PROJ100
  • Location: NYC

When creating transactions for ACME Corp:

  • Sales Invoice (hits Revenue account structure requiring Department + CostCenter): Uses SALES and CC001
  • Expense Journal (hits Expense account structure requiring Department + Project): Uses SALES and PROJ100
  • Asset Purchase (hits Asset account structure requiring only Department): Uses only SALES

The system intelligently applies only the relevant defaults based on the target account structure.

Process Flow​

Data Model​

DimensionAttributeValueSet (Default Dimension Collection)​

public class DimensionAttributeValueSet
{
    public Guid Id { get; private set; }
    public string HashCode { get; private set; }  // For reusability
    public string Description { get; private set; }
    public DateTime CreatedDate { get; private set; }
    
    // Collection of dimension values in this set
    public IReadOnlyCollection<DimensionAttributeValueSetItem> Items { get; private set; }
}

DimensionAttributeValueSetItem (Individual Default Dimension)​

public class DimensionAttributeValueSetItem
{
    public Guid Id { get; private set; }
    public Guid DimensionAttributeValueSetId { get; private set; }
    public Guid DimensionAttributeId { get; private set; }
    public Guid DimensionAttributeValueId { get; private set; }
    public string DisplayValue { get; private set; } // For caching
}

Master Data Integration​

public class Customer
{
    public Guid? DefaultDimensionId { get; private set; } // FK to DimensionAttributeValueSet
    
    public async Task SetDefaultDimensionsAsync(
        IList<DimensionSegmentInput> dimensionInputs,
        IDimensionAttributeValueSetDomainService valueSetService)
    {
        // Creates or reuses existing DimensionAttributeValueSet
        var valueSet = await valueSetService.GetOrCreateAsync(dimensionInputs);
        DefaultDimensionId = valueSet.Id;
    }
}

Key Architectural Decisions​

1. Ledger-Level Availability, Not Account Structure Constraint​

Decision: Available default dimensions are determined by what's active in the ledger, not by any specific account structure.

Rationale:

  • Entities may have transactions hitting multiple account structures
  • Maximum flexibility for business users
  • Aligns with Microsoft's "consuming code constrains" pattern

2. Hash-Based Reusability​

Decision: DimensionAttributeValueSet uses content-based hashing for reuse across entities.

Rationale:

  • Multiple customers with identical default dimensions reuse the same record
  • Reduces storage overhead
  • Maintains referential integrity

3. Get-or-Create Pattern​

Decision: Default dimension sets are created on-demand using get-or-create pattern.

Rationale:

  • Ensures uniqueness without complex locking
  • Supports concurrent access patterns
  • Efficient for bulk operations

Business Rules​

Setup Rules​

  1. Any Active Dimension: Users can set defaults for any dimension attribute active in the ledger
  2. MainAccount Exclusion: MainAccount cannot be set as a default dimension (it's determined by transaction type)
  3. Optional Values: All default dimension values are optional - missing values don't prevent setup
  4. Reusability: Identical sets of defaults are automatically reused across entities

Consumption Rules​

  1. Structure Compatibility: Only defaults compatible with the target account structure are applied
  2. Override Support: Transaction-level dimensions override default dimensions
  3. Partial Application: Partial application of defaults is allowed (some used, some ignored)
  4. Validation: Applied defaults must still pass account structure validation

API Integration Points​

Setting Up Defaults​

GET /api/financial-dimensions/dimension-attributes/available-attributes
POST /api/accounts-receivable/customers/{id}/default-dimensions
POST /api/accounts-payable/vendors/{id}/default-dimensions

Consuming Defaults​

POST /api/general-ledger/journal-entries
# Default dimensions are automatically applied based on associated Customer/Vendor

Error Handling​

Setup Phase Errors​

  • Invalid Dimension Value: Dimension value doesn't exist or is suspended
  • Ledger Not Found: Specified ledger doesn't exist
  • Dimension Not Active: Attempting to use inactive dimension attribute

Consumption Phase Warnings​

  • Partial Application: Some defaults couldn't be applied due to account structure constraints (logged as warning)
  • Override Detected: Transaction-level dimensions override defaults (informational)

Related Documentation: