The M2M attributes after_states and before_states declare which biotope states existed before and after changes due to the data type (compensation, ema, ecoaccount).
If the calculated sum of surfaces on each attribute differ from one another, the user is being informed on the detail view directly and again on a check or record action. Checking and recording of an entry is not possible as long as there is such a logical error on the entry.
However, there seems to be some irritation, since there can be valid situations where unequal before and after state surface sums exist.
First it needs to be determined (from experts) whether these situations are tuly valid or if there is a misunderstanding between users (from the past on the old system) and the experts.
Improvement
*An improvement will be formulated once the situation is more clear. *
# Status quo
The M2M attributes `after_states` and `before_states` declare which biotope states existed before and after changes due to the data type (compensation, ema, ecoaccount).
If the calculated sum of surfaces on each attribute differ from one another, the user is being informed on the detail view directly and again on a check or record action. Checking and recording of an entry is not possible as long as there is such a **logical error** on the entry.
However, there seems to be some irritation, since there can be valid situations where unequal before and after state surface sums exist.
First it needs to be determined (from experts) whether these situations are tuly valid or if there is a misunderstanding between users (from the past on the old system) and the experts.
# Improvement
*An improvement will be formulated once the situation is more clear. *
After discussions with experts this issue is not an issue. The system must hold data on the surfaces before and after a change and they must be equal. The depiction of biotope surface usage might be a misunderstanding derived from the point based biotope calculation manual, published by the MKUEM.
Nothing to do here.
After discussions with experts this issue is not an issue. The system **must** hold data on the surfaces before and after a change and they **must** be equal. The depiction of biotope surface usage might be a misunderstanding derived from the point based biotope calculation manual, published by the MKUEM.
Nothing to do here.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Status quo
The M2M attributes
after_statesandbefore_statesdeclare which biotope states existed before and after changes due to the data type (compensation, ema, ecoaccount).If the calculated sum of surfaces on each attribute differ from one another, the user is being informed on the detail view directly and again on a check or record action. Checking and recording of an entry is not possible as long as there is such a logical error on the entry.
However, there seems to be some irritation, since there can be valid situations where unequal before and after state surface sums exist.
First it needs to be determined (from experts) whether these situations are tuly valid or if there is a misunderstanding between users (from the past on the old system) and the experts.
Improvement
*An improvement will be formulated once the situation is more clear. *
Unequal stare surfaces possibleto Unequal state surfaces possibleAfter discussions with experts this issue is not an issue. The system must hold data on the surfaces before and after a change and they must be equal. The depiction of biotope surface usage might be a misunderstanding derived from the point based biotope calculation manual, published by the MKUEM.
Nothing to do here.