← На главную

При организации учета в сетевой рознице на базе конфигурации «1С:Торговля и склад 7.7» пользователи и разработчики регулярно сталкиваются с двумя взаимосвязанными методическими проблемами при перемещении товаров между торговыми точками:

1. Необходимость учета товара в пути: при проведении типового документа Перемещение ТМЦ остатки списываются со склада-отправителя и моментально приходуются на склад-получатель. В реальной логистике товар может доставляться несколько дней, и на складе-получателе он должен появиться только по факту физической приемки.
2. Отрицательные («красные») остатки и сбитые партии в периферийных базах (ПБ): при использовании компоненты «Управление распределенными ИБ» (УРБД) с выборочной миграцией документов склад-получатель не видит первичных документов поступления и остатков склада-отправителя. При загрузке типового перемещения склад-отправитель уходит в минус по регистру ОстаткиТМЦ, а в регистре ПартииНаличие списываются пустые партии, что приводит к некорректному расчету себестоимости и срыву границы последовательности документов.

Разберем подробнее причины возникновения этих коллизий и рассмотрим проверенные практикой архитектурные решения.

Причины возникновения проблемы в платформе 1С 7.7

Проанализируем технические особенности конфигурации «Торговля и склад 7.7». В типовом документе Перемещение ТМЦ процедура ОбработкаПроведения() формирует движения жестко в рамках одной транзакции:

1. Расход со склада-отправителя по регистрам ОстаткиТМЦ и ПартииНаличие.
2. Приход на склад-получатель по тем же регистрам.

В механизме УРБД документ и его проводки мигрируют как неделимая сущность. Если в периферийной базе магазина-получателя не мигрировали документы ПоступлениеТМЦ по складу-отправителю, платформа не находит партий списания. В результате склад-отправитель уходит в отрицательное сальдо, а партии списываются без суммовой себестоимости. Выясним, какими способами можно организовать двухэтапное перемещение и сохранить целостность регистров.

Способ 1. Использование виртуального склада («Транзит / Товар в пути»)

Рассмотрим вариант, требующий минимальных доработок метаданных. Для каждого направления перевозки или для системы в целом заводится служебный виртуальный склад, например, «Товар в пути (Склад 1 - Склад 2)».

Процесс перемещения разделяется на два этапа:

1. Отгрузка: склад-отправитель оформляет документ Перемещение ТМЦ со своего склада на склад «Товар в пути». С этого момента остатки числятся на транзитном складе, отражая груз в экспедиции.
2. Приемка: склад-получатель по факту фактического прибытия товара вводит второй документ Перемещение ТМЦ со склада «Товар в пути» на свой физический склад.

Преимущества: зависший остаток на транзитном складе наглядно демонстрирует недостачу при перевозке, бой или задержку рейса. Контроль осуществляется стандартным отчетом по остаткам ТМЦ.

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

Способ 2. Статусная модель документа и подпись МОЛ получателя

Разберем доработку типового документа Перемещение ТМЦ. В структуру документа добавляются реквизит СтатусДокумента (со значениями: «Отправлен», «Принят») или признак ПодписьПолучателя, а также табличная часть для фактического приема (или колонка «Количество факт»).

Алгоритм проведения модифицируется следующим образом:

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

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

Способ 3. Разделение на два документа (Ордерная схема)

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

1. Расходный ордер (или Списание на транзит): оформляется на стороне отправителя и списывает товар со склада-донора.
2. Приходный ордер (или Оприходование с транзита): создается на стороне получателя по факту приемки.

В распределенной структуре каждый документ мигрирует только в свою область:

1. Расходный документ создается и проводится в базе отправителя и передается в Центр.
2. В базе получателя документ формируется на основании данных центра или заполняется вручную. При оприходовании партия создается локально, опираясь на учетную цену, переданную из центральной базы.

Сверка взаиморасчетов между складами и контроль зависшего в пути груза выполняются в Центре сопоставлением движений двух документов.

Способ 4. Схема купли-продажи между магазинами (Организационное разделение)

Проанализируем методически наиболее надежный подход для крупных розничных сетей с независимыми базами магазинов. Каждый магазин регистрируется в системе как отдельная фирма (или филиал с собственной учетной политикой).

Перемещение товаров между ними заменяется цепочкой документов купли-продажи:

1. Магазин-отправитель оформляет документ Реализация ТМЦ. Товар законно списывается со склада с расчетом себестоимости по правилам локальной базы.
2. Магазин-получатель оформляет документ Поступление ТМЦ от центральной организации или магазина-донора. Товар приходуется с формированием чистой новой партии.
3. При выявлении расхождений при транспортировке составляются акты расхождений, а разница относится на расчеты с перевозчиком или списывается на убытки.

Такой подход полностью устраняет конфликт регистров ОстаткиТМЦ и ПартииНаличие, так как в каждой локальной базе присутствуют только собственные складские движения и нет необходимости транслировать чужие первичные документы.

Способ 5. Полная миграция данных с интерфейсным разделением

Если конфигурацию решено оставить типовой и использовать стандартный документ Перемещение ТМЦ, единственный способ избежать «красных» остатков средствами УРБД — переключить правила миграции документов и справочников в режим «Все ИБ».

Чтобы пользователи филиалов не видели чужие документы и склады, применяются программные фильтры:

1. В модулях форм журналов и документов накладываются фильтры по текущему складу или подразделению пользователя.
2. В отчетах ограничивается выбор складов в зависимости от прав доступа.

В этом случае база получателя содержит полную партионную картину всей сети, документ перемещения всегда находит входящие партии склада-отправителя, а последовательность документов перепроводится без ошибок.