Переход на конфигурацию «1С:Управление торговлей 11» (УТ 11) со старых систем, таких как «Торговля и Склад 7.7» или «Управление торговлей 10.3», часто вызывает у пользователей и разработчиков замешательство. Один из самых частых вопросов: почему после проведения документов продажи менеджеры не видят сиюминутную маржинальность, а в регистрах остатков отображается «неадекватная» стоимость? Разберем подробно внутреннюю архитектуру учета себестоимости в УТ 11, выясним, в каких регистрах хранятся нужные данные, и найдем способы решения этой проблемы.
Для начала проанализируем структуру регистров накопления УТ 11. В отличие от предыдущих поколений систем автоматизации, где количественный и суммовой учет велся параллельно в оперативных регистрах в момент проведения документов, в УТ 11 применена концепция разделения транзакционной нагрузки.
Основным регистром, который содержит одновременно и количество, и стоимость остатков, является регистр накопления СебестоимостьТоваров. Рассмотрим его особенности:
Вторым важным регистром является ВыручкаИСебестоимостьПродаж. Он предназначен для фиксации финансовых результатов продаж (выручки, себестоимости, маржинального дохода). Однако важно понимать, что этот регистр хранит только обороты продаж в разрезе аналитик и не содержит остатков товаров на складах.
Выясним причину, почему при просмотре записей регистра СебестоимостьТоваров или формировании стандартных отчетов сразу после оформления продажи мы видим нулевую или некорректную себестоимость.
В УТ 11 реализован так называемый отложенный расчет себестоимости. В отличие от «семерки» или «десятки», система не пытается рассчитать точную стоимость списания по ФИФО или средней цене непосредственно при проведении документа списания. Это сделано для повышения производительности системы при многопользовательской работе: оперативное списание партий привело бы к постоянным блокировкам таблиц базы данных.
В течение месяца пользователи просто оформляют документы движения товаров, фиксируя количественные изменения. Суммовая оценка «догоняет» количественный учет только после запуска регламентных процедур. Без их выполнения себестоимость в регистрах будет отсутствовать либо соответствовать устаревшим или оценочным данным, что пользователи и называют «неадекватной стоимостью».
Если менеджеры привыкли оперативно оценивать маржинальность сделок, мы не можем заставить их ждать конца месяца для получения точных цифр. Для решения этой задачи задействуем механизм предварительного расчета себестоимости.
Проанализируем порядок действий для настройки автоматического расчета предварительной стоимости:
Расчет предварительной себестоимости товаров. Мы можем задать расписание, по которому система будет производить расчет (например, каждый час, каждые 15 минут или раз в сутки в ночное время).Регламентное задание рассчитывает себестоимость по методу средней взвешенной оценки (или по скользящему ФИФО в зависимости от версии УТ). После успешного выполнения задания регистр накопления СебестоимостьТоваров заполняется суммовыми данными, и менеджеры смогут видеть близкую к реальности маржу в отчетах.
Если постоянный расчет себестоимости слишком сильно нагружает сервер базы данных или учет ведется с частым вводом документов «задним числом», рассмотрим альтернативный подход. Мы можем оценивать остатки товаров на складах не по фактической себестоимости, а по плановым или зарегистрированным ценам закупки.
Для этого в системе предусмотрены специализированные отчеты:
Ведомость по товарам организации в ценах номенклатурыВедомость по товарам на складах в ценах номенклатурыРазберем по шагам, как настроить этот механизм для оперативного контроля:
Установка цен номенклатуры по этому виду цен. Это можно автоматизировать с помощью подписки на событие или регламентного задания.Если перед нами стоит задача отображать расчетную прибыль и наценку непосредственно в форме документа продажи (например, в Заказе клиента или Реализации товаров и услуг) в момент его подбора, нам потребуется написать небольшое программное расширение.
Поскольку обращаться к регистру СебестоимостьТоваров в режиме реального времени не всегда эффективно (из-за отсутствия актуального расчета), правильным решением будет получение последней цены закупки из регистра сведений ЦеныНоменклатуры. Рассмотрим пример программного кода, который решает эту задачу для выбранной номенклатурной позиции.
Функция ПолучитьПоследнююЗакупочнуюЦену(Номенклатура, ДатаРасчета) Экспорт
Запрос = Новый Запрос;
Запрос.Текст =
"ВЫБРАТЬ РАЗРЕШЕННЫЕ ПЕРВЫЕ 1
| ЦеныНоменклатурыСрезПоследних.Цена КАК Цена,
| ЦеныНоменклатурыСрезПоследних.Валюта КАК Валюта
|ИЗ
| РегистрСведений.ЦеныНоменклатуры.СрезПоследних(&Период, ВидЦены = &ВидЦеныЗакупки И Номенклатура = &Номенклатура) КАК ЦеныНоменклатурыСрезПоследних";
// Предполагается, что вид цены закупки определен в константах или настройках
Запрос.УстановитьПараметр("Период", ДатаРасчета);
Запрос.УстановитьПараметр("Номенклатура", Номенклатура);
Запрос.УстановитьПараметр("ВидЦеныЗакупки", Справочники.ВидыЦен.НайтиПоНаименованию("Закупочная"));
Выборка = Запрос.Выполнить().Выбрать();
Если Выборка.Следующий() Тогда
Возврат Выборка.Цена;
КонецЕсли;
Возврат 0;
КонецФункции
Используя этот метод, мы можем при изменении состава табличной части документа оперативно рассчитывать плановую себестоимость строки и выводить маржинальность сделки на экран пользователя еще до того, как документ будет записан в базу данных и обработан процедурой закрытия месяца.
Мы выяснили, что в УТ 11 единственным полноценным источником данных по количеству и стоимости остатков является регистр накопления СебестоимостьТоваров. Однако специфика системы требует обязательного выполнения регламентных процедур для получения актуальных сумм. Для оперативной работы мы рекомендуем комбинировать использование регламентных заданий предварительного расчета себестоимости и ведение управленческих видов цен закупки.