В процессе работы торговой компании часто возникает задача распределить один клиентский заказ по нескольким складам. Например, часть товара нужно отгрузить с центрального склада, а часть — из ближайшего магазина. Стандартные документы не всегда предоставляют удобный механизм для такой операции, особенно если требуется ручная корректировка автоматического распределения. Рассмотрим, как реализовать подобный диалог в 1С v7.7, проанализировав различные подходы.
Основная цель — создать интерфейс, который позволит пользователю видеть общую потребность в товаре и вносить изменения в количество, отгружаемое с каждого конкретного склада. Идеальный вариант — это наглядная таблица-шахматка, где по строкам идет номенклатура, а по колонкам — склады.
Этот подход, предложенный автором изначально, заключается в том, чтобы в табличной части документа (например, "Заказ" или "Перемещение") создать колонки под каждый склад: КоличествоСклад1, КоличествоСклад2 и так далее.
Преимущества:
Недостатки:
Вывод: Этот вариант подходит только как очень быстрое и временное решение, если вы на 100% уверены, что количество складов не изменится в обозримом будущем. В большинстве случаев от него лучше отказаться в пользу более универсальных методов.
Более правильный с точки зрения архитектуры данных подход. Вместо множества колонок для количества, в табличную часть документа добавляется один реквизит — Склад. Таким образом, одна строка исходного заказа разбивается на несколько строк в документе распределения.
Структура табличной части:
НоменклатураСкладКоличествоЦенаСуммаПреимущества:
Недостатки:
Вывод: Этот вариант идеален для хранения данных, но требует дополнительной надстройки над интерфейсом. Он отлично сочетается со следующим решением.
Это самый мощный и гибкий подход с использованием стандартных средств 1С 7.7. Идея заключается в том, чтобы отделить визуальное представление от физического хранения данных. Данные хранятся "правильно" (как в Решении 2), а для пользователя рисуется удобная "шахматка" с помощью элемента управления Таблица.
Разберем по шагам, как это реализовать:
Номенклатура, Склад, Количество в табличной части).ПриОткрытии()).
Здесь мы программно формируем нашу "шахматку". Сначала создаем колонки: "Номенклатура", "Всего заказано", затем по одной колонке на каждый склад из справочника, и в конце "Итого распределено". После этого перебираем строки табличной части документа и "сворачиваем" их, заполняя ячейки нашей визуальной таблицы.
ПриЗаписи() или по кнопке "ОК").
Это обратный процесс. Мы очищаем табличную часть документа, а затем в цикле обходим строки и колонки нашей визуальной таблицы. Для каждой ячейки, где указано количество больше нуля, мы создаем новую строку в реальной табличной части документа, указывая соответствующую номенклатуру и склад.
Посмотрим на примерный код логики чтения данных из таблицы:
Процедура ПрочитатьИзТаблицы()
// Очищаем реальную табличную часть документа
УдалитьСтроки();
// Получаем список складов, чтобы соотнести с колонками
СписокСкладов = СоздатьОбъект("СписокЗначений");
// ... здесь код заполнения списка складов в том же порядке, что и колонки
// Обходим строки нашей визуальной таблицы (элемент Таб)
Для НомСтр = 1 По Таб.ВысотаТаблицы() Цикл
// Получаем номенклатуру из первой колонки
ТекНоменклатура = Таб.ПолучитьЗначение(НомСтр, 1);
// Обходим колонки, соответствующие складам
Для НомКол = 1 По СписокСкладов.РазмерСписка() Цикл
ТекСклад = СписокСкладов.ПолучитьЗначение(НомКол);
// Номер колонки в таблице может быть сдвинут (например, первая колонка - номенклатура)
// Предположим, колонки складов начинаются с 3-й
КолонкаСклада = НомКол + 2;
ТекКоличество = Таб.ПолучитьЗначение(НомСтр, КолонкаСклада);
Если ПустоеЗначение(ТекКоличество) = 0 И ТекКоличество > 0 Тогда
// Если в ячейке есть количество, создаем строку в документе
НоваяСтрока();
Номенклатура = ТекНоменклатура;
Склад = ТекСклад;
Количество = ТекКоличество;
// ... заполняем остальные реквизиты (цена, сумма)
КонецЕсли;
КонецЦикла;
КонецЦикла;
КонецПроцедуры
Преимущества:
Недостатки:
Этот вариант похож на предыдущий, но вместо элемента Таблица используется невизуальный объект ТаблицаЗначений, который отображается на форме через элемент "ТаблицаЗначений".
Логика схожа: при открытии создаем ТЗ с колонками-складами, заполняем ее, а при записи — читаем данные из ТЗ и переносим в документ. Работа с данными в ТЗ программно несколько проще, чем с ячейками Таблицы.
Преимущества:
Недостатки:
Таблица. Нельзя объединять ячейки, сложнее управлять цветами.Это не столько интерфейсное, сколько архитектурное решение. Его можно комбинировать с любым из вышеописанных интерфейсов.
Суть подхода:
Преимущества:
Вывод: Это зрелый подход для компаний с выделенным отделом логистики. Он решает не только задачу интерфейса, но и задачу организации бизнес-процесса в целом.