Читал один топик . Там всё на спирте объяснено. Понравился подход. Поэтому тоже буду объяснять на ём же, родимом.

Итак, задачка:
1. Имеется спирт. Спирт может быть разных марок (люкс, экстра, самопал, ...).
2. Имеются некие склады, на которых расположены ёмкости. В одну ёмкость можно заливать спирт только одной марки и весь спирт одной марки на складе содержится в единственной ёмкости.
3. Имеется некое приложение, которое учитывает круговорот спирта по ёмкостям, но операторы не всегда внимательно вносят данные.

Теперь сценарий действия, приведший к ошибке учёта:
1. Оператор по ошибке вбил неверную марку при поступлении 100 литров спирта. В результате, в базе данных произошло пополнение литража не в той ёмкости (Б вместо А).
2. Потом оператор "перелил" из ёмкости Б часть спирта в ёмкости В и Г на других складах. Из ёмкости Г часть спирта "перелил" в ёмкость Д ещё на одном складе и т.д.
3. При ревизии обнаружили, что при поступлении была указана не та марка, следовательно, нужно отредактировать операцию поступления, и, возможно, движение по другим складам.
Проблема в эскалации ошибок. Сначала оператор ошибся при поступлении. Потом утвердил свой косяк, переместив часть спирта не из той ёмкости и т.д. А когда очухался, оказалось, что не понятно куда разошёлся уже этот спирт и как исправлять.

Внимание, вопрос:
Каким образом реализовать понятное пользователю редактирование операций движения спирта?

boottyМожет, сторно всех некорректных операций (текущей датой) спасет?
Как выявить все некорректные операции?
Автоматически пройтись по графу распространения ошибки и выдать пользователю все операции, которые могли быть "подпорчены" этой ошибкой, а после этого пусть пользователь сам думает, что и как сторнировать? Или что-то ещё можно предложить?

Kirill Razuvaev
>> Каким образом реализовать понятное пользователю редактирование операций
>> движения спирта?
IMHO, проще административными мерами добиться правильного ввода данных, чем
пытаться локализовывать чужие ошибки. К тому же, их уровень и порядок -
неизвестны. Открывая же механизмы для правки, вы рискуете не только сугубить
ситуацию в случае ошибки при исправлении, но и откроете путь для откровенных
махинаций. Не стоит также забывать о том, что человек, который знает, что от
его ошибки "никто не умрет", перестает ответственно относиться к своей
работе.


Согласен, но человеку свойственно ошибаться, а его начальнику свойственно требовать сходящихся отчётов. Раз свойственно ошибаться, то система должна позволять как-то исправлять свои ошибки.
И ещё: есть вариант, что исправлять ошибки будет не пользователь, а некий технолог сопровождения. И этому сопровожденцу нужен инструмент для редактирования.

boottyВячеслав БанкетboottyМожет, сторно всех некорректных операций (текущей датой) спасет?
Как выявить все некорректные операции?
Автоматически пройтись по графу распространения ошибки и выдать пользователю все операции, которые могли быть "подпорчены" этой ошибкой, а после этого пусть пользователь сам думает, что и как сторнировать? Или что-то ещё можно предложить?Алгоритм примерно такой и предложил бы.

Возможна ситуация, когда достаточно будет сторнировать только источник ошибки:
1. Привезли 100 л спирта в емкость А
2. Записали все 100 л в емкость Б (в которой было, скажем, 1000 л)
3. Перелили из Б в Х 500 л
4. Перелили из Х в У 300 л и т.п.

Достаточно сторнировать запись 2, сделав -100 л из Б и +100 л в А. На остальные перемещения это не влияет. Можно даже частично автоматизировать процедуру исправления, предлагая несколько вариантов сторон на выбор.

Да, в таком случае ошибка не распространяется. Это частный случай. А вот если бы в ёмкости Б было изначально 700-799 литров, то что в таком случае делать? Ошибка распространилась на следующие переливания...

bootty
Если, при каждом "переливании" объем измеряется, то в данном примере не получится взять больше, чем там есть по факту (1000 л). Поэтому достаточно будет одной сторнирующей операции. В тот момент, когда либо из Б попытаются взять больше факта (что вероятнее), либо из А возьмут под ноль остаток по базе, а там останется еще 100 л.

При "переливании" объём не измеряется, мало того, объём могут пополнять из других источников. Так что, исключительная ситуация, когда "из Б попытаются взять больше факта" может проявиться не скоро.

При "переливании" объём не измеряется. Могут происходить замеры при ревизии, которая происходит с некоторой периодичностью, бывают случаи внеплановой ревизии.

Александр Гoлдун
Как-то приходится выкручиваться ручными постепенными обратными "микрокоррециями". Такое исправление некоторых ошибок затягивается на месяца и более.
А вы говорите "эксплуатировать невозможно"
Поделитесь опытом, как "микрокоррекциями" исправлять данные, не вводя систему в инконсистент?
Допустим, со склада А записывают ошибочное перемещение на склад Б 100 литров метилового спирта. Т.е. на складе А - минус 100 литров метилового, а на складе Б - плюс 100 литров его же. На самом же деле, перемещали не метиловый, а этиловый.
Спустя несколько дней (недель/месяцев/лет), оператор на складе Б замечает, что у него в реале есть 100 литров этилового спирта, но отсутствует 100 литров метилового. Оператор на складе Б делает корректирующие операции: минус 100 литров метилового, плюс 100 литров этилового. Баста! На его складе всё замечательно. До других ему дела нет.
Получаем систему в инконсистенте: этилового спирта в ходу больше, чем поступало; метиловый куда-то делся.