При внедрении и настройке связки программных продуктов «1С:Управление торговлей 11» (УТ 11) и «1С:Бухгалтерия предприятия 3.0» (БП 3.0) специалисты часто сталкиваются с конфликтом интересов управленческого и регламентированного учета. Классический пример такого конфликта: отделу продаж для оперативной работы, резервирования и отслеживания поставок жизненно необходима сложная структура виртуальных складов (например, в разрезе конкретных поставщиков, заводов или транзитных зон), в то время как бухгалтерия категорически против «мусора» в своей базе. Бухгалтерам нужен простой и понятный учет по средневзвешенной стоимости на одном единственном реальном складе, где остатки оперативно закрываются день в день.
В этой статье мы подробно рассмотрим, как подружить эти две противоположные концепции, разберем по шагам техническую реализацию «схлопывания» складов при обмене, а также проанализируем возможные методологические риски и альтернативные варианты организации процесса.
---
Рассмотрим стандартный бизнес-процесс торговой компании-перекупщика. Компания приобретает товар у нескольких заводов-изготовителей и поставляет его конечным клиентам. Физически товар может даже не заходить на собственный склад компании, а отправляться напрямую от поставщика клиенту (транзитная торговля).
При этом требования подразделений выглядят следующим образом:
ЗаказКлиента, ставят товар в резерв и контролируют обеспечение. Учет должен вестись по ФИФО (возможно, с детализацией по сериям и срокам годности) для точного расчета маржинальности сделок.РеализацияТоваровУслуг, на конец дня остаток равен нулю. Любые расхождения, зависшие остатки или отрицательные балансы на виртуальных складах в бухгалтерской базе недопустимы, так как это напрямую влияет на расчет налога на прибыль и корректность сдачи отчетности.Если пытаться зеркально переносить все склады и документы из УТ 11 в БП 3.0, возникнет хаос. Бухгалтерия погрязнет в ручной корректировке себестоимости и исправлении отрицательных остатков на виртуальных складах. Выход из этой ситуации — разделение логики оперативного (управленческого) и бухгалтерского учета.
---
Выясним главное правило автоматизации бизнес-процессов: оперативный контур (УТ 11) должен отражать реальную деятельность менеджеров так, как им удобно вести продажи. Не нужно пытаться ограничивать аппетиты отдела продаж в УТ в угоду бухгалтерскому учету.
В УТ 11 мы настраиваем следующую цепочку документов:
ПриобретениеТоваровУслуг.ЗаказКлиента, в котором в качестве склада отгрузки указываем тот самый виртуальный склад, где размещен или ожидается товар. При необходимости используем механизмы резервирования (статусы «В резерве», «К обеспечению»).РеализацияТоваровУслуг с виртуального склада. Если склад ордерный, то дополнительно создается РасходныйОрдерНаТовары.При такой схеме в УТ 11 корректно собирается вся аналитика: менеджеры видят реальные остатки по направлениям закупок, резервы не «слетают», а маржинальный доход рассчитывается корректно по методу ФИФО.
---
Теперь разберем, как передать эти данные в БП 3.0 так, чтобы удовлетворить требования бухгалтеров. Для этого мы будем использовать типовой механизм подмены склада при обмене данными через формат EnterpriseData.
Выясним технические нюансы настройки:
Склады (например, «Основной склад») и указываем его в этой настройке.ПриобретениеТоваровУслуг) и реализации (РеализацияТоваровУслуг) правила обмена будут автоматически игнорировать многообразие виртуальных складов из УТ 11. Вместо них в шапку каждого перенесенного документа в БП 3.0 будет подставляться наш «Основной склад».Таким образом, в УТ 11 мы имеем детальный аналитический учет по десяткам складов, а в БП 3.0 — консолидированный учет на одном физическом складе. Проблема двойных реализаций или расхождений по складам полностью нивелируется на уровне правил обмена.
---
Проанализируем ситуацию с расчетом себестоимости списания товаров. В УТ 11 себестоимость рассчитывается по методу ФИФО (с учетом серий), а в БП 3.0 — по средней стоимости. Не будет ли здесь критических расхождений?
Важно понимать: при обмене данными из УТ 11 в БП 3.0 переносятся только количественные показатели и цены документов закупки/продажи. Проводки по списанию себестоимости (дебет счета 90.02 — кредит счета 41.01) Бухгалтерия формирует самостоятельно по своим собственным алгоритмам в момент проведения документов реализации или при выполнении регламентной операции «Закрытие месяца» (обработка «Корректировка стоимости номенклатуры»).
Поэтому расхождение методов учета в двух базах — это нормальная и допустимая ситуация. В УТ 11 управленческая себестоимость будет считаться по ФИФО, давая точную оценку рентабельности сделок для руководства. В БП 3.0 регламентированная себестоимость посчитается по среднему значению в соответствии с учетной политикой организации.
---
Хотя предложенная схема со «схлопыванием» складов выглядит изящно и просто, на практике могут возникнуть подводные камни, о которых необходимо знать заранее.
Бухгалтерская программа крайне чувствительна к хронологии проведения документов. Если в УТ 11 менеджеры оформляют реализацию задним числом или продают товар до того, как оператор провел документ поступления (пусть даже в рамках одного дня), в БП 3.0 возникнет ситуация, когда на «Основном складе» в момент проведения реализации товара физически нет.
Если в настройках БП разрешено списание запасов при отсутствии остатков, документ проведется, но себестоимость списания будет нулевой. При последующем проведении поступления себестоимость может не скорректироваться автоматически, что приведет к искажению финансового результата. Если же списание при отсутствии остатков запрещено, то обмен данными просто заблокирует проведение документов реализации в БП, и бухгалтеру придется вручную восстанавливать последовательность.
Решение: Установить в УТ 11 жесткий контроль остатков и запретить менеджерам проводить расходные документы «в минус». Регулярно запускать обработку «Групповое перепроведение документов» в БП 3.0 для восстановления последовательности.
В УТ 11 из-за учета ГТД или серий одна позиция номенклатуры в табличной части документа реализации может разбиваться на несколько строк с разными видами запасов. При переносе в БП 3.0 эти строки переносятся «как есть». В редких случаях это может приводить к копеечным погрешностям округления сумм НДС или общей стоимости. Рекомендуется периодически проводить сверку актов взаиморасчетов и оборотно-сальдовых ведомостей между базами.
---
Если на этапе проектирования системы вы понимаете, что создание сотен виртуальных складов в УТ 11 перегрузит справочники и усложнит жизнь пользователям, рассмотрим более цивилизованные альтернативы, заложенные в типовой функционал программы.
Если компания продает товар, который забирает у поставщика под конкретного клиента без размещения на собственном складе, вместо виртуальных складов логично использовать механизм обособленного обеспечения.
Разберем этот процесс по шагам:
ЗаказКлиента. Для товарных строк устанавливаем вариант обеспечения «Обеспечивать обособленно».ЗаказПоставщику. Система автоматически связывает этот заказ с заказом клиента.ПриобретениеТоваровУслуг товар поступает на один общий реальный склад, но в системе он сразу маркируется как «зарезервированный под Заказ клиента №Х». Ни один другой менеджер не сможет продать или перерезервировать этот товар.РеализацияТоваровУслуг с общего склада. Товар списывается обособленно.Этот метод исключает необходимость плодить виртуальные склады, сохраняя при этом жесткий контроль целевого назначения запасов.
Если заводы-поставщики отгружают товар, и право собственности переходит к нашей компании в момент отгрузки (товар юридически наш, но фактически еще едет к нам), в УТ 11 начиная с версии 11.4 реализован полноценный сценарий «Товары в пути».
В этом случае финансовый документ ПриобретениеТоваровУслуг оформляется сразу (он переносится в БП 3.0 для отражения затрат и НДС), а фактическое поступление на склад оформляется позже с помощью ордеров. Это позволяет разделить во времени переход права собственности и складской прием, избегая создания виртуальных транзитных складов.
---
Подводя итог, можно утверждать, что схема ведения детального оперативного учета по виртуальным складам в УТ 11 с последующей консолидацией на одном «Основном складе» в БП 3.0 является жизнеспособной и широко распространенной практикой. Она позволяет:
Для успешной реализации этой схемы достаточно настроить типовую синхронизацию данных через EnterpriseData, указав в настройках БП единый «Склад по умолчанию», и обеспечить административный контроль за хронологией проведения документов в УТ 11 во избежание появления отрицательных остатков.