Доработка УТ 11

1. В типовой конфигурации форма списка / выбора справочника «Номенклатура» предусматривает по сути три варианта навигации – навигация по иерархии самого справочника и отбор по виду номенклатуры + его свойствам и по товарам другого качества . Согласно выбранному варианту заполняется дерево отборов справа на форме.
Тек. заказчик хотел бы иметь возможность навигации по: реквизиту «Производитель» (СправочникСсылка); реквизиту «Вид номенклатуры»; дополнительным реквизитам со ссылочными типами, если такие будут (это минимум, есть желание, если уж дописывать, то реализовать как-то универсально варианты представления для всех реквизитов номенклатуры с типом СправочникСсылка по крайней мере в форме выбора и форме списка).
Пример для варианта иерархии «По виду номенклатуры» в представлении заказчика: должен производиться не отбор, как сейчас (предусмотрен выбор одного вида), а в дереве отборов строиться иерархический список самого справочника. При навигации по нему в списке номенклатуры слева должен производиться отбор по активному виду номенклатуры в дереве справа (абсолютно аналогично тому, как происходит при варианте навигации «По иерархии» сейчас).
То же самое для варианта «По производителю» и остальных реквизитов – должна отображаться форма списка соответствующего справочника, если справочник иерархический – с учетом иерархии.
Реализовать это необходимо в форме списка, форме выбора, формах обработок «Подбор товаров в документы продажи» и «Подбор товаров в документы закупки».
Единственное, насчет форм обработок «Подбор товаров в документы продажи» и «Подбор товаров в документы закупки»… Тут хорошо бы оценить влияние доработки на и без того чудовищную производительность этих форм. Если усугубит, то в них не делать.
2. Задача, над которой архитектурно я еще не думала вообще…
Номенклатура, продаваемая совместно: в тек. конфигурации это некий строящийся в соответствии с настройками поиска список товаров, который чаще продается вместе, чем другой. Механизм нельзя будет использовать с даты запуска ввиду того, что ему нужны будут записи в регистрах для поиска. В понимании заказчика это – номенклатура, которая всегда по умолчанию продается вместе, в комплекте. При этом она не представляет собой комплект в понимании конфигурации – она не собирается в одну единицу товара (пример: коммутатор и патч-корд к нему). Заказчик готов для каждого товара вручную заполнять и поддерживать список товаров, которые идут как дополнение к нему. Главная цель – при оформлении продажи не дать забыть менеджеру по продажам, что с коммутатором нужно продать патч-корд. При этом, поскольку часто покупатели являются или дилерами заказчика, или сист. интеграторами, они могут в одном счете заказывать много видов коммутаторов, и штатный механизм покажет в продаваемых вместе и их тоже – вот этого хотелось бы избежать. Соответственно, штатный механизм, видимо, использовать все же не следует (либо сделать функц. опцию настройки поиска номенклатуры, продаваемой совместно – это наиболее правильно).
Интерфейсно в форме выбора и форме подбора в документы продажи для тек.строки списка номенклатуры нужно в дополнительном поле (снизу) отображать список товаров, продающихся с ним в комплекте, и реализовать обработку выбора номенклатуры из этого поля непосредственно. При этом отображать нужно товары, которые являются комплектом к данному, и также товары, в комплект которых входит данный.
Хранить при таком подходе можно в ТЧ справочника «Номенклатура» (первое, что приходит на ум. Имеющийся справочник «Варианты комплектации» лучше не использовать – в номенклатуре заказчика есть и реально собираемые изделия, продукция. Он просто запутается. ), либо в каком-нибудь регистре сведений (не думала над его структурой), но ввод данных будет интерактивным из карточки номенклатуры.