|
17.06.2019, 10:46 | #1 |
Участник
|
Продолжим теоретические размышления.
итак, функционал исправления ошибок ввода скорее всего надо лечить не столько упрощая сторно/реверс/отмену, сколько снижением вероятности ошибок. снижать вероятность ошибок можно не только программным путём, но и изменением самого бизнес-процесса в каких случаях еще может потребоваться сторно помимо ошибок? === прежде всего, может потребоваться для получения "правильной" отчетности в условиях, когда учёт является дискретным/тактовым (не непрерывным). Типичный такт в наших бухгалтериях - это квартал+20 дней. В течение первого такта данные поступают в систему, а затем во время второго такта данные подчищаются, подгоняются, сверяются, валидируются, одобряются, трансформируются, происходит клининг в клиринговой конторе, распределение затрат, вычисление EBITDA, получение trial balance и прочие названия. Главное, что во время второго такта не желательно добавлять реальные данные в период первого такта. Только под чутким руководством специально обученных людей. именно во втором такте и используется сторно как легальный механизм "цифровой трансформации". именно на втором такте нужны механизмы типа аудиторского следа. Но именно на этом этапе бизнес-данные, как правило, не изменяются (хотя всякое бывает). Именно на этом этапе сторнируются только финансовые движения. В аксапте это сторно реализовано отвратительно. И здесь можно сделать (и делается на внедрениях) очень много. === третий случай, когда действительно нужно сторно - это accruals. бухгалтерские такты очень чувствительны к вводу задним числом (добавление реальных данных к первому такту во время второго такта). казалось бы - не вводи задним числом! но не всегда получается запретить ввод задним числом. возьмем типичный случай - командировки. сотрудника послали 28 числа какого-то месяца в недельную командировку. в новом месяце он возвращается и вводит факт своих затрат. в какой месяц он вводит? представим что в командировку послали бригаду ремонтников. на несколько месяцев. в глухую тайгу. ремонтировать условных трубопровод. или еще какую установку. вернувшись, они дисциплинированно отчитаются. в будущем. но что делать в настоящем? чтобы действовать в таких случаях, придумали учетный механизм accruals. грубо говоря, это: 1. возможность сейчас ввести операцию не с фактической суммой, а с некоторой оценкой. Оценка может появится в результате какого-то алгоритма, а может появится как экспертная оценка некоего ответственного сотрудника (взял с потолка) 2. затем ранее введенная оценка сторнируется/реверсируется 3. и вводятся фактические данные важно, что:
хочу отметить, что по российскому законодательству собственно accruals явно запрещены законодательством. однако сам механизм accruals задействован в РСБУ повсеместно, и по бухгалтерии accruals может проводится совершенно по-разному: см. авансы/зарплата, подотчетники, учет незавершенки, амортизация, ответственное хранение, взять/отдать товар на реализацию и т.п. - это все accruals, в которых явно прописано как делать каждую часть accruals, куда относить оценку, куда относить факт и куда девать разницу. в российском законодательстве всячески избегают использовать сторно как нормальный инструмент учета, оставляя сторно только как инструмент исправления ошибок. в РСБУ приветствуются коррекции и "проводки на разницу". в буржуйских IAS/GAAP сторно-реверсы вполне разрешены. В аксапте мы видим их отголоски в финансовых и физических движениях складских запасов. = Физическое движение - это оценка = когда делается финансовое движение, аксапта автоматически сторнирует физическое, = а затем добавляет финансовое. таким образом:
и да, если говорить о технической реализации сторно для бизнес-данных, то: Последний раз редактировалось mazzy; 17.06.2019 в 11:01. |
|
|
За это сообщение автора поблагодарили: sukhanchik (6). |
17.06.2019, 12:42 | #2 |
Участник
|
Цитата:
Сообщение от mazzy
учетный механизм accruals.
грубо говоря, это: 1. возможность сейчас ввести операцию не с фактической суммой, а с некоторой оценкой. Оценка может появится в результате какого-то алгоритма, а может появится как экспертная оценка некоего ответственного сотрудника (взял с потолка) 2. затем ранее введенная оценка сторнируется/реверсируется 3. и вводятся фактические данные 4. вводятся сторно фактических данных конечно, это уже не аксапта. но если говорить теоретически, если принять установку "Предположим вы проектируете свою ERP/Учетную систему", то такой механизм вполне покрывает требования к учету. т.е. есть следующие понятия: = движения - записи по бухгалтерским счетам, по регистрам, записи в модулях = проводка - это набор движений, которые имеют один идентификатор (по аксаптовски - ваучер) = операция - это набор проводок, для которых указан объект учета и тип учета (1-4 - оценка, сторно оценки, факт, сторно факта) = объект учета - либо ссылка на элемент какого-то справочника, либо некие уникальные идентификаторы (возможно составные), значимые для человека и системы. движения дают оборотно-сальдовые ведомости для бухгалтерии проводки дают аудиторский след операции дают отчеты по объектам учета этот механизм вполне может работать и со "сторно отсторнированных операций" такой механизм покрывает всякие ос-амортизации-выбытия, зарплаты-начисления-авансы-удержания, расчет и пересчет себестоимости. и т.д. Последний раз редактировалось mazzy; 17.06.2019 в 12:46. |
|
Теги |
аудиторский след, разноска, реверс, сторно |
|
Похожие темы | ||||
Тема | Ответов | |||
Пенни за твои мысли, или размышления о внутреннем образование для разработчиков ERP | 21 | |||
О причинах неудачных внедрений ERP | 4 |
|