Key Properties used in accounting should have clean, stable, and technically safe values. In ERP.net, such values may participate in the generation of accounting item keys. For this reason, they should be designed not only for readability, but also for reliable system processing.
Recommended best practices
- Use short, consistent, and meaningful values.
- Prefer codes or code-like values instead of descriptive free text.
- Where possible, the value should be the code of the property, not its display name.
- Keep the format uniform across all records.
- Use values that are stable over time and unlikely to be renamed.
- Treat any Key Property used in accounting as part of a technical key, not only as a user-facing label.
Why codes are preferred
Codes are generally more suitable than descriptive text because they are:
- stable — less likely to change over time;
- consistent — easier to standardize across records;
- compact — better suited for key generation;
- safer — less likely to contain spaces or punctuation with technical meaning.
For example, a value such as 02 is preferable to a display-oriented value such as 2. Main Office.
Why the dot (.) should not be used in values
The dot (.) has a special system meaning when ERP.net compiles item keys for accounting voucher lines. Because of this, using a dot inside a Key Property value may lead to ambiguous or invalid key generation.
Examples:
- Not recommended:
2. Main Office - Better:
2 Main Office - Preferred:
02
The issue is not visual formatting. The problem is that the dot is used by the system as a technical separator during item key compilation, so it should not be part of the Key Property value itself.
This is especially important in integrations, reporting, and statutory exports. In some scenarios, the system must trace a Key Property value from the analytical key back to the originating object in ERP.net — for example, identifying the related Customer during SAF-T export. Code-based values are much more reliable for such lookups than descriptive labels.
Temporary workaround
If an immediate workaround is required, ERP.net provides the configuration option DisableAccountKeyPropertyDotCheck.
When this option is set to 1, the system skips the validation that checks for dots in custom property values used during account item key generation. This should be treated only as a temporary workaround, because it does not resolve the underlying data design issue.
Official reference: Config options reference
Recommendation
The recommended long-term approach is to use clean, code-based values for Key Properties and to avoid dots in any values that participate in accounting key generation. The configuration option should only be used temporarily, for example to ensure business continuity while the affected data is being corrected.
0 Comments