Handle commits from std. NAV source code in an extension

[MaKnauer]

In our solution we often need to disable commits in standard NAV source code, because we need a single transaction in a process. For example:
Create a Order, release it, and post it. If there occurs an error during posting, the Order is created but not posted.

My suggestion:
We need a possibillity to disable commits in standard NAV source code.
By the way, perhaps it would make sense to provide a new Trigger "OnBeforeCommit", so that someone can save the status of the transaction / process.

[Gallimathias]

I think this is the same problem as in the following issues. Or the same wish for the same feature.

#153 #186 #593 #699 #120

In addition, I would like to add that I recently had a discussion about this topic in the company and at the German Dynamics 365 Hackathon 2.0 at Microsoft Germany in Munich. Currently, I would say that, at least here in Germany, the overwriting of standard code is one of the most important functions of all, especially with regard to the acceptance of the new development world by customers and old men in development, if I may put it this way.

[MaKnauer]

The other topics are more generall I think. We don't want to override / change code. My thought was to set a Publisher function with a bool parameter (disableCommit) before commits in NAV standard code. So you can set the parameter to true, to disable the following commit.
This would not change the fucntionallity, but the number of transactions during a process.

[StanislawStempin]

We are currently not planning to provide a generic platform functionality for this problem. We would instead suggest to request specific events/refactorings for your specific scenarios.

[Gallimathias]

A boolean parameter or other methods are at the end but only workaraounds. As long as there is no overwriting, I prefer overloading to keep the standard a little bit clearer.

I don't like it when all the wishes of all partners end up in billions of parameters or individual methods. In my opinion, these are mainly transitional solutions.

[MaKnauer]

Sorry, but I don't see the point of "billons of parameters or individual methods". I asked for a behaviour to disable certain commits, to have a complete roll back for processes. My intention is not to overwrite code with a new functionality.

Thanks Stanislaw for your answer. Our intention is of course to use as much of standard NAV as possible, and only write addon functionality. So I have to look if a refactoring is possible.

[reiniroosh]

@MaKnauer I'm a bit confused by your example btw.
Creating an order, releasing it, and then posting it only has one commit, at the end of posting, so it would be rolled back, right?

[rznd]

Actually, codeunit 80 has at least one commit before posting, inside function CheckAndUpdate.