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

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

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

gybsonЭто одинаковые меры для всех ЕРП - Административные. К сожалению не у всех есть административные меры повлиять на портовые службы Аомыня или Кейптауна :(. А изменения в базах происходили не только из-за ленивых операторов. Пример: пришел сухогруз - по документам 50000т руды. Когда через месяц руду разгрузили, развезли по заводам и более точно взвесили оказалось 50200т или 49700т. Пускай заводы точно и в срок предоставляют данные, искажения в основном происходят в начале производственной цепочки, а значит "плывет" и себестоимость ГП...
Uncle_AlexЧего тут искать или решать. Задача в принципе не формализуется из за несовместимости периодовВо-во. Я тоже так подумал, когда ознакомился с ситуацией. Но платят нам не за правильные выводы :)...
Жаль что в ходе дискуссии не демонстрируют конкретные ноу-хау сторнирования. Неужели все так очевидно и однозначно, что об этом не стоит и говорить?
Для затравки приведу мое решение вышеописанной задачи. Исходная ситуация: оперучет ведется в Екселе (150-200 новых файлов в месяц). За неделю перед сдачей отчетности (норматив тогда был не 7, а 28 число, раньше физически не успевали) данные ручными проводками переносились в базу 1С 7.7 и по ним начинали делать отчетность. В этой базе не было документов, а только справочники, план счетов, универсальные бух. отчеты и специальный гибко настраиваемый отчет для получения Balance Sheet. Когда находили ошибку все пересчитывали в Ексель и результаты добавляли в 1С. Работа очень развивающая внимательность и аккуратность. В общем Отделу себестоимости всегда было чем заняться :(...
Сделал им документы покупки, продажи, производства и т.п. Весь оперучет перевел на регистры. Для незнакомых с 1С: регистры - специальные таблицы, заполняемые документами при записи. В 1С - один из основных методов (наряду с проводками) хранения результатов хозопераций. В основном по ним, а не по документам получают отчеты за период, также используются самими документами для расчета себестоимости. Документы оперучета разрешалось исправлять, удалять, вводить в любом периоде. Так как расчет себестоимости критичен к правильной последовательности ввода документов, а изменения задним числом его нарушают ночью запускался механизм восстановления последовательности, который перезаписывал документы в правильном порядке. Т.есть к утру обычно все становилось правильным. Были прописаны правила, по которым из данных оперучета раз в месяц формировались проводки. То есть все проводки описывающие деятельность за месяц (порядка 7тыс. в месяц) вводились одним документом и имели одну дату. Собственно по ним и делалось большинство отчетов. В проводках не было детализации по документам, поэтому, например, все взаиморасчеты по одному контракту сворачивались до одной проводки. Оригинальность моего (по крайней мере я его нигде не подсмотрел) "метода" сторно заключалось вот в чем.
Допустим сейчас июль и нам необходимо сформировать проводки за июнь. При этом мы уверены, что все исправления и добавления в оперучете были не раньше 1 января. Для создания таблицы проводок мы берем обороты регистров не за июнь, а за январь - июнь. Дополнительно получаем сальдо оперучета на 1 января и добавляем его к таблице оборотов. Отдельно рассчитываем проводки. Для этого берем обороты по проводкам за январь-май и к ним добавляем сальдо по проводкам на 1 января. Из таблицы полученной из оперучета вычитаем таблицу полученную из проводок и результат записываем как обороты за июнь. Т.е. данные бухучета периодически подравниваются под оперучет (условно правильный). Получилась сравнительно простая самовыправляющаяся учетная система с надежным сторно, где не нужно заботиться о сторнировании отдельной операции. Основной минус - в проводках нельзя было увидеть откуда взялась "добавка" к основным оборотам. Поэтому для налоговой такая "упрощенка" не прокатит, но аудиторов из PWC, такой подход к учету вполне устроил...
ИМХО я привел характерный пример (длинно получилось, но просьба модераторам не резать) того, что для решения одинаковых задач можно использовать разные приемы... А мне даже не хотят ответить сколько дат хранит сторнирующий документ в Аксапте :(

SergINIЭто про Россию? К нам ввозят руду? В окошко каждый день смотрю и вижу что грузят в порту, но руду там никогда не видел :(Если Ваше окошко находится в Ванино (Россия) или в Николаеве (Украина), то точно увидите сухогрузы доставляющие ежегодно миллионы тонн бокситов (боксит - это руда такая) для "Русский Алюминий" (сейчас он уже вроде "Российский Алюминий") из Австралии, Китая, Гвинеи, Нигерии, Гвианы ... Прежде чем подкалывать собеседника рекомендовал бы было немного освежать познания по теме...
SergINIЯ не видел в порту судно, которое задерживалось на месяц(это очень дорого!!!), если его не арестовали или оно не пришло на ремонт! ??? Если бы смогли дочитать фразу до конца то узнали бы, что месяц (и больше) уходит не только на разгрузку судна, но и на погрузку сырья в вагоны и перевозку всей партии руды до завода (из Ванино это тысячи километров), где только после уточненного взвешивания всей партии груза и получают разницу с заявленным в документах весом...
SergINIЗа груз отвечает экспедитор, или я не прав?... Это про какой порт такие сказки? Совершенно не в курсе кто отвечает за грузы. Знаю только что разница между датой получения учетчиком в Москве копий инвойсов из порта погрузки и датой в них проставленных обычно равно 1-3 месяца. Основные сырьевые порты я назвал. В управленческой базе пунктов отправки и назначения несколько сотен. В подробных логистических базах их (в том числе портов) тысячи...
ЗЫ. Я работал в Русале 5 лет назад и все подробности уже не помню. Предлагаю вместо подлавливания меня на знание морской тематики вернуться к теме сторно и описать свой опыт решения подобных проблем...

mazzyБудет очень жалко если придется вырезать, поэтому напомню: тема " Re: Реализация сторно в ERP системах "Можно считать это попыткой завлечь специалистов ERP подробно описать свой опыт решения подобных задач.

sleshiyAnswer, есть хорошее правило автоматизации - БАРДАК И АВТОМАТИЗАЦИЯ НЕСОВМЕСТИМЫ. Читайте почаще законодательную базу по материальному и бухгалтерскому учету (не помешают и знания юридического плана). Выполнять пожелания (читай капризы) отдельной категории заказчиков нужно с оглядкой именно на вопросы законодательной базы. В противном случае сами себя и клиента, в том числе, уверенно заведете в тупик.1.С правилом несовместимости бардака и автоматизации не согласен. Нормально совмещаются. Получается автоматизированный бардак.
2.Большое спасибо за совет читать законодательство! Обязательно попробую и надеюсь (как-никак экономфак МГУ и многолетний стаж работы главбухом и финдиректором), что чего-нибудь в нем пойму. Особенно интересуют законы регламентирующие управленческий учет (извините за тавтологию) для которого и была создана моя конфигурация. Нигде не могу найти... Не подскажите ссылку?
3.Ну если клиент сам позволяет себя обманывать... Должен же быть естественный отбор от слишком доверчивых капиталистов на современном жестоком рынке. Почему бы его не проводить нам автоматизаторам? И когда я делал конфигурацию консолидированного учета активов для другого капиталиста (Рома зовут), мне тоже удалось убедить клиента, что разбираюсь в МСФО и ГААП. Так что в журнале Форбс, где публикуются списки заведенных автоматизаторами в тупик клиентов есть и мои...
Про сторно что-будь можете рассказать?

Uncle_Alex... Данные(воможно не актуальные) внесенные прошлыми периодами сравниваются с данными от реально имевших место. Вся погрешность накапливается сканирующим механизмом и по аналогии с пузырьком в алгоритмах сортировки заносится на последний отчетный период... Да правильно, так все и есть... Uncle_AlexЗдесь понятно, аудиторы должны свято верить, что процесс коррекции выполнен достоверно ибо проверить это можно только тотальным анализом. Терь по поводу самого "сторно". Как уже имел смелость заявлять, "сторно" это частный случай актуализации нынешнего состояния данных об учете, после обнаружения несоответствия внесения данных этого учета в прошлом. В любом случае такая коррекция отражает разность между старыми данными(как правило недокументированными) и новыми(документированными), а данных о реальном документе нет нигде. Очень попахивает непрозрачностью. Метод лобового изменения задним числом с гарантированной актуализацией, базируется на внесении подвержденных данных, его минус - изменение задним числом результатов всех отчетных периодов. Для налоговой отчетности это тоже не катит, а для остальных дело вкуса. Уж гемороя и требований к квалификации персонала явно меньше.Да, правильно заметили: в принятии результатов должен быть элемент веры в "непогрешимость" системы и пользователей :). Но если никому не верить будет очень тоскливо жить:(. А если серьезно, то пока аудиторам не смогли подробно разъяснить принцип работы базы они отказывались "аудировать", но поняв, успокоились. И так как каждый год аудит проводят, как правило разные люди, объяснять приходится заново. Надеюсь за 5 лет работы системы учетчики в этом поднаторели :)... Так для того я и завел эту ветку, чтобы обсудить методы снижения неудобств сторнирования, ведь для многих видов отчетности (регламентной, например) альтернатив ему нет...
Снижение требований к квалификации... - распишу чуть подробней (Модератор, дальше будет и про ERP!). Изначально в управлении работало порядка 25 человек и в период сдачи отчетности нормой было засиживаться всем до 21-24. Все они были квалифицированными и хорошооплачиваемыми специалистами (знание ГААП, свободный английский и т.д.). Изначально я работал в департаменте ИТ Русала, но поссорился с начальством, хотел уволиться, но меня "приютили" пользователи. То есть я числился учетчиком и сидел вместе с ними... Когда система заработала, задач для работника стало примерно на 1ч в день :). Данные из других баз выгружались в Эксель, корректировались и заливались в систему. Заливка и отладка данных за месяц занимала несколько часов. Себестоимость считалась сама, отчеты и акты сверки заполнялись по кнопке. Остался ввод с бумажных носителей и внемашинная работа... Учетчики, понимая что свалившуюся на них "халяву" долго в тайне не сохранить, заволновались. Была даже официальная просьба высокому начальству передать им часть работы других ведомств! К "благодетелю" испытывали смешанные чувства: "тебя надо расцеловать и грохнуть!". Типичный отзыв о системе: "Она нас отупляет!"... Итог печален. Число работников уменьшилось вдвое и управление превратилось в отдел:(... Но рано или поздно этот учет будет вестись в SAP, поэтому мне очень интересно: как работа в настоящей ERP повлияет на численность пресонала ;)?

SergINIВсё-таки административно что-то нужно решать. Я не читал контрактов, но в них должно быть прописано в какой момент времени руда становится вашей, и в этот момент по факту взвешивания(или на основаниии таможенных документов) оформлять руду...Контрактов тысячи и различных условий перехода прав собственности там тоже достаточно. Часто определить дату продажи/покупки - нетривиальная задача (например, если эта дата зависит еще от оплаты). Согласен, неплохо максимально унифицировать условия контрактов и учетчики с менеджерами на эту тему часто ругались. Но не всегда это возможно, когда у компании контрагенты по всему миру и у каждого свои понятия об унификации. А определить точную дату продажи на бирже - вообще отдельная песня :(... Хорошо, пусть по контракту право собственности переходит в порту погрузки, и если порт в Австралии, то уточнить вес груза мы сможем только через 3 месяца... SergINIВ бух. учёте разрешены методы:
1-й. Назовём его традиционный. Когда материальные ресурсы оцениваются по окончанию месяца. Т.е. после всех введённых по месяцу документам. Последовательность их ввода на "правильность" себестоимости никак не влияет.
2-й. Так называемый метод "скользящих" цен. Т.е. если вы по каким-то причинам не можете расчитывать 1-ым способом, то записывете этот метод в своей учётной политике и обосновываете перед налоговой, что 1-ый метод для вашей компании нельзя применить. Метод скользящих цен подразумевает что себестоимость плавает, она расчитывается на основании уже введённых документов и порядок ввода при таком методе тоже не имеет значения(главное, чтобы они все были введены)!...Ну что на это сказать... Будем считать, что мой капризный клиент настоял на расчете себестоимости продукции в момент записи документа ее продажи, притом по своему уникальному фирменному методу ее оценки "FIFO", при котором результат зависит от даты и даже времени записи документа (поверьте мне на слово)... SergINIЯ бы это "надёжным" сторном не посмел назвать. Больше на подгон оборотов под конечное сальдо (остаток) похоже :) Вообще сторно это исправительная проводка. К которой бухгалтер должен подложить документально оформленную бух. справку с перечнем всех исправляемых проводок и причин исправления :) Так что касательно бухучёта ваш метод не катит! В управленческом учёте, если "управленцы" согласны, такой подход возможно прокатит. Но кому он нужен, если "откуда взялась "добавка" к основным оборотам" нельзя определить, а следовательно и проверить!Еще раз напомню, про ключевое слово в описании задачи: УПРАВЛЕНЧЕСКИЙ учет, т.е. для собственных нужд, причем тут бух.справка? И я сразу сказал об ограниченности применения своего приема... А в моем примере учет вообще велся от имени оффшора, который закупал сырье, передавал его на переработку заводам, а полученную продукцию продавал, т.е. владельца давальческого сырья. Поэтому правила РСБУ были для него глубоко... И заводы Русала были для него обычными контрагентами. На эту схему (толлинг) тогда приходилось 80% оборота (сейчас не знаю)... Насчет "надежности". Предположим, оперучет ведется проводками и для исправлений делаются подробные сторнирующие проводки в текущем периоде. Когда приходит отчетная пора проводки за месяц сворачиваются (например, для ускорения выдачи отчетов) до достаточной для отчетности детализации и выгружаются в другую базу, где с ними работают другие люди, которым есть чем заняться вместо увлекательной перепроверки правильности сторнирования первички. Схема, напоминающая (здесь выше довольно точно определили) OLAP подход. Так вот, я получаю тот-же результат, но с намного меньшими усилиями...

Все, больше на вопросы, связанные с моим решением задачи (написал только для затравки!) отвечать не хочу, иначе придется переименовывать тему! Очень надеюсь, что вместо вопросов ко мне здесь появятся описания других задач требующих частого сторнирования и методов их решения...