Практически ни разу не встречал в описании на учетные системы акцента на алгоритм указанный в теме.
Похоже ВСЕ учетные системы при отражении фактов хоз. деятельности, кроме регистрации параметров события формируют сводные значения, используя имеющиеся данные и данные определенные событиями предшествующих периодов. Кроме того алгоритмы обработки текущих событий также могут использовать те же сводные значения. Пожалуй таким, самым распространенным параметром является складская цена ТМЦ. Все это прекрасно работает при условии введения новых значений "поверх" существующих. Что происходит когда изменяюся параметры данных в прошлом? Будем иметь в виду параметры оказывающие влияние на будущие периоды, а также операции ссылающиеся на сводные итоги по таким параметрам. Для примера приведу решения реализованные 1С-е. Кроме явной отмены и последующего нового проведения требуется следующая фоновая поддержка:
1. Для перепроведения документа в прошлом нужна подгонку зависимых сводных значений на этот момент. Это так называеиый временный расчет.
2. Поскольку по факту перепроведения может быть нарушена актуальность документов проведенных выше точки вмешательства, задействуется механизм последовательностей, который повторит процедуру пункта 1 для всех документов включенных в последовательнось.
3. Документы использованные в последовательности могут исказить актуальность документов других последовательностей. Придется повторить процедуру 2.
Подводные и надводные камни этого решения. Исполнение пункта два в рукопашном и похоже в монопольном режиме. Формирование последовательностей основано на человеческих факторах и не гарантирует достоверной отчетности по системе в целом. Ресурсы затрачиваемые при этом могут достич критических значений.
Хотелось бы услышать от уважаемой публики: Как еще в мире решена, решается или может быть решена проблема сабжа?

Сисой
И в 1С это, кстати, тоже довольно легко реализуется.
В основном административными мерами.

Меня в общем то интересуют алгоритмические решения, а не административные.

iscrafmАлгоритмически:
- Проверить возможность отката
- Если возможно, выполнить каскадный откат, после правки выполнить повторный постинг
- если откат запрещен - предложить сторнирующие записи.

Сторнирующие записи - это наследие возможностей бумажного учета?

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

GaryaКак вы "перепроведете" документы, в которых цена ранее уже была посчитана, документы выданы на руки клиентам и эти клиенты разъехались по странам и весям?
Хвала всевышнему :)
Речь не шла об изменениях параметров документа введенных непосредственно оператором. Имелась в виду себестоимость/цена списания, которая извлекается системой самостоятельно. Вот она то при вмешателство в прошлое и может оказаться не актуальной для более поздних по оси времени операций.

sobolev
www.petroglif.ru
Весь учет ведется без каких-либо предположений о том, что документы проводятся текущим числом. Другими словами, система инвариантна к дате проведения документа.
Все проверки и пересчеты осуществляет "на лету". Остаток товара по лотам контролируется на ненулевое значение для каждого момента времени. То есть, если вы проводите документ задним чилом, и после проведения остаток в какой-либо момент станет отрицательным, то система выругается и не разрешит проведение. Если все ОК, то все пересчеты будут выполнены автоматически и очень быстро.
Это в контексте контроля на отрицательный остаток, формализуемая задача, а как быть с ценой при списании по средневзвешенной? Она будет порушена если меняется остаток на момент очередного приходования, который выше операции проведения/перепроведения, и увы, тоже в прошлом.
sobolev
Это касается как товарных остатков, так и бухгалтерских проводок, связанных с документами - все пересчеты оборотов и остатков по счетам делаются автоматически. Вот я и пытаюсь добиться ответа каким образом. Вижу пока только два способа: как в 1цэ, врукопашную, по заранее подготовленным последовательностям зависимых документов или тотальный перерасчет по всем документам, во втором случае по меньшей мере нет необходимости юзать временные расчеты на каждый перепроводимый док.

iscrafm
Все зависит от того, какой процент рентабельности заложен в продажную цену товара. Это просто пища для размышления при анализе эффективности продаж, не более. Что Вас так смущает? Бывает и за три года себестоимость пересчитываем, ничего страшного, кроме 5 минут ожидания. Главное бух. не трогать.
Почему в СССР не продавалась красная икра в магазинах? Небыло спроса, никто не спрашивал. :)
Рентабельность не есть заложенная величина. Она плавает в зависимости от значимости клиента, курса валюты расчета, настроения манагера и тд. и тп. На счет пищи для размышлений тоже пожалуй не соглашусь. Оперативный и точный анализ эффективности может оказаться востребованным для оценки деятельности манагеров в реальном режиме времени, есть варианты совмесной хоз. деятельности по отдельным группам/товарам, да мало еще что.
Эффективность приведена просто как показатель проблематичности получения достоверных показателей системы в режиме близком к реальному. Вот хочется в принципе как в 1С, только автоматически и в 1000 раз быстрее. Когда будет в 1000 раз быстрее и с автоматически проблем не будет. :)

GaryaВ примере, который я привел чуть выше, как раз о цене списания и идет речь. Она может измениться, если добавить задним числом еще один приход или расход, стараясь при этом соблюсти принцип FIFO (или LIFO). Если "на лету" по ценовым параметрам принимаются какие-то принципиальные решения (как я привел выше), то любое перепроведение задним числом может потребовать пересмотра этих решений.
Все пральна.
Вы ранее выдали: "документы выданы на руки клиентам и эти клиенты разъехались по странам и весям", вот я и подумал, что мы о разном.

iscrafm
Это Вы на себестоимость реального времени делаете упор? Это периодический показатель. Какое реальное время. Зачем искать проблемы, там где их нет?
Ммм. Я делаю упор на ПРАВИЛЬНУЮ себестоимость на сейчас.
Давайте на пальцах. Получили контейнер импортной бадяги. Стоимость (цены) известны только согласно инвойса поставщика. Товар по приходованию продается, как говорят, с колес. Стоимость доставки, таможенной очистки станет известна ч/з 3-4 дня. В операции "наживы" участвуют два чела. Один дал деньги, второй ввез и продает. Договорились маржу пополам. Ну и вот честный дерибан можно осуществлять по мере продажи партии , но не раньше чем будут актуализирована себестоимость во всех продажах. Посему точные цифры могут быть получены только после введения в себестоимость дополнительных затрат и перерасчета ВСЕХ операций продаж в которых эти товары учавствовали. Так вот в актуальное состояние показателей хочется верить сразу же после после операции актуализации приходования, а не после того как кто то ночью сделает перерасчет по всем зависимым операциям продаж.