Приветствую

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

Есть документы, в комментарии которых указаны значения недостающих реквизитов, пример:

ПКО1, комментарий: раб. время с 12 до 15 (зал3). Инкассации не было.
ПКО2, комментарий: Сдано за раб. время с 14 до 18 (зал3). Инкассация.
ПКО3, комментарий: Инкассация. раб. с 10 до 16 (зал1).
ПКО4, комментарий: раб. время с 10 до 12 (зал новый). Не инкассация.

Нужно вывести сумму ПКО-шек, сгруппировав их по залам.

Есть справочник Склады, в котором элементы имеют наименования, которые буква в букву (за исключением регистра) совпадают с текстом комментария:
Склад1, наименование: Зал1
Склад2, наименование: зал2
Склад3, наименование: зал3
Склад4, наименование: Зал Новый
Склад5, наименование: левый приход

Но если в комментарии не указан склад - группировать по складу - "левый приход"

-----

Сейчас всё делаю построчной проверкой "Найти(Комментарий, Склад.Наименование)", но чё-то долго как-то. А тут же эскуэль есть!! Одно не въехать - как? А вдруг в комментарии попадётся _два_ склада?? Есть мысли - напишите пожалуйста.

        Запрос.Текст = 
        "ВЫБРАТЬ
        |    Игроки.Ссылка
        |ИЗ
        |    Справочник.Игроки КАК Игроки
        |ГДЕ
        |    Игроки.Наименование ПОДОБНО &Наименование";
        Запрос.УстановитьПараметр("Наименование",Текст+"%");

Комментарии неограниченной длины - не знаю как с ними работать будет. Ну и наверно добавить"%"+ нужно:
в Запрос.УстановитьПараметр("Наименование","%"+Текст+"%");

Что б работало надо как-то так сделать:

ВЫРАЗИТЬ(Комментарий КАК СТРОКА(100500))

Логично. Суть в том, что получается несколько запросов по количеству элементов справочника Склады. А одним запросом? По сути - Ваше решение избавляет от проверки каждой строки, т.к. сервер отберёт только нужные строки - это да. Но если в каком либо документе нет склада, то дополнительный запрос на не входящие в найденные - это без указания склада, а вот если два склада и более указано, то в две выборки попадёт один и тот же документ, этот дополнительная свёртка результата с подсчётоми сортировкой по полю подсчёта - очень нагружено, в том числе и для сервера.

Поиск в комментариях - обречен на постоянный гембель. Где-то указали не так как в справочнике, где-то указали два склада, где-то вообще не указали.
А может пойти другим путем? Есть такое понятие в бухии как дополнительные реквизиты, может создать для документов доп. реквизит и обязать заполнять его для ПКО тех кто их создает.

Не понял слово ))


Обязать нельзя, нужно проверки ставить, а (к стыду своему) совсем не смог разобраться (как-то раз пробовал) что за зверь - дополнительные реквизиты. Дополнительный реквизит назначается сразу всем документам - нет, значит его ещё и добавлять нужно - это гемор, но если разобраться с архитектурой, то в момент записи можно проверять комментарий и добавлять этот реквизит, но как это должно происходить? Это регистр сведений или справочник какой?

Дополнительный реквизит добавляется сразу для всех документов, а заполняется индивидуально для каждого (как и любой реквизит).
Хранятся значения дополнительных реквизитов в регистре сведений "Значения дополнительных реквизитов".
Если пользователи будут заполнять их то всё будет хорошо.

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

Можно спросить, почему именно 100500?

Как по всем комментариям ПКО выяснить максимальную длину? С точки зрения оптимизации - это вряд ли поможет, но сам вопрос!

Это я образно.


Можно написать не сложную обработку, которая, которая переберёт все ПКО в базе и определит наибольший комментарий. Но это будет резальтат на текущий момент. А завтра (послезавтра, через недель, через 10 лет) кто-то может ввести комент больше. Поэтому просто надо логически определить сколько может понадобиться символов на это. А если внести пару строк кода - то можно в ПКО проверять длину комментария, таким образом гарантировать, что длина не будет превышать какое-то количество символов.

Ясно, думал ограничение системы ))



Не-не! По поводу обработки - это не то, именно получив выборку - узнать какова максимальная длина комментария - вот вопрос. Есть ли функция вычисления длины, там, что-то такое?

А проверки написать - это, конечно, вариант, но как правило, логическая оценка даст результат и до первого крика "Мой склад отчёт не видит, а он ЕСТЬ!" ))

Крики будут постоянно, потому что основываться на комментарий нельзя.
Вариант с использованием формирования отчета без прямой связи между ПКО и складом считаю абсурдным

В документе должна быть прямая ссылка на склад (кстати сам реквизит есть просто не во всех операциях участвует). Можно сделать доступным реквизит "Склад" для всех операций и сделать обязательным к заполнению. Но это доработка типового объекта.
Или как я говорил - организовать работу с дополнительными реквизитами без доработки типового объекта.

А общие реквизиты возможно использовать для решения данной задачи?

В 8-ке нет понятия общих реквизитов, они были в 7.7.
Так что уточните что Вы имеете ввиду

А в 8.14 вроде есть, если я не ошибаюсь

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

Тогда хз, я ещё не переходил на 8.2.14