Исследование возможности удаления проводок

[sguryev]

Краткое описание:

На данный момент проводки нельзя ни удалять, ни исправлять. Это приводит к проблемам при вводе некорректной проводки, приходиться вводить проводки с отрицательными суммами, что в свою очередь мешает при анализе и просмотре проводок. Цель исследования рассмотреть взаимосвязи различных объектов с которыми связаны проводки и выработать рекомендации к удалению.

Рассмотрены следующие случаи:
1. Заполнение строк журнала ГК в ручную и далее разноска.
2. фактуровка Закупки, создание закупки и формирование счета-фактуры.
3. фактуровка Заказа, создание заказа и формирование счета-фактуры.

Получен результат:
- Выработаны рекомендации, на основе которых можно добавить функциональность к системе, которая позволит удалять проводки автоматически.
- Также описаны связи объектов связанных с проводками для случаев описанных выше.

Ограничения:
Рассмотрено не для всех случаев, а для конкретных ситуаций описанных выше.

Содержание проекта:
Проект состоит из объектов сгруппированных по определенным правилам:

- TransInPurch_Modif – помещены таблицы данные, которых изменяются при разноске закупки в Главную Книгу, в подгруппе Empty помещены таблицы, которые оказались пустыми, как до, так и после разноски. Выборка именно этих таблиц осуществлена после мониторинга обращений к БД и выявления в полученном логе тех таблиц, над которыми выполнялись операции insert, delete, update.

- TransInSales_Modif – помещены таблицы данные, которых изменяются при разноске заказа в Главную Книгу, в подгруппе Empty помещены таблицы, которые оказались пустыми, как до, так и после разноски. Выборка именно этих таблиц осуществлена после мониторинга обращений к БД и выявления в полученном логе тех таблиц, над которыми выполнялись операции insert, delete, update.

- TransInJournal_Modif – помещены таблицы данные, которых изменяются при создании и разноски проводки вручную в Главную Книгу, в подгруппе Empty помещены таблицы, которые оказались пустыми, как до, так и после разноски. Выборка именно этих таблиц осуществлена после мониторинга обращений к БД и выявления в полученном логе тех таблиц, над которыми выполнялись операции insert, delete, update.

- Classes – некоторые классы, которые используются при разноске, частично выявлены в результате анализа кода.

- n_1 – связи таблицы проводок (LedgerTrans) много к одному, получены в результате анализа этой таблицы в MorphXplorer.

- 1_n - связи таблицы проводок (LedgerTrans) один ко многим, получены в результате анализа этой таблицы в MorphXplorer.

- Relations - связи таблицы проводок (LedgerTrans) выявлены из описания таблиц, подпункт связи. Введены две подгруппы: журналы (Jour) и проводки (Trans).

- Forms – некоторые формы связанные с проводками, частично выявлены из анализа кода.

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

Метод исследования см. статью в базе знаний:
Один из подходов к анализу движения данных в AXAPTA
статью:
Использование MorphXplorer
и статью:
Таблицы задействованные при некоторых операциях с проводками

[sguryev]

<b>Результаты исследования:</b>

[mazzy]

Цитата:

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

И это не спроста

Цитата:

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

Это не проблема. Это называется аудиторский след.

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

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

Цитата:

Изначально опубликовано sguryev
Цель исследования рассмотреть взаимосвязи различных объектов с которыми связаны проводки и выработать рекомендации к удалению.

Мы тоже занимались в свое время такми исследованиями.
Дело в том, что разнесенную проводку Аксапта не обязательно сохраняет в неизменном виде. Разнесенная сумма может:
= дробиться на несколько сумм (при сопоставлении);
= использоваться для создания целого веера новых проводок (курсовые, суммовые, закрытия склада, коррекции, пересчет и т.п.);
= использоваться в форме "аудиторский след", наконец.

Поэтому сама постановки задачи "изменение разнесенной проводки" неверна с методической и технологической точки зрения.

Но все равно спасибо вам.
Очень полезная информация.

[Роман Кошелев]

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

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

[komar]

Конечно, удалять проводки нехорошо. Однако, если это делает специально выделенный администратор, и регистрирует свои действия, то почему бы и нет?
А самый простой способ - заглянуть в database log, и исправить суммы в затрагиваемых операцией таблицах.

[Pavel]

Цитата:

Изначально опубликовано komar
Конечно, удалять проводки нехорошо. Однако, если это делает специально выделенный администратор, и регистрирует свои действия, то почему бы и нет?
А самый простой способ - заглянуть в database log, и исправить суммы в затрагиваемых операцией таблицах.

Привет,

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

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

Вот только, если расшифровать "мнение опытных людей" (Роман), то получится, что у разных проводок в разных модулях, в разных случаях, ну очень «различные варианты связей».

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

Затем, возникнет понимание, что такого специалиста можно использовать эффективнее, чем за рядовыми пользователями «мусор разгребать».

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

Так смотришь, и до понимания табу дело дойдет.
Но лучше сразу поверить!

С уважением.

[mazzy]

Не очень верю в конструктивное продолжение. Но хотелось бы ошибаться в этом...

Pavel, похоже вы знаете решение этой проблемы.
Расскажите, как можно обеспечить удаление проводок?

Итак у нас есть:
= расширяемая система (модули разные, связи между модулями очень различны, возможны отраслевые решения, возможны собственные наработки)
= по настоящему многопользовательская система

Как обеспечить возможность удаления проводок в такой системе?

Пока я знаю два подхода:
1. запрет удаления
2. единый системный регистратор (например в 1С это общий журнал)

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

Так какое решение можете предложить вы?

[Pavel]

Цитата:

Изначально опубликовано mazzy
Как обеспечить возможность удаления проводок в такой системе?

Пока я знаю два подхода:
1. запрет удаления
2. единый системный регистратор (например в 1С это общий журнал)

Запрет удаления вы считаете несовместимым с менталитетом наших людей.

Так какое решение можете предложить вы?

Привет,

1) Можно менее формально, т.е. на ты?
2) Данные системы не предполагают удаление проводок, а только сторнирование.
3) "Если очень хочется, то можно" (komar). Всякое в жизни бывает. С вытекающими последствиями.

Про "совместимость менталитета" - это не умный вывод, а факт из жизни.

С уважением.

[mazzy]

Понятно.
А решение?

[Pavel]

Цитата:

Изначально опубликовано mazzy
А решение?

Хорошо, еще раз... Сторно!

[mazzy]

Ага. Понял.

[komar]

Сторно изначально создавалось в бумажной системе бухучета. То есть там, где автоматический пересчет итогов невозможен в принципе, и иной метод исправления ошибок приводил бы к невозможности свети концы с концами.
В автоматизированной системе:
1. Ведутся логи изменений БД
2. Возможен автоматический пересчет итогов, связанных таблиц и т.п. (в Аксапте для этого нужно чуть больше поработать, в Аттейне процедуру сделать проще, но везде это возможно. И даже в той же Axapta такое делается, сам видел). И даже такой, чтобы сохранялась целостность данных.

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

А причина, по которой консультанты отстаиваю "методологическую неправильность" удаления операций проста как полено:


Делать лениво, проще убедить, что ее делать не надо

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

[mazzy]

1. Я правильно понимаю, что лог удалять нельзя по определению?
2. Я правильно понимаю, если лог не ведется, то проводки и сторно сами и являются логом?
3. Я правильно понимаю, если лог не ведется, то проводки и сторно нельзя удалять по определению лога?

Можно свести обсуждение к двум тезисам:
= можно ли вести лог отдельно от проводок? нужно ли? что лучше?
= можно ли удалять лог? когда и при каких условиях?

[komar]

Под логом я понимаю в первую очередь средства Аксапты (из которых для нас важнейшим является Журнал изменения БД).
Лог отдельно от проводок вести нужно, т.к. не только удаление проводок представляет интерес для грядущих поколений.
Лог удалять можно. Когда? Я предлагаю чистить его в момент закрытия периода (удаляя то, что к нему относится). Правда система умеет удалять его только весь или не весь. Думаю, стоит научить ее делать иначе.
Стоит подумать - а что будет, если лог не удалять вообще. Насколько значительно разбухнет база? Ответа у меня нет, такие замеры не производились. Знаю только, что работа с логом не замедляет работу системы (для пользователя это незаметно).

Вообще Журнал изменений БД полезная штука - я пользовался, остался доволен.

[Pavel]

Привет,

Тема принципиальная, жаль не хватает времени "побадаться".

Про лог все поняли с первого раза и по технической стороне вопроса все понятно.

Цитата:

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

Рассуждения типа «если жизнь на Марсе» (дух программерства). Если отвлечься от «фантазий» и рассмотреть требования ПБУ, то окажется, что регламент внесения изменений в отчетный период определен и не зависит от формы ведения учета (бумажной или электронной).

Цитата:

Изначально опубликовано komar
В автоматизированной системе:
1. Ведутся логи изменений БД
2. Возможен автоматический пересчет итогов, связанных таблиц и т.п. (в Аксапте для этого нужно чуть больше поработать, в Аттейне процедуру сделать проще, но везде это возможно. И даже в той же Axapta такое делается, сам видел). И даже такой, чтобы сохранялась целостность данных.

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

Удивляет тот факт, что производители всех западных систем, за десятилетия их развития, так и не смогли «справиться» с удалением разнесенных проводок.
Все ждали чудесного решения от российских умельцев.

Цитата:

Изначально опубликовано komar
А причина, по которой консультанты отстаиваю "методологическую неправильность" удаления операций проста как полено:
Делать лениво, проще убедить, что ее делать не надо
Хотя в некоторых случаях цель действительно не оправдывает средства, некоторые фирмы и без корреспонденции счетов жили.

«Мы все учились понемногу чему-нибудь и как-нибудь...» А.С. Пушкин
Полагаю, профессиональное образование сложно подменить «творческим подходом» к делу.

С уважением.

[komar]

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

Но я считаю, что это пережиток прошлого, и никто с задачей не справился, потому, что никто такую задачу и не ставил. Да, на Западе аудиторам может сильно не понравиться система, позволяющая удалять проводки. Но это не есть значит, что такое решение принципиально неправильно. Ибо на том же западе живут и без сторно (что приводит к некоторому отсутствию экономического смысла в оборотах по счетам при исправлении обратными проводками).
Есть такая вещь, как удобство, и есть такая вещь как целесообразность. Целесообразно иметь возможность отследить все изменения в учете. А вот как это удобнее сделать, каждый решает по-своему. Для некоторых окажется удобнее сторно. А некоторые будут писать удаление проводок. Я видел на практике и то и другое.

[Pavel]

Цитата:

Изначально опубликовано komar
Но я считаю, что это пережиток прошлого, и никто с задачей не справился, потому, что никто такую задачу и не ставил. Да, на Западе аудиторам может сильно не понравиться система, позволяющая удалять проводки. Но это не есть значит, что такое решение принципиально неправильно.

Есть такая вещь, как удобство, и есть такая вещь как целесообразность.

Привет,

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

С уважением.

[komar]

А кто говорил про закрытый период?
Я все про открытый

[Pavel]

Цитата:

Изначально опубликовано komar
А кто говорил про закрытый период?
Я все про открытый

Привет,

"закрытый период"?
Речь идет об отчетных датах: кассы - день, НДС - месяц, ЕСН - квартал, и т.д. и т.п. (полугодие, год). Это для бухгалтерских и налоговых отчетов.
А финансовые и управленческие отчеты готовятся по требованию собственников бизнеса и/или инвесторов. Как правило - это отчетность по неделям и месяцам.

Как работа с логом БД предполагает отслеживать отчетные даты при удалении проводок? Объясни, pls.

С уважением.

[komar]

1. Имеется в виду исправление проведенных операций до момента предоставления отчетности.
2. Ссыляться на ПБУ относительно к управленческой отчетности некорректно, т.к. управленческая отчетность не обязана руководствоваться ПБУ.
3. Все и так знают, что касса должна быть "прошнурована и пронумерована"... Но только делается это далеко не каждый день

Если была составлена отчетность, то исправлять, есссно, придется по определенным правилам. А вот до ее предоставления можно и поудалять.
Работа с логом не предполагает никакого отслеживания. Оное отслеживание предполагает гипотетическая процедура по удалению проводок. Которая может отличать закрытый период от открытого. Кстати, закрытие периодов - это один из инструментов сохранения данных, по которым была предоставлена отчетность.