Теоретические размышления о реализации сторно в ERP системе

[Lemming]

Предположим вы проектируете свою ERP/Учетную систему. Вопрос в том, как красиво сделать сторно/реверс документов. Вариант 1С с удалением старых проводок и создания новых имеет как свои преимущества, так и недостатки. Преимущества заключается в том, что это самый очевидный способ, по которому пошли почти все отечественные учетные системы, недостатки: в некоторых случаях это вносит путаницу в учет, а так же теряется аудиторский след.

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

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

Предположим вы проектируете ERP систему или платформу для создания подобных систем с нуля: как бы вы спроектировали реверс/сторно/удаление проводок/ отчеты, в которые могут попасть или не попасть такие проводки и, вообще, возможно всю архитектуру разноски, что бы одновременно поддержать аудиторский след и не заставлять пользователей получать инфаркт (как в аксапте ), когда они допустили ошибку и разнесли документ с ошибками?

[mazzy]

Цитата:

Сообщение от Lemming

Вариант 1С с удалением старых проводок и создания новых имеет

У 1С есть еще один вариант - регистр сведений.
Жаль, что он появился очень поздно. До него были попытки играться с "историческими значениями", которые сейчас пытаются ввести в Data Entity.

Скорее всего, в системе должно быть что-то типа регистра сведений. Причем тотально.

В Аксапте ближайший аналог - себестоимость в складских проводках.
По хорошему, в Аксапте нужно было бы хранить историю статусов и складских аналитик.

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

лет 20-30 назад, когда закладывались архитектурные решения, хранилище и поиск были дорогим удовольствием. это сейчас гуглы с фейсбуками ничего не удаляют, а только помечают как удаленное.

[mazzy]

Цитата:

Сообщение от Lemming

и не заставлять пользователей получать инфаркт (как в аксапте ), когда они допустили ошибку и разнесли документ с ошибками?

Тут дело не в системе.

ключевой вопрос - допустимы ли исправления уже проведенного документа в многопользовательской системе?

аналог разноски IRL - поставить подпись/печать под документом и отправить этот документ другим людям, которые будут принимать свои решения и подписывать свои документы на основании данного.

вопрос - можно ли сказать ОЙ забрать документ обратно и исправить его? технически можно конечно. Но огранизационно - нет. Вплоть до инфарктов Поскольку на основании подписанного документа другие люди уже поработали и что-то сделали.

ERP система только многократно ускоряет этот процесс.

[Lemming]

Цитата:

Сообщение от mazzy

Тут дело не в системе.

Мысль понятна, но практика подсказывает...вот я для этого и создал тему, что бы поразмышлять над тем, как лучше всего было бы спроектировать, что бы и "И волки сыты и овцы целы" были!?

Цитата:

Сообщение от mazzy

аналог разноски IRL - поставить подпись/печать под документом и отправить этот документ другим людям, которые будут принимать свои решения и подписывать свои документы на основании данного

Во основе моего вопроса лежит еще мысль о том, что да, на западе они спокойно живут со сторно, а вот на просторах СНГ (кстати, интересно как в Индии и Азии), существует проблема, которая особенно остро ощущается при смешивании Российского пользователя-бухгалтера и западной ERP системы.

[mazzy]

Цитата:

Сообщение от Lemming

на западе они спокойно живут со сторно

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

там другой подход - документ проверяется ДО разноски. Но если уж проверки пройдены, а документ одобрен, то фиг его исправишь.

[Lemming]

Цитата:

Сообщение от mazzy

плохо они живут со сторно.
...
там другой подход - документ проверяется ДО разноски. Но если уж проверки пройдены, а документ одобрен, то фиг его исправишь.

Это наталкивает на мысль о том, что может быть дело и не в сторно, а в том как нам сделать разноску удобней? Я не помню стандарт это или модификация: предварительный просмотр проводок, он отчасти спасал, но я его только в журналах ГК видел. Потому что, получается, что подход 1С - это жизненная необходимость, но он ведь тоже работает так себе.

[mazzy]

Цитата:

Сообщение от Lemming

Это наталкивает на мысль о том, что может быть дело и не в сторно, а в том как нам сделать разноску удобней?

да, добавлять бизнес-проверки.
то что постоянно делают во время внедрений.

да, стандартный функционал аксапты слабый в этой области.

Цитата:

Сообщение от Lemming

Я не помню стандарт это или модификация: предварительный просмотр проводок, он отчасти спасал, но я его только в журналах ГК видел.

финансовые проводки - это очень специфический язык очень специфически обученных людей.
этого механизма проверки недостаточно.

Цитата:

Сообщение от Lemming

Потому что, получается, что подход 1С - это жизненная необходимость, но он ведь тоже работает так себе.

У них своя сказка - по историческим причинам, их главной целевой аудиторией (те, кто деньги платит) являются как раз те самые специфически обученные люди со специфическими требованиями.

во-первых, требования бухгалтеров зачастую отражают требования регулирующих органов, которые являются естественными антагонистами бизнеса

во-вторых, бухгалтера живут и мыслят в периодах сдачи отчетности (квартал+20 дней на правку данных). этот период очень часто совершенно никак не отражает естественные бизнес-периоды (сезонность, периоды бюджетирования, средняя продолжительность сделки и т.п.)

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

[mazzy]

Цитата:

Сообщение от Lemming

а вот на просторах СНГ (кстати, интересно как в Индии и Азии)

у них примерно также как и у нас.

вот за что я благодарен майкрософту - за возможность поработать над задачами разных стран - Бразилия, Аргентина, Мексика, Испания, Индия, Индонезия, Франция, Италия и Норвегия.

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

самое интересной была задача из норвегии - они тупо заменяют "ихние кассовые аппараты" на нечто, напоминающее блокчейн в электронном виде. продавцы выбирают период отчетности и высылают в налоговую файл с операциями (есть около 10 атрибутов) и некую контрольную сумму, которая зависит от текущих операций и контрольной суммы прошлого периода. всё.

сдал - фиг поменяешь. чем больше период себе выбираешь, тем проще подхимичить в текущем периоде, но тем сложнее что-то сделать с предыдущими периодами.

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

Но меня удивило даже не два статуса отмены, а то что регулирующие органы в бразилии как-то одобряют на уровне каждой сделки!

в индии - полный аут. российское законодательство - образец стройности и логичности по сравнению с индийским.

[mazzy]

Цитата:

Сообщение от Lemming

Предположим вы проектируете ERP систему или платформу для создания подобных систем с нуля: как бы вы спроектировали реверс/сторно/удаление проводок/ отчеты, в которые могут попасть или не попасть такие проводки и, вообще, возможно всю архитектуру разноски, что бы одновременно поддержать аудиторский след и не заставлять пользователей получать инфаркт (как в аксапте ), когда они допустили ошибку и разнесли документ с ошибками?

Возвращаясь к исходному вопросу:

думается, что реверс - это не цель, а инструмент.

цель - минимизировать ошибки ввода информации в систему. а если ошибки таки сделаны, то минимизировать ресурсы и время исправления ошибок (реверс/сторно). другими словами, стоит минимизировать не само по себе сторно. стоит минимизировать ошибки.

если в результате правильной архитектуры, вместо 10% ошибок ввода, получился 1% ошибок, то затраты на сторно могут быть даже увеличены. При этом общий эффект все равно будет положительным.

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

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

= начать можно со входа на сайт, https, логирования ip, времени и прочих параметров авторизации
= раньше были переводы только на расчетный счет - добавили переводы на карты, переводы по номеру телефона
= раньше надо было вводить все реквизиты для перевода на счет, теперь корр.счет сразу определяется по БИК
= бюджетные платежи и всякие штрафы раньше требовали безумного цифрового КБК - теперь банки ввели разделы и предлагают список в соответствии с разделами
= номер карты проверяется
= и т.п.

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

с другой стороны, далеко не для каждой операции с банком можно сделать сторно!

ну и т.п.

да, изнутри эти системы выглядят ужасно и старомодно.
но направление движения интернет-банки вполне показывают. как мне кажется.

[Sancho]

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

[Sancho]

а из улучшайзеров... я как-то свою внутреннюю бухгалтерию сам с нуля написал, так вот в каждом документе при выборе объекта учета (клиент, фин. счет и пр.) под объектом мелким шрифтом был как текущий баланс, так и баланс с учетом этого документа.
дополнительный визуальный контроль, не перепутал ли ты знак.

[mazzy]

Цитата:

Сообщение от Lemming

Вопрос в том, как красиво сделать сторно/реверс документов.

Продолжим теоретические размышления.

итак, функционал исправления ошибок ввода скорее всего надо лечить не столько упрощая сторно/реверс/отмену, сколько снижением вероятности ошибок. снижать вероятность ошибок можно не только программным путём, но и изменением самого бизнес-процесса

в каких случаях еще может потребоваться сторно помимо ошибок?

===

прежде всего, может потребоваться для получения "правильной" отчетности в условиях, когда учёт является дискретным/тактовым (не непрерывным).

Типичный такт в наших бухгалтериях - это квартал+20 дней. В течение первого такта данные поступают в систему, а затем во время второго такта данные подчищаются, подгоняются, сверяются, валидируются, одобряются, трансформируются, происходит клининг в клиринговой конторе, распределение затрат, вычисление EBITDA, получение trial balance и прочие названия. Главное, что во время второго такта не желательно добавлять реальные данные в период первого такта. Только под чутким руководством специально обученных людей.

именно во втором такте и используется сторно как легальный механизм "цифровой трансформации". именно на втором такте нужны механизмы типа аудиторского следа. Но именно на этом этапе бизнес-данные, как правило, не изменяются (хотя всякое бывает). Именно на этом этапе сторнируются только финансовые движения.

В аксапте это сторно реализовано отвратительно. И здесь можно сделать (и делается на внедрениях) очень много.

===
третий случай, когда действительно нужно сторно - это accruals.

бухгалтерские такты очень чувствительны к вводу задним числом (добавление реальных данных к первому такту во время второго такта). казалось бы - не вводи задним числом!

но не всегда получается запретить ввод задним числом. возьмем типичный случай - командировки. сотрудника послали 28 числа какого-то месяца в недельную командировку. в новом месяце он возвращается и вводит факт своих затрат. в какой месяц он вводит?

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

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

грубо говоря, это:
1. возможность сейчас ввести операцию не с фактической суммой, а с некоторой оценкой. Оценка может появится в результате какого-то алгоритма, а может появится как экспертная оценка некоего ответственного сотрудника (взял с потолка)
2. затем ранее введенная оценка сторнируется/реверсируется
3. и вводятся фактические данные

важно, что:

• оценка может отличаться от реальной суммы - может быть 100%, может быть больше 100%, может быть меньше 100. Например, формирование резервов, страховых депозитов. Например, аванс сотруднику это часть зарплаты. Оценка может формироваться даже с коэффициентом меньше нуля. Например, подъемные приглашенному специалисту, +200 голды за регистрацию в игре или +3 месяца ажура бесплатно.
• ранее введенная оценка может сторнироваться не единоразово и не в момент появления реальных данных. например, амортизация списывается ежемесячно на основании другой оценки. например, незавершенка. тот же аванс сотруднику. Например, плохие долги списываются сильно позже обнаружения таких долгов.
• реальные данные могут и не вводится вообще. например, списание МБП, спецодежды.

хочу отметить, что по российскому законодательству собственно accruals явно запрещены законодательством. однако сам механизм accruals задействован в РСБУ повсеместно, и по бухгалтерии accruals может проводится совершенно по-разному: см. авансы/зарплата, подотчетники, учет незавершенки, амортизация, ответственное хранение, взять/отдать товар на реализацию и т.п. - это все accruals, в которых явно прописано как делать каждую часть accruals, куда относить оценку, куда относить факт и куда девать разницу.

в российском законодательстве всячески избегают использовать сторно как нормальный инструмент учета, оставляя сторно только как инструмент исправления ошибок. в РСБУ приветствуются коррекции и "проводки на разницу".

в буржуйских IAS/GAAP сторно-реверсы вполне разрешены. В аксапте мы видим их отголоски в финансовых и физических движениях складских запасов.
= Физическое движение - это оценка
= когда делается финансовое движение, аксапта автоматически сторнирует физическое,
= а затем добавляет финансовое.


таким образом:

• если сторно нужно только как механизм исправления ошибок ввода, то надо бороться не со сторно, а с ошибками
• если сторно нужно как механизм "цифровой трансформации" в условиях дискретно-тактового учета (квартал+20 дней), то нужно развивать только финансовое сторно. по факту стал традиционным подход двух систем - учетная и ЛПБ (любимая программа бухгалтера), в которой и происходят "цифровые трансформации", не влияющие на реальную жизнь в учетной системе
• если сторно используется как составная и неотъемлемая часть механизма accruals, то скорее стоит развивать функционал системы, чтобы система знала о бизнесе и различала оценку/сторно оценки/ввод фактической суммы.

и да, если говорить о технической реализации сторно для бизнес-данных, то:

Цитата:

Сообщение от mazzy

У 1С есть еще один вариант - регистр сведений.
-------------
возможно, развитие снова вернется к пометке на удаление, причем с тотальным пересмотром понятия уникальности - уникальность требуется только для не помеченных на удаление, помеченные могут быть неуникальными.

[mazzy]

Цитата:

Сообщение от mazzy

учетный механизм accruals.

грубо говоря, это:
1. возможность сейчас ввести операцию не с фактической суммой, а с некоторой оценкой. Оценка может появится в результате какого-то алгоритма, а может появится как экспертная оценка некоего ответственного сотрудника (взял с потолка)
2. затем ранее введенная оценка сторнируется/реверсируется
3. и вводятся фактические данные

этот учетный механизм можно расширить 4м пунктом:
4. вводятся сторно фактических данных

конечно, это уже не аксапта.
но если говорить теоретически, если принять установку "Предположим вы проектируете свою ERP/Учетную систему",
то такой механизм вполне покрывает требования к учету.

т.е. есть следующие понятия:
= движения - записи по бухгалтерским счетам, по регистрам, записи в модулях
= проводка - это набор движений, которые имеют один идентификатор (по аксаптовски - ваучер)
= операция - это набор проводок, для которых указан объект учета и тип учета (1-4 - оценка, сторно оценки, факт, сторно факта)
= объект учета - либо ссылка на элемент какого-то справочника, либо некие уникальные идентификаторы (возможно составные), значимые для человека и системы.

движения дают оборотно-сальдовые ведомости для бухгалтерии
проводки дают аудиторский след
операции дают отчеты по объектам учета

этот механизм вполне может работать и со "сторно отсторнированных операций"

такой механизм покрывает всякие ос-амортизации-выбытия, зарплаты-начисления-авансы-удержания, расчет и пересчет себестоимости. и т.д.

[Sancho]

Цитата:

Сообщение от mazzy

если сторно нужно только как механизм исправления ошибок ввода, то надо бороться не со сторно, а с ошибками

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

[mazzy]

Цитата:

Сообщение от Sancho

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

да, конечно, остается.
речь идет о экономической целесообразности, а не "можно сделать".