Разработка системы резервирования товаров в самописной конфигурации — это задача, требующая не только навыков кодирования, но и глубокого понимания архитектуры данных. Основная сложность заключается в контроле временных интервалов: как не допустить «наползания» одного резерва на другой, как учитывать бессрочные заявки и где хранить историю изменений, если даты в документах приходится корректировать. Рассмотрим комплексный подход к решению этой задачи, опираясь на лучшие практики разработки на платформе 1С.
Проанализируем ситуацию: автор темы изначально использовал периодический РегистрСведений. Это допустимо для хранения параметров (например, «кто зарезервировал»), но крайне неудобно для количественного учета. В 1С для работы с остатками профессиональнее использовать РегистрНакопления. Разберем два подхода:
Рекомендация: Оптимальным вариантом для самописной конфигурации будет использование РегистрНакопления типа «Остатки» для контроля жестких резервов и дополнительного РегистрСведений для хранения графиков и периодов. В продвинутых системах (например, ERP) используется механизм «График движения товаров», который мы и попробуем эмулировать.
Рассмотрим главную проблему автора: сотрудник А резервирует товар с 01.08 без даты окончания, а сотрудник Б хочет зарезервировать этот же товар с 31.08 по 10.09. Чтобы система работала корректно, нам нужно внедрить алгоритм проверки свободного остатка на каждый день внутри выбранного периода.
Вместо того чтобы физически менять даты в первом документе (что ведет к потере исходных данных), мы будем анализировать «окно доступности». Разберем по шагам, как это реализовать в коде при проведении нового документа:
ДатаНачала по ДатаОкончания нового документа.ДатаОкончания не заполнена, подставляем максимально возможную дату (например, 31.12.3999), как советовали участники форума.Пример структуры запроса для проверки пересечений:
Запрос = Новый Запрос;
Запрос.Текст =
"ВЫБРАТЬ
| РезервыОстатки.Номенклатура,
| РезервыОстатки.КоличествоОстаток КАК Зарезервировано
|ИЗ
| РегистрНакопления.РезервыТоваров.Остатки(&ДатаПроверки, Номенклатура = &Номенклатура) КАК РезервыОстатки";
// В цикле проверяем каждую значимую дату периода
Если в какой-то из дней свободный остаток (Общий остаток на складе минус сумма всех активных резервов) становится меньше требуемого, документ не должен проводиться. Система выдаст ошибку: «На период с 31.08 по 10.09 товар уже зарезервирован другим сотрудником».
Бессрочный резерв — это управленческий риск. Чтобы система не превратилась в «кладбище» забытых товаров, проанализируем следующие инструменты:
РегламентноеЗадание, которое каждую ночь проверяет регистр и, если текущая дата больше даты окончания резерва, формирует документ «Корректировка резервов», высвобождая товар.Автор задавался вопросом: где хранить факт смещения дат? Если мы все же решили автоматически «подвинуть» старый резерв, чтобы дать место новому, нам нужно сохранить историю для разбора конфликтных ситуаций.
Проанализируем варианты:
ДатаПо изменилось с «пусто» на «30.08».РегистрСведений.ЛогИзмененийРезервов. При программном изменении дат будем записывать туда:
Рассмотрим интересную идею из обсуждения: создание виртуальных складов под каждого сотрудника. Когда менеджер резервирует товар, мы делаем документ ПеремещениеТоваров с основного склада на «Склад Иванова».
Преимущества:
Сложности: Нужен строгий партионный учет. Если мы просто переместили 10 штук, а потом менеджер их не продал, нам нужно вернуть их обратно. Без привязки к документам поступления (партии) на виртуальном складе может возникнуть пересортица или трудности с расчетом себестоимости. Однако для целей именно управленческого «бронирования» этот метод является самым наглядным для пользователей.
Чтобы сотрудники «хотели думать» и видели ситуацию наглядно, разработаем простое АРМ (автоматизированное рабочее место). Используем элемент формы ДиаграммаГанта. По оси X пустим время, по оси Y — список товаров. Полоски будут показывать занятые периоды. Если менеджер увидит, что вся полоса по конкретному артикулу «закрашена», он не будет пытаться создать пересекающийся резерв, а сразу перейдет к переговорам с коллегами.
Подведем итог: Для качественного учета резервов в самописной конфигурации следует отказаться от простого изменения дат в документах. Правильный путь — это контроль остатков в разрезе времени с помощью регистров накопления, внедрение жестких регламентов по срокам жизни резерва и использование механизмов версионирования для отслеживания истории правок.