Найти и исправить ошибки на 19 миллионов рублей при помощи экспресс-проверки учета для 1С:УНФ

Александр Палкин, собственник и руководитель компании ООО «Саранск-Комплект» обратился к нам за помощью в исправлении проблем учета, выявленных нашей Экспресс проверкой учета.
Саранск-Комплект — поставщик материалов и комплектующих для производства мебели.

Компания ведёт учёт с 2011 года. За это время в программе накопилось много ошибок. Руководитель хотел наладить учет, чтобы отойти от операционных дел и спокойно передать управленческий учет ответственному сотруднику.
Чтобы не оставлять ситуацию без контроля, решили проверить учёт с помощью расширения для 1С.

Расширение поможет:
• исправить текущие ошибки
• легко контролировать учёт и проверять работу сотрудников буквально одной кнопкой

Мы решили поэтапно разбираться с вопросами.

Проблемы себестоимости

Если не следить за себестоимостью, в учете могут зависать суммы по товарам, которые потом никуда из себестоимости не денутся. А это значит, не попадут в Валовую прибыль, Доходы и расходы. Что в свою очередь искажает результаты деятельности.
Подробнее об этом рассказываем в статье Как избежать ошибок в себестоимости в 1С:УНФ

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

Подобных ошибок накопилось почти на 19 миллионов рублей! А это с учетом того, что есть и минусовые суммы, то есть сумма проблем явно еще больше.

Шаг 1: перезакрыть все месяцы

Начали мы с простого и банального — перезакрыли все месяцы с 2011 года. Это позволило исправить большое количество ошибок автоматически. Сумма ошибок значительно сократилась с 19 миллионов до 1,5 миллиона. Это уже очень хороший результат.

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

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

Шаг 2: проверить незакрытые суммы

Внимательно посмотрели на суммы, которые автоматически не закрылись. Оказалось, что такие суммы висят без учета Заказа покупателя. При этом основные суммы висели на конкретных заказах — как зарезервированные товары.

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

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

Вывод: механизмы расчета себестоимости и резервирования нужно дорабатывать очень аккуратно и смотреть на связанные механизмы.

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

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

Шаг 3: убрать зависающие суммы

В процессе глубокого анализа себестоимости мы выявили еще одну типовую проблему — зависающие суммы из-за резервов товара, которые делаются задним числом.

Не уверены, что это очень понятно, но пытливый читатель увидит следующее:
1. По пустому заказу покупателя у нас зависла сумма 2 880,32
2. Расходная накладная провелась без себестоимости и закрытие месяца никак эту ситуацию не поправило

Почему так произошло? Видимо, последовательность действий была такая:
1. Был оформлен Заказ покупателя 559 в июне 2013 года
2. Потом был оформлен приход товара и дополнительные расходы, но уже следующим месяцем — июлем.
3. Когда менеджер понял, что товар есть на остатках, он в Заказе покупателя оформил резерв на эту позицию, чтобы ее никто не занял.
4. Т.к. УНФ контролирует остатки всегда на текущую (актуальную) дату, то Заказ покупателя успешно провелся.
5. Но с точки зрения себестоимости так делать не корректно, т.к. себестоимость перекинулась на заказ в июне, а товар пришел в июле. По сути, сделалось движение задним числом. И сумма с прихода товара не встала на резерв корректно

Пока для работы с резервами нет хорошего решения. Обходное решение — это на административном уровне запретить ставить резервы в заказах, дата которых меньше текущего месяца, а резерв оформлять отдельным документом Резервирование товаров на актуальную дату. Это можно сделать на основании заказа. Но менеджерам, конечно, не сильно удобна подобная схема работы и они ошибаются.

Мы установили клиенту нашу доработку Контроль остатков на дату документа, которая при проведении документа контролирует складские остатки на дату документа (а не текущую, как в типовой УНФ). Она не позволяет оформить резерв задним числом и пользователь либо меняет дату Заказа, либо формирует документ Резервирование товаров.

Помимо этого, доработка полезна для тех, кто использует обмен с 1С:Бухгалтерией. Т.к. механизмы контроля остатков в 1С:Бухгалтерии более строгие и там остатки контролируются на дату документа. Поэтому часто получается ситуация, что в УНФ все красиво, а в Бухгалтерии — не проводится. И бухгалтеру приходится «мудрить» менять даты документов и т.п. Причем в случае исправления или  перепроведения документа в УНФ в бухгалтерии дата опять меняется и все начинается заново. 

Если исправлять такие ситуации вручную, то исправлять даты нужно на стороне УНФ, ну или поставить нашу доработку, которая будет сама контролировать нужные даты.

Шаг 4

Мы до него пока не дошли, ждем исправления шага 2, но на данном этапе мы продолжим анализировать зависшие суммы и некорректные остатки отчета Запасы. Скорее всего проблемы будут, но их будет гораздо проще выявить и найти способ исправления

Проблемы взаиморасчетов

У клиента, как и большинства пользователей 1С:УНФ, к сожалению, была стандартная проблема с зачетом авансов по документам. Одновременно висели как авансы, так и долги по одному и тому же контрагенту, договору, заказу.

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

Для исправления ситуации мы воспользовались нашей разработкой по автоматическому зачету авансов, которая сама закрывает все некорректные ситуации со взаиморасчетами.

Решили исправить все некорректные ситуации на актуальную дату. Если что-то будет исправляться задним числом, разработка сама все выровняет ночью

Какие итоги

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

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

Если у вас есть сомнения, есть ли ошибки в учёте, можете заказать демонстрацию нашего продукта или проверить работу на демоверсии — в нее включено несколько проверок.

Заказать демоверсию

А еще этот клиент написал нам отзыв по этой задаче