Hi Zyme,
I'm assuming you mean when creating cash book entries?
Since a blank/NULL VatCode is completely valid, we unfortunately cannot treat NULL as "just pick it up from the Chart of Accounts" - since, then, the API would have no way of distinguishing between that intent and the intent to actually set VatCode to NULL.
You could argue that the above only applies when using data classes, where you have to explicitly set all properties - whereas, when using proxy classes or the simple Create...() methods - specifying only the Account and/or ContraAccount - automatic setting of VatCode based on settings from the Chart of Account would be entirely feasible. I might even be inclined to agree with you that, in hindsight, we should probably have made it so.
However, introducing side effects in such an important area retroactively could effectively constitute a breaking change for certain integrations - in which developers have depended on the current functionality.
Best regards,![]()
I'm assuming you mean when creating cash book entries?
Since a blank/NULL VatCode is completely valid, we unfortunately cannot treat NULL as "just pick it up from the Chart of Accounts" - since, then, the API would have no way of distinguishing between that intent and the intent to actually set VatCode to NULL.
You could argue that the above only applies when using data classes, where you have to explicitly set all properties - whereas, when using proxy classes or the simple Create...() methods - specifying only the Account and/or ContraAccount - automatic setting of VatCode based on settings from the Chart of Account would be entirely feasible. I might even be inclined to agree with you that, in hindsight, we should probably have made it so.
However, introducing side effects in such an important area retroactively could effectively constitute a breaking change for certain integrations - in which developers have depended on the current functionality.
Best regards,