Партионный учет в режиме распределенных баз данных ТКПТ 8

Основная проблема учета партий товаров в торговой сети связана с перемещениями между торговыми подразделениями. И заключается она в том, что в момент непосредственной отгрузки товаров с РЦ система:

1. Не может передать ссылки на списанные партии (т. к. для этого придется передавать всю накладную поступления, не принадлежащую подразделению получателю).
2. Как правило, после пересчета итогов дня/недели/месяца состав отгружаемых партий очень значительно меняется.

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

Главным недостатком данного метода считается отсутствие данных регистра партии в торговых подразделениях, что на первоначальных этапах внедрения представляет некоторое неудобство.

А также такая методика делает невозможным восстановление последовательности документов в информационной базе торгового подразделения — только в центральной базе (там же, где выполняется допроведение).

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

Предположим, что в момент отгрузки с РЦ одной единицы товара «Товар1» была списана партия «Поступление1» стоимостью 10 руб. за единицу. В базе магазина данная себестоимость была зафиксирована. По истечении некоторого периода времени товар был возвращен на РЦ и партия «Поступление1» по 10 руб. за единицу вернулась обратно. Это зафиксировалось в базе РЦ.

После чего в базе РЦ было проведено восстановление последовательности, в результате чего произошел пересчет партий и списана оказалась партия «Поступление4» стоимостью 11 руб. за единицу. Предположим, что система позволяет передать данной изменение в базу магазина, где в результате такой операции произойдет нарушение последовательности. Но последовательность в РЦ продолжает восстанавливаться и доходит до возврата из магазина партии, разумеется, «Поступление1», т. к. без пересчета последовательности в магазине система не сможет определить, какая партия «вернулась» на РЦ. В результате последовательность восстанавливается полностью. Такие ситуации, как показали исследования, случаются примерно в 90% случаев.

Но теперь аналогичная операция начинается в магазине, и, когда система доходит до документа возврата, меняя отгружаемую партию с «Поступления1» на «Поступление4», данное изменение передается в базу РЦ, нарушая там только что восстановленную последовательность. При среднем ассортименте РЦ 2–3 тысячи позиций приблизительно одна четвертая часть постоянно возвращается, в результате получаем около 500–700 таких «недоразумений», которые будут фактически ежедневно нарушать работу механизма восстановления последовательности.

Если от данного механизма отказаться, то это становится равносильно полному НЕ восстановлению последовательности.

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

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

Для того, чтобы задействовать механизм допроведения по партиям, необходимо выполнить ряд настроек в справочнике «Подразделения компании». 

Открыть справочник подразделения можно из меню «Справочники» → «Структура компании» → «Подразделения компании».

В открывшемся списке поочередно выделить каждый элемент и выбрать пункт «Изменить». В открывшейся форме установить подразделениям соответствующий режим проведения по партиям.

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

Для всех торговых подразделений необходимо установить режим «Партионные движения отсутствуют».

Для выполнения допроведения по партиям в ручном режиме следует открыть обработку «Модуль обмена данными» (Меню «Сервис → Функции РБД»).

В открывшейся форме перейти на закладку «Ручной обмен» и нажать «Допроведение по партиям».

По окончании допроведения система выведет соответствующее сообщение.

Настройку для выполнения автоматического допроведения можно установить в планировщике обмена, например, выполнить по завершении обмена со всеми узлами регламентной информацией (Z‑отчеты и инвентаризации). Для этого последний символ в параметрах последней задачи планировщика должен быть равен 1. НЕ рекомендуется выполнять допроведение после обмена с каждым узлом по регламентному плану обмена. Рекомендуется выполнять допроведение 1 раз в течение 1 сеанса обмена и только после обмена с последним узлом.

Рекомендованные статьи о ПП ТКПТ 8:

• Управление потоками информации в режиме распределенных баз данных ТКПТ 8
• Управление электронным оборудованием в «1С‑Рарус: Торговый комплекс. Продовольственные товары. Редакция 8»