Одной из частых задач при автоматизации логистики является отслеживание перемещения товарно-материальных ценностей (ТМЦ). Основная сложность заключается в том, что процесс «перекладывания» товара из одной точки в другую растянут во времени, а плановая дата прибытия — величина непостоянная. Давайте разберем, как правильно спроектировать архитектуру в 1С, чтобы получать актуальную информацию о том, «что летит» и «когда прилетит», не нарушая целостность регистров.
Классический подход к данной задаче подразумевает разделение учета на остатки и статусы. Вместо того чтобы пытаться впихнуть плановую дату в измерение регистра накопления (что приведет к дроблению записей и проблемам с производительностью), воспользуемся схемой «Товары в пути».
ТоварыНаСкладах и приход по регистру ТоварыВПути.ТоварыВПути и приход на склад-получатель.Эта схема позволяет видеть «зависший» товар на отдельном виртуальном складе, не привязываясь к датам в самих регистрах остатков.
Если ваша конфигурация поддерживает ордерную схему (например, 1С:Управление торговлей), используйте её возможности для фиксации факта. Ордерная схема разделяет финансовое движение и складскую операцию.
В ордере есть две ключевых даты:
Анализ отклонений строится путем сопоставления этих двух дат. Таким образом, плановая дата становится не измеримым ресурсом, а атрибутом документа или регистра сведений, что позволяет системе работать стабильно даже при многократных изменениях плана в течение дня.
Если вам необходимо хранить историю изменения плановых дат для последующего анализа эффективности планирования, рекомендуем следующий подход:
РегистрСведений, который будет хранить историю плановых дат.ИдентификаторПартии или СсылкаНаЗаказ.ПлановаяДата.Рассмотрим структуру такого регистра:
// Пример структуры регистра сведений для хранения плановых дат
// Измерения: ЗаказНаПеремещение (Справочник/Документ), НомерЭтапа (Число)
// Ресурс: ПлановаяДата (Дата)
// Реквизиты: АвторИзменения, Комментарий
Такой подход избавляет от необходимости перезаписывать документы или создавать «мусор» в регистрах накопления. Вы всегда можете получить текущую дату запросом к срезу последних, а историю — выбрав все записи по конкретному заказу.
Для сложных цепочек перемещений с промежуточными точками (складами) целесообразно внедрить понятие ИдентификаторПроцесса. Любое движение товара (отгрузка, перегрузка, приход) должно сопровождаться записью этого ключа в движения.
Это дает следующие преимущества:
Чтобы понять, «как оно ползло», разделите аналитические отчеты на два типа:
ТоварыВПути в разрезе идентификаторов заказа. Плановая дата берется «на лету» из последнего значения регистра сведений.ПлановыеДаты с фактическими датами закрытия ордеров. Разница между этими датами и даст вам искомую метрику качества планирования.Таким образом, мы уходим от перегрузки измерений регистра накопления, сохраняя при этом гибкость планирования и прозрачность оперативного учета.