Здравствуйте, welvist, Вы писали:

W>В том то вся и фишка, что еще хотят аудит манипулирования историей. А редактирование истории должно быть для возможности исправить ошибку.

W>Система исключительно ручного ввода данных. Факт выполнения чего-либо производится на бумаге. А в программе затем фиксируется согласно бумаге.
W>По сути система складского учета. История нужна якобы для расследований, а также для анализа.

Видится два варианта: один без отката изменений, второй с откатом.

Вариант 1 (простой, без отката изменений).
Если появляется ошибка, то в программу вводят операции, исправляющие эту ошибку, с какой-нибудь пометкой — типа "сторно". История хранит, как исходные операции, так и сторнирующие.

Пример истории:
1. Приход на склад А.
2. Перемещение с А на склад Б.
3. Перемешение с Б на склад С.
4. Перемешение с С на склад А. (сторно — анулирование документов 2 и 3).

Т.е. для исправления ошибки был введен еще один документ (номер 4), что и было отражено в истории.

Плюсы такого подхода:
— можно посмотреть все операции с объектом (обычные, ошибочные, а также исправления этих ошибок)
— легко реализовать (нужно хранить только последнюю версию объекта плюс длинную историю)

Вариант 2. По аналогии с 1С Предприятие.

Каждое перемешение — некий документ, который вносится в программу.
Документ может быть "проведен", тогда изменения отражены в базе, или "не проведен", тогда документ в базе есть, но изменения в базе не отражены.

1. Приход на склад А. (здесь ошибка — должно быть на склад Б)
2. Перемещение со склада А на склад Б.
3. Перемешение со склада Б на склад С.

Для исправления ошибки необходимо отменить проведение документов до ошибки. Потом исправить ошибочный документ и перепровести все остальные.
Т.е. отменить документы 2 и 3, потом исправить документ 1. Затем нужно перепровести документы 2 и 3. Вот здесь и вылезет ошибка, т.к. документ 2 не сможет быть проведен, т.к. на складе А объекта уже нет. Пользователю придется эту ситуацию разрулить.

Проблема здесь в "отмене проведения", т.е. к возврату к исходному состоянию. Проще всего хранить все версии объекта на соответствующие даты. И "вычеркивать" ненужные строки при отмене проведения. Для оптимизации отделять текущую версию объекта от предыдущих.

Реализовать этот вариант сложнее. К тому отмененные версии могли использовать в других местах системы и их тоже надо откатывать, т.е. придется хранить еще и эти связи в системе.
В общем, нужно строить целую инфраструктуру для этого.