В конфигурациях "Управление производственным предприятием 1.3", "Комплексная автоматизация 1.1" при включенном режиме РАУЗ (Расширенная аналитика учета затрат) становится проблемой оценить валовую прибыль от продаж в управленческом учете.
Типовой отчет "Валовая прибыль" прекращает работу, т.к. не делаются (точнее делаются, но неправильно, как при режиме оценке затрат "по прямым", так и "по нулевой цене") движения по регистру накопления "ПродажиСебестоимость", в результате чего отчет прекращает "видеть" себестоимость вообще, и вся прибыль становится равна выручке.
Существуют различные технически простые решения, решающие эту проблему: в основном в виде отчетов на "построителе отчетов" и СКД, которые выбирают себестоимость непосредственно из регистра РАУЗ "УчетЗатрат". Однако, если номенклатуры и движений много, в качестве горизонта выбрать отрезок более 1 месяц, а логика отчета корректно выбирает себестоимость за каждый месяц периода, а не усредняет ее за весь период, то такое решение будет работать медленно, особенно в файловых базах, из за большого объема выборок и соединений данных.
Очевидным решением представляется скорректировать неправильные движения документа "Расчет себестоимости выпуска" по регистру "ПродажиСебестоимость" после его проведения. Предложенная для загрузки ниже внешняя обработка решает эту проблему именно таким способом.
При этом:
1. Заработает типовой отчет "Валовая прибыль", который посчитает прибыль, эффективность (наценку) и рентабельность. Даже при использовании режима оценки затрат "По нулевой цене" (при котором себестоимость оценивается 1 раз в месяц, а не в каждом документе), отчет позволит детализировать финансовый результат до конкретных документов продаж и заказов покупателей.
2. Для больших баз, его производительность будет значительно выше любого отчета, правильно (т.е. по среднемесячной оценке для каждого месяца продаж, а не с усреднением за весь период выборки) рассчитывающего прибыль прямой выборкой себестоимости из регистра "УчетЗатрат".
Так, например, в моей практике, для некоторой организации, использующей УПП для учета в производственной-торговой деятельности, отчет за год выборкой из "УчетЗатрат" выполнялся примерно 15 минут, а типовой отчет "Валовая прибыль" начал выполняться за несколько секунд. При этом, каждый ежемесячный расчет себестоимости по управленческому учету проводился около 5 минут, а вот его допроведение занимало дополнительно всего лишь около 2 секунд.
3. Следует отметить, что при любом режиме оценки затрат, себестоимость каждой номенклатуры в каждой реализации будет все равно определяться отчетом по среднемесячной оценке. При выбранном режиме оценки затрат "По прямым" себестоимость де-факто прописывается в регистры РАУЗ каждым расходным документом по среднескользящей оценке, на что некоторые пользователи сознательно рассчитывают, и лишь в конце месяца корректируется до среднемесячной оценки.
Т.е. если вам нужна прибыль по среднескользящей оценке, при включенном режиме оценки затрат "По прямым", то эта обработка не подойдет, однако в комментариях могу пояснить, что можно сделать в этом случае.
Для начала эксплуатации (без изменения конфигурации) скачайте обработку по ссылке ниже, задайте период и нажмите "Выполнить". В типовых конфигурациях дату запрета редактирования отключать не потребуется, т.к. регистр "ПродажиСебестоимость" к ней нечувствителен.
Разумеется, если после использования данной обработки, документы "Расчет себестоимости выпуска" будут перепроведены, потребуется запустить обработку за этот период повторно, чтобы восстановить правильные движения по регистру "ПродажиСебестоимость".
При незначительной доработке конфигурации возможно сделать так, чтобы правильные движения формировались автоматически при проведении документа "Расчет себестоимости". Для этого необходимо:
1. Экспортную функцию "ДопровестиРасчетСебестоимости" из модуля обработки вынести в собственный серверный общий модуль.
2. Добавить подписку на событие "Обработка проведения" для документа "Расчет себестоимости выпуска", и в качестве обработчика передать вышеуказанную функцию.
Пример настройки подобной подписки на событие представлен на рисунке:
Здесь в серверный модуль в_Подписки вынесена функция "ДопровестиРасчетСебестоимости" из предложенной к загрузке обработки, и указана в качестве обработчика события для подписки "в_ПриПроведенииРасчетаСебестоимости_ДопровестиДляВаловойПрибыли".
Предложенная доработка не затруднит обновление конфигурации, но позволит не следить за своевременностью допроведения документов при их эпизодическом проведении задним числом.
Ограничения
1. Логика обработки в данный момент прописывает в ПродажиСебестоимость только себестоимость проданных товаров. Себестоимость комиссионных товаров и себестоимость производственных услуг в данный момент не считается, однако ее можно доработать самостоятельно, или на заказ.
2. В случае, если в РАУЗ отключен управленческий учет (т.е. используется режим "Регламентированный учет" или "Регламентированный учет с дополнительной аналитикой") данные по себестоимости будут браться из бухгалтерского учета (регистр "УчетЗатратРегл").
Поскольку в бухгалтерском учете себестоимость хранится очищенная от НДС, а типовой отчет "Валовая прибыль" "предполагает", что себестоимость включает в себя НДС, то он будет завышать эффективность (наценку) на ставку НДС (т.е. 10% или 18% (20%).
Для решения проблемы можно сделать следующее:
а) Самый правильный способ. В учетной политике по управленческому учету включить флаг "Не включать НДС в стоимость партий". См. рисунок.
б) Точечно исправить отчет "Валовая прибыль", заставив его учитывать такой случай. По аналогии исправить иные управленческие отчеты по прибыли.
// Отчет "Валовая прибыль", модуль объекта
Процедура СформироватьОтчет(ТабличныйДокумент) Экспорт
// Перед формирование отчета можно установить необходимые параметры универсального отчета.
УчетнаяПолитика = ОбщегоНазначения.ПолучитьПараметрыУчетнойПолитикиУпр(?(НЕ ЗначениеЗаполнено(УниверсальныйОтчет.ДатаКон), ТекущаяДата(), УниверсальныйОтчет.ДатаКон), Ложь);
// +stvorl исправлена проблема с завышением прибыли на НДС, если себестоимость определяется по данным регл. учета
//УниверсальныйОтчет.ПостроительОтчета.Параметры.Вставить("НеВключатьНДСВСтоимостьПартий", ?(НЕ ЗначениеЗаполнено(УчетнаяПолитика), Ложь, УчетнаяПолитика.НеВключатьНДСВСтоимостьПартий));
УниверсальныйОтчет.ПостроительОтчета.Параметры.Вставить("НеВключатьНДСВСтоимостьПартий", ?(НЕ ЗначениеЗаполнено(УчетнаяПолитика), Ложь, УчетнаяПолитика.НеВключатьНДСВСтоимостьПартий)
или Константы.РежимИспользованияРасширеннойАналитикиУчетаНоменклатурыИЗатрат.Получить() <> Перечисления.РежимыИспользованияРасширеннойАналитики.УправленческийИРегламентированныйУчет);
// -stvorl
УниверсальныйОтчет.СформироватьОтчет(ТабличныйДокумент,,, ЭтотОбъект);
КонецПроцедуры // СформироватьОтчет()
Совместимость
Последний раз тестировалось на конфигурациях:
- Комплексная автоматизация 1.1.111.1
- Управление производственным предприятием 1.3.115.2
Не ожидается затруднений при работе на более старых (как минимум, двухгодичной давности) релизах, а также при использовании в отраслевых решениях на базе КА 1.1 и УПП 1.3.
История изменений
21.01.2019 - Первоначальная редакция.
31.01.2019 - По замечанию пользователя xan333 учтен случай, когда в режиме РАУЗ используется детализация, не предусматривающая управленческого учета ("Регламентированный учет" или "Регламентированный учет с дополнительной аналитикой").
