RKAБывают ситуации, когда в операции ввели ошибочные данные. Самое ожидаемое решение этой проблемы: откатить операцию, ввести правильные данные и выполнить заново. Но это не всегда возможно (по многим причинам). И вообще, насколько откат операций - это правильно, нужен ли он в принципе, или можно обойтись без откатов?

А как без отката, если как Вы правильно заметили ввели некие данные ошибочно? А если после месяца работы, поняли что настроили проведение операции немножко не так как хотелось бы? Самый быстрый способ-это перепровести все операции за данный период. Ну в самом деле, не гемороиться ведь со сторно, как это практикуют в Аксапте... Кроме пухнущей как на дрожах БД вы ничего при этом не поимеете...
А что это за многие причины, по которым не всегда возможно сделать откат операции? Ну кроме организационных конечно....
Насчет правильности-вопрос философический. Сильно зависит от вида бизнеса...
Где то требуется только сторно, а где то гораздо проще и быстрее перепроводкой.
Все ИМХО:)

Guest11
Запрет откатов у западников популярен. SAP тоже практикует подобную методику. Специально не вдавался в вопрос "зачем", но логика вроде такая - "чтоб все, что сделано, было видно. Усегда!". Типа данные не потеряются.
Россияне в этом плане гибче. Что правильней - ХЕЗ. Флейма - не будет? :)
Здесь понятие правильней не "проходит". Вернее его нужно рассматривать с точки зрения конкретной задачи, а не вообще... Так что темы для флейма нету:-)
Другое дело, правильнее, когда система позволяет и тот и другой способ, а не "заточена" только под один!

bI-KyКак только в бизнес-процессе (не только в учетной системе) могут быть порождены данные, ссылающиеся на неверную запись, ее необходимо фиксировать и компенсировать только посредством сторнирования. Переживать при этом за "пухнущую базу" уж точно не стоит.
Хоть один довод в пользу фиксирования этой записи и сторнирования ее? Вам мало мусора в БД? Зачем это нужно, если оператор например просто ошибся в одной цифре, а это часто случается в процессе ввода большого объема информации. Просто видеть какой у Вас нехороший оператор, что так часто ошибается? Так для этого история есть, которую кстати вообще можно хранить в другой БД и на объем рабочей БД она никак не повлияет...

Чуть Выше я привел пример, когда организация, после месяца, двух, трех .... работы, решила перестроить алгоритм проведения пусть не всех, но хотя бы парочки видов операций. Замечу, данные в этих операциях верны, ошибок нет. Но правила проведения(проводки) решено поменять. Что будете делать? Продублируете их все?:-)
Я просто перепроведу операции...

Я описал частные случаи, но они имеют место быть, и сами клиенты часто акцентируют свое внимание именно на возможности перепровести операции "в случае чего"... Естественно, не отрицаю возможностей сторнирования. Здесь сам клиент диктует политику и это правильно, у него должен быть выбор, а не однобокое видение(пусть даже неверное) проблемы разработчиком, только потому, что его система по другому не умеет...

!!! OTigerорганизация, после месяца, двух, трех .... работы, решила перестроить алгоритм проведения пусть не всех, но хотя бы парочки видов операций. Замечу, данные в этих операциях верны, ошибок нет. Но правила проведения(проводки) решено поменять.Лихой бизнес-процесс! А отчеты, построенные на данных проводок, на основании которых принимались решения и, собственно, эти решения - тоже откатить?
Ну зачем так глупо то? :) Ну как дети малые...С чего Вы решили, что кардинально поменяются все проводки? Может просто понадобилось добавить парочку проводок, они картину бизнеса не меняют вообще, это просто еще одни дополнительные показатели для удобства работы. Не всегда организация способна на 100% правильно настроить все необходимые показатели, особенно при внедрении новой системы. Многое "приходит" во время работы... Это нормальная практика. Все мы человеки, а не машины...:)

777777777 LSV Другое дело, правильнее, когда система позволяет и тот и другой способ, а не "заточена" только под один!Чистая правда ! Зачот !
Двойной зачот, если это регулируется правами!
А что, бывает по другому? :-)

bI-Ky LSV К сожалению, мне непонятно, о чем идет речь. Об экстремальном программировании и горячем рифэкторинге?Что же тут непонятного ? Ну решили люди улучшить аналитику, добавили пару-тройку субсчетов, появились новые бух-нюансы у предприятия.
Непонятно, какое отношение, в таком случае, эта история имеет к обсуждаемой теме.
Самое прямое, ибо, если к решению "улучшить" аналитику организация пришла через месяц-два с начала года, например, то необходимо перепровести операции за эти месяц-два, чтобы появились циферки на упомянутых субсчетах. Ну и дальше работать уже с учетом новой аналитики.

iscrafmOTiger и bl-Ky, вы просто делаете акцент немного на разных понятиях, причем оба, на мой взгляд, правильный.

Вот это абсолютно верно:
"Как только в бизнес-процессе (не только в учетной системе) могут быть порождены данные, ссылающиеся на неверную запись, ее необходимо фиксировать и компенсировать только посредством сторнирования".
Действительно, если цепочка данных в БП уже построена, делать откаты с корректировкой данных становится весьма проблематично и в общем неверно. Простой пример:
Приход товара - > Карточка партии - > Расход
Это утрированно схема партионного учета в ценах поставщика. В момент прихода товар фиксируется по указанной в СФ цене. Далее делается отпуск со склада. Отпускная цена вычисляется как Цена поставщика + НДС в стоимость сырья + Наценка. НДС, естественно - поставщика. Наценка фиксированная и не может быть более определенного значения (серьезное нарушение). Товар отгружен. Через некоторое время оператор видит что в приходном документе допустил ошибку при вводе спецификации. Последствия отката и корректировки всей цепочки DataFlow: наценка может получиться более предельного значения (это серьезно) и , конечно, несоответствие документов переданных потребителю и текущего состояния данных в системе. Если же не корректировать всю цепочку, то через некоторое время база данных становиться похожа на мусорную свалку.

Ситуация о которой говорит OTiger напрямую никак не связана с внешним миром: документы потребителям не передаются, записи проводок всего лишь представление данных документов, которые зарегистрированны в системе и т.д. Поэтому вполне разумно не ограничивать привелигированных пользователей системы в возможности, например, добавить новый вид аналитики и переформировать все проводки за 5 лет. Это не XP и не горячий рефакторинг - это обычная человеческая потребность изменить взгляд на состояние дел, посмотреть на них в других срезах. Просто масса примеров когда это требуется.
Ну и конечно, исправление ошибок не связанных ни с DataFlow, ни с учетной политикой.

В общем все правильно, только о разных понятиях.

Ну так я вообщем то изначально заявлял, что оба подхода имеют право на жизнь, нужно лишь дать пользователю право выбора. Я ведь не делал заявлений, типа сторно это бред, нужно только перепроводкой пользоваться:)

bI-Ky OTiger bI-KyНепонятно, какое отношение, в таком случае, эта история имеет к обсуждаемой теме.
Самое прямое, ибо, если к решению "улучшить" аналитику организация пришла через месяц-два с начала года, например, то необходимо перепровести операции за эти месяц-два, чтобы появились циферки на упомянутых субсчетах. Ну и дальше работать уже с учетом новой аналитики.
А я вот считаю, что к вопросу "править ошибочные записи или сторнировать" разнесение каких-то там проводок по субсчетам не имеет ни малейшего отношения. Особенно этот конкретный пример выглядит нелепо - как будто при разнесении по субсчетам общий счет (который был прежде максимальной детализацией) изменится. Кроме всего прочего, вообще непонятно, почему такой упор именно на "проводки", которые, собственно, не являются первичными записями и в большинстве своем создаются автоматически на основании других данных.

Так проводки и создаются на основании данных, которые хотят поправить:)
Мы хотим поправить уже проведенный(проводки уже по нему созданы) документ(операцию). Для этого и необходимо его распровести(удалить проводки), поправить и провести заново(создать проводки).

bI-Ky OTigerТак проводки и создаются на основании данных, которые хотят поправить:)
Мы хотим поправить уже проведенный(проводки уже по нему созданы) документ(операцию). Для этого и необходимо его распровести(удалить проводки), поправить и провести заново(создать проводки).
Диалог о Фоме и Ереме. Что ж Вам дались эти проводки. Бизнес-трансакция включает в себя множество взаимосвязанных действий. И это вовсе не обязательно записи в БД и, тем более, примитивный бухучет. Если бы "откат бизнес-операции" (см. топик) вызывал лишь пересоздание проводок этой самой операции, обсуждать было бы нечего.
Так это зависит от реализации самой системы. Ничего лучше проводок пока никто не придумал. И не зацикливайтесь на бух. проводках, проводки бывают разные. Мы например ВСЕ учеты строим проводками, и ничего кроме проводок бизнес-транзакция не создает. Это очень удобно с точки зрения универсальности. Нам в принципе по барабану какой бизнес автоматизировать. У нас нет отдельных модулей. Все настраивается в логике шаблонов операций. Но это мы от темы отошли:)

bI-Ky
Возможно, есть взаимное недопонимание - в данном случае под "сторно" мной подразумевается не бухгалтерское создание "красной записи" в проводках, а корректирующая операция в бизнес-трансакциях вообще.
В нашем понимании - это в итоге теже проводки, которые плюсуются к проводкам сторнируемого документа. В итоге мы с Вами получим одинаковые цифры, но в Вашем случае в базе будет больше "лишних" данных... Вот и вся разница. Хотя и у нас есть возможность создания сторно...

bI-Ky
Что касается разницы в подходе к исправлениям у "западников" и россиян - просто есть нормальная учетная политика, основные принципы которой выработаны веками (!), а есть российское раздолбайство с подчистками и активным использованием незаменимого бухгалтерского средства "Штрих".
Причем тут раздолбайство, поверьте, у западных компаний раздолбайства не меньше чем у нас, не идеализируйте. Просто есть реалии бизнеса, когда без отката операций не обойтись. Примеров можно назвать массу. Почитайте тот же AXForum и другие подобные, там огромное кол-во вопросов связанно именно по данной тематике, значит проблема все таки существует и она весьма остра. Там правда отвечают в Вашем же стиле, но это просто потому, что по другому они не умеют делать...:)

P.S. Еще раз, я не агитирую только за технологию отката операций, я лишь говорю о том, что у пользователя всегда должен быть выбор. Вы же пытаетесь нас убедить в том, что "откат" не нужен, все необходимо делать сторнированием. Видимо причина таже, Ваша система по другому просто не умеет. Но это не значит что такой подход не имеет право на жизнь.:)