There is a well know approach (https://community.dynamics.com/blogs/post/?postid=c3176cf6-231d-42d8-a6a7-fbf2f33e4c2f ), which allows to separate Financial Dimensions in Excel add-in, and I successfully implemented such approach for the two DataEntities (LedgerJournalLineEntity and BudgetRegisterEntryEntity – I’ve created an extension in MyModel (MYM)).
Apart from that I got a requirement to restrict values in the lookup for one of FinancialDimensions (when you open the Excel add-in and focus on FinancialDimension field (let’s say – Office) you should be able to see (on the right side) the list of available Offices I need to restrict values for certain field (one of Financial Dimensions) in Excel add-in.
There is a well know approach (https://community.dynamics.com/blogs/post/?postid=c3176cf6-231d-42d8-a6a7-fbf2f33e4c2f ), which allows to separate Financial Dimensions in Excel add-in, and I successfully implemented such approach for the two DataEntities (LedgerJournalLineEntity and BudgetRegisterEntryEntity – I’ve created an extension in MyModel (MYM)).
Apart from that I got a requirement to restrict values in the lookup for one of FinancialDimensions (when you open the Excel add-in and focus on FinancialDimension field (let’s say – Office) you should be able to see (on the right side) the list of available Offices.
Here is the signature of that method:
[SysODataActionAttribute("DimensionCombinationEntityDimensionSegmentCustomLookup", false),
SysODataCollectionAttribute("_fields", Types::String)]
public static str dimensionCombinationDimensionSegmentCustomLookup(Array _fields)
You can create a subclass of DimensionSegmentLookupGeneratorBase and apply a restriction for any Financial Dimension (I did it for Office) — and this also works. Pay attention to the method's attributes: SysODataActionAttribute.
It is logical to assume that if there is some other entity (say not LedgerJournalLineEntity but BudgetRegisterEntryEntity) which also has a relation with DimensionCombinationEntity (BudgetRegisterEntryEntity.Dimension == DimensionCombinationEntity.RecId), then our restriction for Office should also trigger?! But it turns out — NO, when in the Excel Add-in we try to select available values for Office in the lookup (exactly the same way we tried for LedgerJournalTrans), the debugger never enters the DimensionCombinationEntity.dimensionCombinationDimensionSegmentCustomLookup() method at all.
It gives the impression that when Excel reads the metadata of LedgerJournalTrans it sees the method DimensionCombinationEntity.dimensionCombinationDimensionSegmentCustomLookup(), but when it reads BudgetRegisterEntryEntity — it does not see the same method.
At the same time we’ve discovered, that field BudgetTransactionLine.LedgerDimension (which is being used in the BudgetRegisterEntryEntity.Dimension – contains the LedgerDimensionBudget EDT)
Whilst LedgerJournalTrans.LedgerDimension (which is being used in the LedgerJournalLineEntity.Account– contains the DimensionDynamicAccount EDT)
Here is the EDTs inheritance structure:
- DimensionCombinationBase -> LedgerDimensionBase -> LedgerDimensionBudget (BudgetTransactionLine.LedgerDimension)
- DimensionCombinationBase -> LedgerDimensionBase -> LedgerDimensionAccount -> DimensionDynamicAccount (LedgerJournalTrans.LedgerDimension)
We’ve assumed that, that by adding two more fields (LedgerDimension (with DimensionDynamicAccount EDT) and AccountType (with LedgerJournalACType BaseEnum)) to the BudgetTransactionLine table (the same two fields that we have in the LedgerJournalTrans table ) we will achieve the expected result – but we haven’t.
(I’m reminding the purpose of this article: I need to restrict values for the Financial Dimension “Office” in the Excel add-in lookup, i.e. to make sure that when we get focused on the Financial Dimension “Office” field in the Excel add-in lookup the System goes in to the DimensionCombinationEntity.dimensionCombinationDimensionSegmentCustomLookup() method).

Report
All responses (
Answers (