← На главную

При переходе с устаревших конфигураций («Торговля и склад 7.7», «Управление торговлей 10.3») на современную «1С:Управление торговлей 11» (или «1С:ERP», «1С:Комплексная автоматизация») ключевым камнем преткновения часто становится механизм расчета себестоимости. Пользователи и руководство привыкли видеть финансовый результат и списанную себестоимость сразу в момент проведения документа реализации и требуют от разработчиков «вернуть все как было». Разберем, почему переписывание себестоимости в УТ 11 на оперативное списание — это архитектурно тупиковый путь, к каким сбоям это приведет и как закрыть реальные потребности заказчика штатными инструментами системы.

Архитектурные различия: почему онлайн-расчет невозможен в УТ 11

В конфигурациях предыдущих поколений списание стоимости происходило непосредственно при проведении документа расхода по регистрам партий. В УТ 11 разработчики фирмы «1С» кардинально изменили концепцию. Рассмотрим ключевые причины, почему перенос старой логики разрушит учетную систему:

1. Математическая модель расчета (СЛАУ): В современной торговле и на распределительных складах регулярно возникают циклические операции — кольцевые перемещения между складами, возвраты товаров из партий будущих периодов, интеркампани (перепродажи между собственными юридическими лицами), разборка и сборка комплектов. Для корректной стоимостной оценки таких цепочек программа строит систему линейных алгебраических уравнений (СЛАУ) за весь отчетный период. Рассчитать точную стоимость в момент проведения единичного документа математически невозможно, так как исходная стоимость партии зависит от операций, которые будут совершены позже в этом же месяце.
2. Разделение количественного и суммового контуров: В УТ 11 оперативный складской учет отделен от финансового. Документы товародвижения фиксируют только физические остатки товаров на складах и факт перехода права собственности. Суммовая же оценка отложена до выполнения регламентных процедур.
3. Блокировки СУБД и производительность: Классический онлайновый партионный учет требует жестких транзакционных блокировок остатков партий на дату и время документа. При параллельной работе нескольких десятков пользователей по одним и тем же ходовым позициям это гарантированно приводит к взаимоблокировкам (deadlocks) и полному зависанию базы данных. Отложенный расчет позволяет менеджерам проводить накладные без задержек.
4. Конфликт с регламентными процедурами: Даже если разработчик создаст подписки на события и заполнит регистры СебестоимостьТоваров и ВыручкаИСебестоимостьПродаж вручную, при первом же штатном закрытии месяца документ РасчетСебестоимостиТоваров полностью перезапишет или сотрет эти движения согласно собственным математическим алгоритмам.
5. Разрушение механизмов НДС и интеркампани: С регистрами себестоимости неразрывно связаны механизмы раздельного учета НДС и автоматического формирования документов передачи между организациями. Вмешательство в проведение документов вызовет расхождения в налоговом учете и сбои при выгрузке в бухгалтерию.

Вариант 1: Настройка регламентного расчета предварительной себестоимости

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

1. Перейдем в раздел НСИ и администрирование — Обслуживание — Регламентные и фоновые задания.
2. Найдем регламентное задание Расчет себестоимости товаров.
3. Настроим расписание выполнения задания: например, каждый час или в обеденный перерыв и по окончании рабочего дня (в 13:00 и 19:00).
4. В настройках параметров финансового учета убедимся, что для оперативного контроля включен расчет предварительной себестоимости. В актуальных версиях с механизмом «Партионный учет 2.2» порядок распределения партий формируется фоновым заданием практически непрерывно, а стоимостные суммы подтягиваются регламентом.

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

Вариант 2: Контроль минимальной цены и маржинальности до момента отгрузки

Чаще всего требование «видеть себестоимость в накладной» продиктовано страхом продать товар в минус или необходимостью посчитать премию менеджера. Однако себестоимость в момент сделки не учитывает будущие допрасходы (транспортировку, хранение, изменение курсов валют). Сравнивать фактическую выручку с еще не сформированной себестоимостью методологически некорректно. Для контроля прибыльности продаж используем типовое ценообразование:

1. Создадим специальный вид цены — например, Плановая себестоимость или Минимальная цена продажи (раздел CRM и маркетинг — Настройки и справочники — Виды цен).
2. Настроим способ задания этой цены: она может рассчитываться динамически по формуле от цен поставщиков (с добавлением планового процента логистических затрат) либо фиксироваться документом Установка цен номенклатуры при поступлении товара.
3. В соглашениях об условиях продаж или в правилах ценообразования ограничим минимально допустимую цену отгрузки. При попытке менеджера выставить цену ниже установленной границы программа заблокирует проведение заказа клиента.
4. Для нестандартных ситуаций задействуем типовой бизнес-процесс Согласование заказа клиента. Если менеджеру необходимо отгрузить товар с минимальной наценкой, документ автоматически отправляется на согласование руководителю отдела продаж.

Вариант 3: Учет длинных сделок и распределение затрат будущих периодов

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

Для правильного управленческого анализа таких операций используем механизм сделок:

1. Включим функциональную опцию учета сделок (раздел НСИ и администрирование — CRM и маркетинг — Сделки с клиентами).
2. При оформлении заказов, поступлений товаров, поступлений услуг и накладных отгрузки указываем единую сквозную аналитику — конкретную Сделку с клиентом.
3. Транспортно-заготовительные и прочие дополнительные расходы регистрируем документом Приобретение услуг и прочих активов со статьей расходов, распределяемой на финансовый результат по направлению деятельности или непосредственно на сделку.
4. В отчетах по финансовым результатам формируем аналитику в разрезе сделок. Это позволяет получить достоверную маржинальность комплексного контракта независимо от того, в какие месяцы приходили первичные документы на закупку, логистику и реализацию.

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