Показать сообщение отдельно
Старый 17.06.2019, 10:46   #12  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
Цитата:
Сообщение от 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С есть еще один вариант - регистр сведений.
-------------
возможно, развитие снова вернется к пометке на удаление, причем с тотальным пересмотром понятия уникальности - уникальность требуется только для не помеченных на удаление, помеченные могут быть неуникальными.
__________________
полезное на axForum, github, vk, coub.

Последний раз редактировалось mazzy; 17.06.2019 в 11:01.
За это сообщение автора поблагодарили: sukhanchik (6).