svcoder1) коррекция документа задним числом, как требует российский бухучет
Нет такого в ПБУ. Мало того, есть запрет на редактирование.
Другое дело "сложившаяся практика" позволяет корректировать пока не сдали отчеты, а то и после сдачи.

Но в результате.ю все на предптиятии знают, что пока не сдали отчеты бух.данные не могут считаться правильными и окончательными. А то и после сдачи.

svcoderПочему в западных системах не практикуется подход, когда допускается коррекция исходного документа задним числом
Почему не практикуется? Есть в итальянских бух.системах, есть в бразильских, есть в системах для учета домашних финансов.

Т.е. есть там, где не нужна достоверность данных.

Скорее всего, в данном вопросе под "западными ИС" понимаются ЕРП-системы, изначально созданные в интересах владельцев бизнеса. Это значит, что данные должны быть достоверными и актуальными в любой момент времени, а не "после сдачи".

reddДругое дело, что практически опция "гладкого" изменения документа задним числом очень привлекательна для пользователей.
Для каких?
Впрочем, правильно заданный вопрос содержит половину ответа: обратите внимание, не для контролеров, не для людей-принимающих-решения, не для владельцев. для ПОЛЬЗОВАТЕЛЕЙ.

reddС другой стороны, сложности практической реализации заставляют многих вендоров утверждать, что такая опция вредна.
Концепция вредна не из за сложности реализации, а из-за изначальной логической порочности.

Итак, есть:
1. МНОГОПОЛЬЗОВАТЕЛЬСКАЯ система
2. Пользователь А
3. Пользователь Б
4. Другие пользователи

Пользователь А вводит и проводит (разносит\учитывает) некий документ.
Информация этого документа попадает в какие-нибудь регистры\своды\итоги и влияет на входящую информацию для пользователя Б.
Пользователь Б на основании входящей информации создает свои документы и свои действия.
Пользователь А изменяет свой документ.

Правильные ли действия совершил Пользователь Б?
Откуда Пользователь Б узнает, что созданные им документы ни черта не актуальны?
Если пользователю А разрешить править свои документы, то как и когда пользователь Б сможет узнать, что теперь то он может создавать свои документы?

Теперь доводим сложность до нормальной. у нас несколько десятков\сотен пользователей, действия которых взаимосвязаны. Можно ли гарантировать, что они пользуются актуальной информацией и выполняют правильные действия, если они могут менять проведенные документы?

redd mazzyДля каких?
Впрочем, правильно заданный вопрос содержит половину ответа: обратите внимание, не для контролеров, не для людей-принимающих-решения, не для владельцев. для ПОЛЬЗОВАТЕЛЕЙ.

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

mazzy
Концепция вредна не из за сложности реализации, а из-за изначальной логической порочности.

Итак, есть:
...

Теперь доводим сложность до нормальной. у нас несколько десятков\сотен пользователей, действия которых взаимосвязаны. Можно ли гарантировать, что они пользуются актуальной информацией и выполняют правильные действия, если они могут менять проведенные документы?

reddАбсолютная актуальность информации - фикция. Физики смирились с неопределенностью, попробуйте и вы.
А где я говорил об абсолютной?
Думайте дальше.

redd- Пользователь А корректирует Д1, и система позволяет ему это сделать, но в пределах, не приводящих к противоречивости Д2.
Ну, началось. Давай вводить на ходу новые условия и функции...
Сформулируйте свою мысль от начала и до конца что должна позволять система и при каких условиях.
В общем, думайте дальше.

reddТеперь все сначала: чем плохо, что ошибка в документе будет исправлена задним числом, при условии, что система проследит за непротиворечивостью данных и сохранит версию документа, предшествующую изменению?
Давайте, думайте.
Что значит "система проследит"?
Что значит "система сохранит"?
Раскройте эти умолчания и вам самим станет ясно "чем плохо".


=======================
svcoder
mazzy
Скорее всего, в данном вопросе под "западными ИС" понимаются ЕРП-системы, изначально созданные в интересах владельцев бизнеса. Это значит, что данные должны быть достоверными и актуальными в любой момент времени, а не "после сдачи".


Именно они и понимаются, так как больше всего изменения задним числом влияют на функции планирования. Но при чем здесь достоверность данных. Я разумеется имею ввиду ситуацию, когда хоз операции заносится в момент их возникновения, а не в конце месяца
Ну, почему же только планирования?
На функции контроля еще как влияет.

Пример:
1. продавец выписал документ на 100 рублей
2. склад отпустил по этому документу товар на 100 рублей
3. продавец исправил документ на 80 рублей
4. клиент оплатил 80 рублей.
Кто виноват в том, что на складе не хватает 20 рублей?
Как это показывает система, если в ней допустимы правки уже проведенных документов?

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

======================
LunxХрм. В SAP R/3 - пожалуйста, если период открыт - можно постировать любые проводки в пределах периода. Вопрос закрытия или открытия периода находится (по крайней мере у нас) в компетенции глав. буха. Говорить о том, что запрет на создание документов задним числом в западных ERP - некоторое лукавтсво. Если открыть прошлый период (а эти делается счелчком пальцев) - пожалуйста - проводите на здоровье.
Вы не поняли. Вопос был про ПРАВКУ уже постированных.
Создавать новые документы задним числом никто не запрещает.
Мало того, буржуйские системы разрешают и явно обрабатывают новые документы задним числом, чтобы было правильно. Это входит в бизнес-процесссы.

А в некоторых системах, в которых разрашена правка, предполагается, что все документы вводятся в хронологическом порядке, а специальная обработка новых заднечисловых отсутствует. Зачем, если можно поправить?

John 3Volta mazzy svcoderПочему в западных системах не практикуется подход, когда допускается коррекция исходного документа задним числом
Почему не практикуется? Есть в итальянских бух.системах, есть в бразильских, есть в системах для учета домашних финансов.

Т.е. есть там, где не нужна достоверность данных.
"Возхохотамше под лавкою" :)
Вот где надо работать - в Италии или Бразилии. Где не нужна достоверность данных :)
Для владельцев - нужна.
Но "по законодательству" у них точно так же как и у нас.

John 3VoltaА если серьёзно - нельзя править документы задним числом. Вот как можно приавить цену прошлогоднего прихода сырья, если само сырьё уже израсходовано в производство, а полученная готовая продукция давно продана клиенту?
Вы тоже путаете.

Это похоже специфика 1Совсцев, что только они этот вопрос воспринимают сразу... Перечитайте внимательно - ПРАВИТЬ уже проведенные документы. Вдумайтесь. Не создавать НОВЫЕ, а править уже существующие.

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

Еще раз повторю, что с точки зрения проклятобуржуинских программ, это нормальная ситцация по нормальному бизнес-процессу. Они поведут себя так: сначала продают товар по той себестоимости, которая есть на текущий момент (даже по 0), а потом, когда появились НОВЫЕ КОРРЕКТИРУЮЩИЕ документы, ДОБАВЛЯЮТСЯ КОРРЕКЦИИ до правильной себестоимости.

Внимание! уже проведенные документы НЕ ПРАВЯТСЯ. Добавляются НОВЫЕ КОРРЕКТИРУЮЩИЕ. Для новых запоминается кто, когда и зачем их ввел.

Что спрашивают апологеты изменений в проведенных документах?
Они спрашивают: у меня была приходная накладная с ценой. А потом я получил уточнение цены. Как я могут ИСПРАВИТЬ приходную накладную?
Ошибка в логике: надо не ИСПРАВИТЬ, до создать НОВЫЙ корректирующий. Тогда остается и первоначальная информация, и корректирующая, и итоговая.

George NordicКстати, существует миф, что в западных системах нельзя работать задним числом. Причем настолько устойчивый, что иногда (особенно при демонстрации финансовому деп...э-э-э бухгалтерии ;) ) приходится демонстрацию Dynamics AX (Axapta) начинать с того, что показывать, как 1 кликом мыши перевести рабочую дату и начать работать каким угодно числом.
Э-э-э.
И ты на эту удочку попался.

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

Когда другие (не 1Совцы) говорят о работе задним числом, то говорят именно о внесении и корректной обработке новой корректирующей информации.

Я не знаю откуда пошла такая подмена понятий.
Просто надо знать об этом.

Смотри /topic/492905&pg=1#4895254
ты говоришь о новых, а тебя спрашивают об изменении уже существующих

iscrafm mazzyИтак, есть:
1. МНОГОПОЛЬЗОВАТЕЛЬСКАЯ система
2. Пользователь А
3. Пользователь Б
4. Другие пользователи

это сказка из серии... блокировать документ при редактировании или нет.
Рыдалъ

iscrafmА если пользователь А отсторнировал документ, действия пользователя Б, которые он совершил опираясь на первоначальную версию документа, считать правильным?
Нет. Но в этом случае система четко показывает причину, источник неправильности.

Если разрешить править уже проведенные документы, то причину неправильности найти очень сложно.
см. пример в этом посте http://sql.ru/forum/actualthread.aspx?tid=492905#4896481