В большинстве ERP систем изменение разнесенных данных запрещено и для изменения используется механизм сторнирования, т.е. исправление не самой ошибки, а ее последствий. Этот механизм должен быть очень "интеллектуальным". Например: поступили 2 месяца назад материалы. В настоящее время часть еще на складе сырья, часть в НЗП, часть вошла в продукцию и уже продалась. Если только сейчас "всплывет" документ допрасходов (транспорт, таможня и т.п.) на эту партию, понятно, что недостаточно просто завести его в систему. Необходимо корректно "развесить" затраты на материал и продукцию. И так как в прошлом может измениться что угодно, необходимо корректно отразить последствия "чего угодно" в текущем периоде (или отказать пользователю, если например, остатки ушли в минус). На форуме не нашел описаний как практически выполняется сторнирование в конкретных программах. Был бы очень признателен за описание или ссылку.
Также интересно сравнить "комфортность" механизмов сторнирования в различных ERP. Насколько они "всеядны" к любым изменениям задним числом, можно ли в отчетах за прошлые периоды или актах сверки с контрагентами включать/отключать результат сторнирования и т.п.?

То Aleksiya. Спасибо за развернутый ответ, вроде немного прояснилось. Но еще вопросы. Я правильно понял, что сторнирующий документ хранит две даты: текущую и для расчетов? Для учета сторно используется штатное закрытие месяца или специальный механизм? Надо всегда все полностью пересчитывать или есть возможность рассчитать последствия конкретного сторно? Если изменение произошло 2-3 месяца назад нужно последовательно пересчитывать 2-3 месяца или есть возможность сделать это "оптом"?
Постараюсь объяснить проблему с включением/отключением показа результата сторнирования. По данным системы выпускают бумажные документы для внешних потребителей (контрагенты, госорганы, акционеры и т.п.) или учитывают входящие от них. При обнаружении в них ошибок есть два варианта исправления: перевыпуск исправленных документов или учет ошибок в последующих периодах. И этот способ зависит от договоренности с контрагентом. В зависимости от того закрыт у него период или нет, он может настаивать на одном из вариантов... При просмотре отчетов за прошлые периоды пользователю удобно видеть результаты с учетом сторно, но он не должен забывать, что многие данные фактически числятся на другую дату и для подготовки отчетности, например в налоговую, он должен брать данные без учета даты сторнирования. В общем много нюансов использования сторнирования ...
ЗЫ.Мне тоже нравится удобная возможность внесения изменений непосредственно в разнесенный документ и даже знаю систему, где это штатная возможность :), но в которой начисто отсутствует механизм полноценного сторнирования данных из закрытых периодов :(.

MX -- ALEXНе подскажете что за система ?
Эта система вовсю обсуждается в соседней ветке. И очень не хотелось чтобы здесь создался филиал того обсуждения.
Все таки хочется подробностей описания конкретных действий, когда (skeptik правильно уточнил мой вопрос), стало известно, что данные в закрытом периоде (неважно по какой причине) не соответствуют действительности, а все исправления можно делать только в текущем периоде.
Для затравки опишу реальную ситуацию. В Русале есть группа учетчиков, основная задача которых - подготовка управленческой отчетности руководству. Нормативы: к 7 числу выдается отчетность о международной деятельности за предыдущий месяц. Это гааповская отчетность плюс больше сотни специальных отчетов. Большинство из них связаны с себестоимостью продукции. Есть, например, такие: список поставщиков, которые поставили бокситы, которые пошли на производство глинозема, который пошел на производство первичного алюминия, который пошел на производство конечной продукции, которая была продана в отчетном месяце. Т.е методом "антиФИФО" надо раскрутить всю цепочку общей длиной в несколько месяцев. Сами учетчики "сидят" в отдельной БД и большую часть первички не вводят, а закачивают из других систем. Первая проблема: в этих системах происходят изменения данных задним числом (десятки в месяц). Вторая проблема: многие документы (транспорт, таможня т.п.) приходят через 1-2 месяца. Это еще несколько сотен исправлений в месяц. Естественное пожелание руководства - входящее сальдо текущего баланса = исходящее предыдущего. Все корректировки только в текущем периоде. Цена неучтенной ошибки высока - десятки миллионов долларов. Документооборот тоже немаленький. Изменение стоимости одной партии входящего сырья - больше сотни сторнирующих записей через месяц... В рамках решения задачи выдачи отчетности проблемы удалось минимизировать на самописной конфигурации, но для других видов учета она не подойдет. Поэтому и интересны универсальные способы борьбы ERP с массовым непредсказуемым прошлым.