← На главную

При работе в связке «1С:Управление торговлей 10.3» и «Битрикс» часто возникает потребность не просто видеть общие остатки, а отслеживать жизненный цикл конкретной партии: от момента оплаты поставщику до реализации конечному клиенту. Это необходимо для анализа оборачиваемости денежных средств и понимания рентабельности конкретных поставок. Рассмотрим подробно, как настроить систему и какие риски стоит учитывать при внедрении партионного учета в условиях активного обмена с сайтом.

Постановка задачи и анализ базовых механизмов

Основная цель — реализовать схему «оплатили поставщику — привезли — продали» так, чтобы в отчетах можно было увидеть связь между конкретным поступлением и конкретной реализацией. В типовой конфигурации УТ 10.3 партионный учет работает по методам FIFO, LIFO или «По средней». Однако для точного отслеживания «той самой единицы товара» стандартных настроек может быть недостаточно.

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

Вариант 1: Использование обособленного учета по заказам

Разберем механизм, заложенный в типовой конфигурации. В настройках договора с контрагентом (покупателем) существует важный флаг: ВестиОбособленныйУчетТоваровПоЗаказамПокупателей. Рассмотрим подробнее, как это работает:

1. Если этот признак установлен, то при проведении документа ЗаказПокупателя система начинает резервировать товар не просто на складе, а в регистре «Партии товаров на складах» с привязкой к конкретному заказу.
2. Это означает, что при поступлении товара (документ ПоступлениеТоваровУслуг), если он пришел под этот заказ, он будет жестко закреплен за ним по стоимости и количеству.
3. Проблема: Этот метод хорошо работает для стоимостного учета, но он накладывает ограничения. Например, если в договоре стоит такой флаг, вы не сможете просто так продать этот товар другому клиенту — система будет требовать именно тот заказ, под который товар зарезервирован.

Вариант 2: Резервирование в заказах поставщикам (Связка «Заказ-Заказ»)

Для решения задачи «деньги — товар — деньги» наиболее эффективным считается механизм размещения заказов покупателей в заказах поставщикам. Выясним причину, почему это удобно: так мы создаем прямую цепочку документов еще до того, как товар физически попал на склад.

Рассмотрим алгоритм настройки:

1. Переходим в «Настройка параметров учета», раздел «Заказы».
2. Убеждаемся, что включена возможность использования заказов поставщикам и резервирования.
3. При получении заказа с сайта (который в 1С падает как ЗаказПокупателя), в нем необходимо указать в колонке Размещение конкретный ЗаказПоставщику.

В этом случае, в момент проведения документа ПоступлениеТоваровУслуг, товар автоматически попадет в резерв под конкретного покупателя. Это позволяет внешним отчетом вытянуть всю цепочку: от оплаты счета поставщику до отгрузки клиенту.

Влияние на обмен с Битрикс: Характеристики и Серии

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

Использование характеристик:

Если каждая новая партия — это новая характеристика номенклатуры, то модуль обмена с Битрикс создаст для каждой характеристики отдельное Торговое предложение (SKU). На сайте это будет выглядеть как выбор конкретного варианта товара. Плюс в том, что остатки по каждой «партии-характеристике» будут синхронизироваться отдельно и корректно.

Использование серий:

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

Технические риски и работа «задним числом»

Важно помнить, что партионный учет в УТ 10.3 крайне чувствителен к последовательности документов. Разберем основные опасности:

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

Рекомендации по реализации отчета

Чтобы увидеть желаемый цикл «оплатили — привезли — продали», отчет должен строиться на соединении данных из нескольких регистров:

• Закупки (или ПартииТоваровНаСкладах при поступлении) — для анализа затрат и цен поставщика.
• Продажи — для анализа выручки.
• ВзаиморасчетыСКонтрагентамиПоДокументамРасчетов — чтобы понять, когда была произведена оплата поставщику и когда пришла оплата от клиента.

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

Выводы

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