Skip to main content

Notifications

Announcements

No record found.

Community site session details

Community site session details

Session Id :
Finance | Project Operations, Human Resources, ...
Answered

Deletion of unused financial dimensions- "The dimension exists as a default dimension. You cannot delete dimension <name>"

(0) ShareShare
ReportReport
Posted on by 58

Good afternoon,

I'm having difficulty deleting a Financial Dimension from a 10.0.31 system. When I try, it throws the usual "The dimension exists as a default dimension. You cannot delete dimension <name>" error. I've copied the DB to my DEV box and debugged. The error is thrown because an entry exists in the DimensionAttributeSetItem table for this Dimension Attribute.

This Dimension Attribute is not linked to any Ledger Account structures or transactions and is not included in any Financial Reporting configuration.

Legacy questions on here suggest deleting the offending value from the database table, but Microsoft have explicitly blocked the ability to do so using an SQL DB trigger as per this article - https://go.microsoft.com/fwlink/?linkid=2147109. This article refers to a fix to resolve "an issue with Dimension sets removal" as per here: https://fix.lcs.dynamics.com/issue/results/?q=533024. This was included in the service update for 10.0.18, so is already applied.

It also states "In the future, Microsoft will provide a tool for self-service correction of data for targeted scenarios", but I cannot find any further reference to this.

Does anyone have any suggestions, besides leave the Dimension there and pretend it doesn't exist?

  • Verified answer
    Phil Matthews Profile Picture
    58 on at
    RE: Deletion of unused financial dimensions- "The dimension exists as a default dimension. You cannot delete dimension <name>"

    Just to update on this and close off, Microsoft Support have advised that you now cannot remove financial dimensions that have been part of a dimension set. This is by design and they will not support it. Their internal documentation on it reads as follows:

    Cause

    • This is working according to the logic of the system.
    • For any user-created financial dimension or system created financial dimension, once a value has been used in a transactional context -- EVEN if that transaction has not been posted, or even deleted, the system must block the deletes of the backing record value in order to maintain data integrity for reporting and auditing purposes.
    • User created financial dimensions are where the data comes from one of around 50 tables such as OMOperatingUnit (organization model element like department, cost center), DimensionFinancialTag (custom dimensions), or a plethora of other tables including Customer, Vendors, Workers, Retail Stores, etc...
    • System created financial dimensions are where the data comes from a small list of around 10 tables such as Vendors, Customers, Bank accounts, Projects, Items, Fixed Assets. When a Journal either within a specific module or the general journal is entered, the user can enter basically an alias for the ledger account by just entering the Customer ID, Project ID, etc.. and the journal will resolve that to a full ledger account at posting time. Since the field this is entered in is the same as a full ledger account, the data must be stored within the dimension tables the same as a full ledger account. Since a journal is a transactional data source, the data is considered to be used in a transaction and therefore cannot be deleted.

    Design reasoning

    • Dimensions data is insert-only, immutable (non-changeable).
    • Once a particular value has been inserted, it is never inserted again to increase performance.
    • Therefore, any particular dimension record could be referenced by just one, zero, or more than likely thousands to millions of records holding a foreign key to it.
    • Dimension data has references from over 600 shipping tables in over 1150 columns across those 600 tables, plus any number of customizations from partners that we can't detect.
    • Therefore, there is no ability, at the time the customer clicks the delete button, to scan every single record in all 600 of these tables to determine if any reference is still held to the dimension record being requested to be deleted. There could literally be a billion rows to be scanned to determine this.
    • Thus, as accounts are part of a accounting system of record, we must block the delete if it's been determined to have been used within the context of a transaction at least once, EVEN IF THE TRANSACTION HAS SUBSEQUENTLY BEEN DELETED.

    Workaround

    • Work with support to convey this is required behavior for data integrity reasons. The customer can choose to rename the value (e.g. "___DONOTUSE_ASSET001") to make it not appear in line with the other records.
    • If this is a single or handful of records, it will be highly likely that the customer will eventually need to create a new record in that table anyway (i.e. a new customer, a new asset, a new vendor). They should rename the value temporarily to a do not use context. Then as soon as they need a new record, simply rename it to the ID of the record they would have otherwise created. This is the quickest and easiest workaround for the customer that can save everyone significant time and cost in researching usage.
  • Komi Siabi Profile Picture
    12,847 Most Valuable Professional on at
    RE: Deletion of unused financial dimensions- "The dimension exists as a default dimension. You cannot delete dimension <name>"

    Hello Phil,

    Please check that, the dimension in question had not been used in the account structure setup.

    Here is a post on the subject.

Under review

Thank you for your reply! To ensure a great experience for everyone, your content is awaiting approval by our Community Managers. Please check back later.

Helpful resources

Quick Links

🌸 Community Spring Festival 2025 Challenge Winners! 🌸

Congratulations to all our community participants!

Adis Hodzic – Community Spotlight

We are honored to recognize Adis Hodzic as our May 2025 Community…

Kudos to the April Top 10 Community Stars!

Thanks for all your good work in the Community!

Leaderboard > Finance | Project Operations, Human Resources, AX, GP, SL

#1
Abhilash Warrier Profile Picture

Abhilash Warrier 185

#2
Martin Dráb Profile Picture

Martin Dráb 147 Most Valuable Professional

#3
Vahid Ghafarpour Profile Picture

Vahid Ghafarpour 130 Super User 2025 Season 1

Overall leaderboard

Product updates

Dynamics 365 release plans