У клиента много самовывоза. Крупные (по составу номенклатуры) собирают заранее, но реализацию создают в момент выдачи заказа. Возникают казусы: пришел покупатель за товаром, кладовщик глянул на стеллаж собранных заказов, не заметил нужный, начинает его заново собирать - теряется время, и возникает неразбериха с товаром.
Поэтому клиент пожелал дополнительный статус заказа, чтобы кладовщик в журнале заказов сразу видел в поле "Текущее состояние", собран ли заказ, если да, то на какой полке находится.
Сильно менять конфигурацию, добавлять новый статус заказа не хочется. Может кто-то решал подобную задачу?

Можно использовать дополнительные сведения.

(1) Для обычных форм наверное наилучшее решение. А для УФ наверное другие есть?

(2) Ты посмотри сначала. Я про УТ11 говорил.

Если создаете реализацию в момент выдачи, то это и есть твой статус фактической выдачи.
А заказ переводи в статус к отгрузке только после сборки заказа.
Для информации местонахождения собранного заказа можно использовать доп.реквизит

Хочется предложить ордера при отгрузке, но, возможно, это лишнее

(0) Ордера + отчет Состояние выполнения заказа

(4) > А заказ переводи в статус к отгрузке только после сборки заказа.
В статус к отгрузке ставят при поступлении оплаты (или частичной). Служит лишь разрешением кладовщику на выдачу товара.
(5) Собранные заказы остаются на том же складе. Можно конечно стеллаж собранных заказов сделать отдельным складом, но как-то сложно (доп. сведения или реквизит проще). Возможно, когда захотят адресное хранение внедрить.

(6) ну как захотите адресное хранение/работу внедрить - обращайся.

Чисто организационно можно попробовать решить, зависит от наличия площади на складе.

зона "ГОТОВЫХ заказов" - заказ в этой зоне находится только в том случае, если заказ полностью физически готов к отгрузке. Факт готовности заказа - визуально, по наличию заказа в этой зоне (лист с номером заказа, крупно, на первой паллете/коробке)

если в УТ11 не используете адресное хранение - то тут я дальше не спец ;-) но думаю, вывернуться каким-нить доп.реквизитом можно...

Успехов!!

(7) зона "ГОТОВЫХ заказов" - типа ячейки склада?
Адресное хранение в УТ11 сильно отличается от Альфа-Авто?

(6) Оставаться на складе товар может. но он же условно "в зоне отгрузки". Так вот у ордера есть статус, который определяет такие товары.
Плюс отчет состояние выполнения у заказа показывает состояние всех позиций в заказе.

(9) Ордера вводить имеет смысл при адресном хранении. Или в УТ11 ни так как Альфа-Авто? Там ордерный и ячеистый склад объедены в одно понятие. Накладные двигают регистр Остатки товаров, а ордера - Остатки товаров на ордерном складе, который в измерениях имеет "Ячейка". Поэтому отчеты остатков можно получать вплоть до ячейки. В УТ11 также? (не приходилось использовать).

(10) Ордер имеет смысл вводить при обособлении работы склада.
Ячейки в данном случае ни при чем.

(8) из твоего контекста я пон,л сто адресного склада с адресной работой нет. Поэтому зона готовых заказов это именно физически выделенная зона. Отдельная. Не смешиваемая с другими участками обработки заказов

(8) в какой конфиге ты работаешь и по каким процессам неясно. Складское обслуживание заявок в своей сути везде одинаково. Если нет достаточной автоматизации то недостатки компенсируются размерами свободного места и правильной диспетчеризацией расстановкой заказов в таких зонах. Ничего нового и необычного тут никто вряд ли поидумает

Если есть нормальная складская система то готовность заказа видна без всяких статусов. Статусы это некий учетный контур определённых флажков по которым нет данных в леративном режиме.
Если складская система есть то всегда можно посмотреть или отобразить текущее состояние заказа. Соответственно ауп склада видит текущее состояние заказа из учётной системы сваливается флажок разрешения к отгрузке от менеджеров. Например у меня таким флажком является собственно в складской система наличие документ.отгрузка. а он появляется когда в учётной системам выписали реализацию

(8) В УТ 11 и КА2 есть еще помещения. Можно этим воспользоваться
(10) Матчасть не знаешь.
При использовании ордеров не обязательно использовать ячейки.

(14) Для решения поднятого в теме вопроса, в УТ 11 все есть

(16) да я тоже так думаю.
Кстати если волокешь в ут11 в складской блоке - если есть желание то провести мне экскурсию за денежку по складским возможностям ут11?

(17) Не знаю, волоку я или нет.
Но экскурсию, наверное, мог-бы провести.
Наверное, правильнее было-бы, для начала, кинуть последовательность действий, которые хотелось отразить.
я бы попробовать пройтись по системе, чтобы не придумывать чего-то. Иногда, объяснение чего-то приводит к бОльшему пониманию того, о чем повествуешь

(18) стукайся в скайп Zlopun через часика полтора если что

(0) "на стеллаж собранных заказов, не заметил нужный"- морду бить кладовщику не пробовали??
потому как, кладовщики могут меняться.. один не заметил, второй не захотел заметить, третий вообще не смотрел на стеллаж.. разорится же ж клиент под каждого недокладовщика статусы клепать.

(15) Вначале руководство за "Адресное хранение", но как только узнает, что для этого что-то нужно еще вводить, создавать, сразу против.
Решили обойтись доп. реквизитом (или свойством). Высказали пожелание, чтобы не загромождать форму списка Заказов клиента, не добавлять колонку с доп. реквизитом. А в колонке "Текущее состояние" вместо "Готов к отгрузке" выводилось "Собран: " + содержимое доп. реквизита (номер ячейки собранного заказа).
Смотрю в конфигураторе у Заказ клиента нет реквизита Состояние. Он формируется как реквизит формы. Но как, чет не пойму? Подскажите...

Нашел, из РС Состояния заказов клиентов. Теперь надо во фрагмент запроса:

    ВЫБОР
        КОГДА (НЕ ДокументЗаказКлиента.Проведен)
            ТОГДА ЗНАЧЕНИЕ(Перечисление.СостоянияЗаказовКлиентов.ПустаяСсылка)
        ИНАЧЕ
            ЕСТЬNULL(СостоянияЗаказовКлиентов.Состояние, ЗНАЧЕНИЕ(Перечисление.СостоянияЗаказовКлиентов.Закрыт))
    КОНЕЦ КАК Состояние,

Вставить замену на "Собран: " + Значение доп. реквизита, если он не пустой

(21) не надо мешать в одну кучу учетные функции учетных прог и функции прог, ведущих палнирование и регистрацию реальных событий - даже если вы будете это совмещать в однйо проге - это у вас ВСЕ РАВНО распадется на два практически НЕЗАВИСИМЫХ друг от друга контуров.
.
да какой нахрен менеджеру интерес видеть в какой ячейке склада стоит заказ клиента?
какой нахрен складу нужность знать фио клиента? и тд.
.
> Вначале руководство за "Адресное хранение", но как только
> узнает, что для этого что-то нужно еще вводить, создавать, > сразу против.

- ну заведи свое руководство ВНЕЗАПНО на свой склад в период сезона. и свози это же твое руководство на другой склад, который "адресное хранение где чтото ввели и создали" в такой же сезон. ну и пусть посмотрит на разницу. если руководство не заметит разницы - поздравляю. ВАМ НИЧЕГО НЕ НАДО.

(23) > да какой нахрен менеджеру интерес видеть в какой ячейке склада стоит заказ клиента?
В какой ячейке склада стоит заказ клиента может ему не интересно, но знать собран ли он - желательно. Специфика у них такая - много самовывоза. Мелкие заказы (1-3 позиции) не нуждаются в предварительной сборке. А крупные - желательно собрать заранее (например, после звонка клиента), чтобы не терять время во время выдачи, не создавать неразбериху на складе: заказ уже собран, а его вновь собирают. А номер ячейки - для примера, возможно что-то другое будут в "Отметка о сборке" писать.

+ (22) Дополнительные реквизиты имеют реквизиты: Свойство, Значение (тип: Характеристика.ДополнительныеРеквизитыИСведения) и ТекстоваяСтрока (неограниченная длина). Задал тип: Строка фиксированной длинны 100. На пустое значение проверять ТекстоваяСтрока? Но условие:

ВЫБОР
    КОГДА НЕ ДокументЗаказКлиента.Проведен
        ТОГДА ЗНАЧЕНИЕ(Перечисление.СостоянияЗаказовКлиентов.ПустаяСсылка)
    КОГДА ЗаказКлиентаДополнительныеРеквизиты.ТекстоваяСтрока <> """"
        ТОГДА ПРЕДСТАВЛЕНИЕ("Собран: " + ЗаказКлиентаДополнительныеРеквизиты.ТекстоваяСтрока)
    ИНАЧЕ ЕСТЬNULL(СостоянияЗаказовКлиентов.Состояние, ЗНАЧЕНИЕ(Перечисление.СостоянияЗаказовКлиентов.Закрыт))
КОНЕЦ

не работает из-за "неограниченная длина". Как быть?

(25) Попробуй поместить дополнительные значения во временную таблицу, в которой ограничишь значения. А потом во втором запросе используй это условие.

(25)Может быть, не стоит курочить штатный механизм?
Потом это все боком вылезет.
А ошибку из-за "неограниченная длина", можно исправить путем, ограничения в запросе этой длины, например, до первых 100 знаков. Или до стольких знаков, сколько нужно для работы.

(26) С этим разобрался:

    ВЫБОР
        КОГДА НЕ ДокументЗаказКлиента.Проведен
            ТОГДА ЗНАЧЕНИЕ(Перечисление.СостоянияЗаказовКлиентов.ПустаяСсылка)
        КОГДА (ВЫРАЗИТЬ(ДополнительныеРеквизитыЗаказКлиента.Значение КАК СТРОКА(1000))) <> """"
            ТОГДА "Собран: " + (ВЫРАЗИТЬ(ДополнительныеРеквизитыЗаказКлиента.Значение КАК СТРОКА(1000)))
        ИНАЧЕ ЕСТЬNULL(СостоянияЗаказовКлиентов.Состояние, ЗНАЧЕНИЕ(Перечисление.СостоянияЗаказовКлиентов.Закрыт))
    КОНЕЦ КАК Состояние,

работает, но пока он единственный доп. реквизит. Возможно будут добавлять еще. Поэтому еще надо в условии добавить проверку именно моего реквизита "Отметка о сборке".

Какая, нафиг, "Отметка о сборке"?
Это-же имеется все в штатных механизмах.
Склады ордерные? - Конечно. И там это все есть. Причем, не только событие "Отметка о сборке"

(29) В том то и дело, что не ордерные. Хотел их завлечь адресным хранением - пока не хотят.

Читаю задачу
"Поэтому клиент пожелал дополнительный статус заказа, чтобы кладовщик в журнале заказов сразу видел в поле "Текущее состояние", собран ли заказ, если да, то на какой полке находится."
Что тут непонятного? Если не хотят ничего делать и чтобы все было, пусть вручную учитывают.

(31) Да, вручную писать доп. реквизите "Отметка о сборке" например, "Да" (что угодно, лишь бы не пусто).
С запросом разобрался, конечный вариант:

    ВЫБОР
        КОГДА НЕ ДокументЗаказКлиента.Проведен
            ТОГДА ЗНАЧЕНИЕ(Перечисление.СостоянияЗаказовКлиентов.ПустаяСсылка)
        КОГДА НЕ ДополнительныеРеквизитыЗаказКлиента.Значение ЕСТЬ NULL
                И ДополнительныеРеквизитыЗаказКлиента.Свойство.Заголовок = "Отметка о сборке"
            ТОГДА "Собран: " + (ВЫРАЗИТЬ(ДополнительныеРеквизитыЗаказКлиента.Значение КАК СТРОКА(1000)))
        ИНАЧЕ ЕСТЬNULL(СостоянияЗаказовКлиентов.Состояние, ЗНАЧЕНИЕ(Перечисление.СостоянияЗаказовКлиентов.Закрыт))
    КОНЕЦ КАК Состояние,

Всем спс за помощь.

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

(33) Как заказали, так и сделал. А то, что ты предлагаешь - дело конечно хорошее, но лучше по нормальному, использовать штатные механизмы: ордерную схему, адресное хранение.
Может я был недостаточно убедителен, когда предлагал внедрить адресное хранение. В УТ11 не приходилось внедрять, смутно представляю. В Альфа-Авто - да, много допиливать пришлось. В автосервисе зачастую ремонтируют методом тыка: "давай попробуем это заменить", не пошло, "тогда вот это"... и так пока не угадают. В результате менеджер в накладной указал одно, а в складском ордере (кладовщик меняет) совсем другое. Основные остатки с ордерными не идут... Многое пришлось допилить, ну и организационно наводить порядок.
А в УТ11 как-то смутно всю эту кухню представляю... Может есть ссылки на статьи, где эта кухня хорошо описана?

(34)Ситуация, когда "менеджер в накладной указал одно, а в складском ордере (кладовщик меняет) совсем другое" вполне рабочая. Особенно, если офис и склады/магазины разнесены на расстояния. И по времени планирования и действия тоже могут быть довольно прилично разнесены. Так что для меня этот аргумент для оправдания.
И, все-же, она реализуема в УТ 11. Сложности в двух плоскостях. В правильной постановке учета(возможно, придется капитально пересматривать существующую) и в очень приличном изучении возможностей реализации штатными средствами(это стОит того). Приходится кругами ходить, пока более-менее определишь что, конкретно, для текущего бизнеса подойдет.
Я, например, тонны справочников(каталогов продукции) уже перелопатил как они устроены, поездил по другим конторам(типа, как покупатель), выискивая что-то общее и отличия в работе.

(34) "В автосервисе зачастую ремонтируют методом тыка: "давай попробуем это заменить", не пошло, "тогда вот это"... и так пока не угадают. В результате менеджер в накладной указал одно, а в складском ордере (кладовщик меняет) совсем другое."
- ну, как обычно.. особенности частного бардака.. ;-)
почему бы менеджеру в накладнйо не указывать ФАКТИЧЕСКИ сделанное, а не планируемое, раз факт сильно отличается от плана?

(35) наличие конкретной адресации (ячеечный учет) и фиксация выполняемых операций в нужных разрезах позволяют получить на складе все с точностью до исполнителя и момента времени. Ихобретать ничего не надо. или смотреть тащательно как это можно реализовать на штатном функционале УТ (просто/сложно/сизвращениями) или брать специализированное WMS-решение. где основы все прописаны давно уже.

а по сути любая складская операция - полный аналог бухгалтерии с двойной записью (ДтАналитикаКУДА-КтАналитикаОткуда, Исполнитель, ДатаВремя). и две операции одностороннего типа - вход ТМЦ на склад и выход ТМЦ со склада.

Смена состояния заказа на "Готов к отгрузке" делается только вручную, автоматом в типовом механизме ничего не предусмотрено? Например, все заказанное есть в наличии, ждут оплаты, оплата поступила, в заказе всего одна позиция, в сборке не нуждается... Речь о Интернет-магазине, в основном доставка почтой России. Есть доработки: при проведении оплаты формируется уведомление (e-mail, SMS) менеджеру. Хотелось бы и состояние заказа автоматом поменять, чтобы на складе его отгрузили.

(38)"состояние заказа автоматом поменять, чтобы на складе его отгрузили"
Если склад ордерный, то на рабочем месте кладовщика появится товар к отгрузке

(38) у меня для таких задач есть свой подход:
на типовую (например, УТ) навешиваются сбоку (один или несколько) Бизнес-процессы. Они привязываются к типовой ЗадачаИсполнителя обычно. Дальше. В бизнес-процессе прописывается вся бизнес-логика, предусматриваются реквизиты/таб.части для хранения ссылок на связанные (в данном случае, с каждой отгрузкой) документы и т.п. - заказ, реализация, с/ф, разные ордера и корректировки - всё что нужно.

Бизнес логика описывает уже создание разных доков на задачах и точках, всякие автоматические смены статусов, рассылки оповещений/уведомлений.. и главное, генерит при выполнении условий, очередную задачу очередному исполнителю. В соответствии с картой маршрута (собрать заказ, оформить документы, контроль оплаты и т.д.).

Для того, что бы исполнитель видел не дурацкий список задач на раб.столе, для каждого раб.места (кладовщик, менеджер, бухгалтер и пр.) создается свой АРМ, где в лаконичной форме все данные и кнопочки для выполнения конкретных задач. Например, кладовщик иногда вообще без мышки/клавы - всё сканером ш/к - сканируем сборочный лист, потом товары по нему- как то так даже иногда.
Короч, в АРМах появляются задачи, которые требуют выполнения, и кнопочки (или команды сканера) чтоб их выполнить. Как только задача выполнена - из АРМа она убегает и не отсвечивает.

всё выше перечисленное - ВАЖНО - исключительно сбоку от типовых механизмов, т.е. в рамках бизнес-процессов создаются, модифицируются и проводятся ТИПОВЫЕ, совсем не доработанные документы. Т.е. сотрудники оперируют своими задачами в АРМах, а в системе при этом создаются своим чередом документы в нужной последовательности.

разумеется, такое решение требует некоторого бюджета

(40)"разумеется, такое решение требует некоторого бюджета"
А что, есть лишние деньги? Может быть, их потратить тогда на того, кто даст совет использовать штатный функционал? И не городить рядом еще АРМы.

(41) Штатный функ это однозначно хорошо, если у "клиента" полтора заказа в день обрабатывается. Если же конвейер, и узкое место - скорость/четкость обработки заказа  - тратим, правильно, на хорошего советчика. А он берет калькулятор и аккуратно просчитывает результат/затраты по всем вариантам (не забывает - учитывает качество/стоимость/заменимость персонала) и сразу видит, городить АРМы или шапками закидывать

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

(42) Если контора серьезная, не "полтора заказа в день обрабатывается", то АРМы безусловно нужны. Главное, чтобы были "с боку", не нарушали типовой функционал. Иначе, после очередного обновления эти АРМы придется переписывать.
В моем случае клиент - небольшой Интернет-магазин, пока нет необходимости ни в ордерной схеме, ни в адресном хранении, ни в серьезных АРМах. Всего-то клиенту понадобились "Готов к отгрузке" разбить на пару под состояний заказа: "Готов к сборке" - если много позиций номенклатуры (например, более 3-х), и "Собран".
Добавлять новые СостоянияЗаказовКлиентов не стал, поскольку новые объекты - серьезное изменение конфигурации, может исказить типовой функционал. Решил обойтись чисто оформительскими методами.
Состояние "Собран" отображается изменением (32) запроса динамического списка. По такому же принципу хочу отображать "Готов к сборке":

ВЫБОР
    КОГДА НЕ ДокументЗаказКлиента.Проведен
        ТОГДА ЗНАЧЕНИЕ(Перечисление.СостоянияЗаказовКлиентов.ПустаяСсылка)
    КОГДА НЕ ДополнительныеРеквизитыЗаказКлиента.Значение ЕСТЬ NULL
            И ДополнительныеРеквизитыЗаказКлиента.Свойство.Заголовок = "Отметка о сборке"
        ТОГДА "Собран: " + (ВЫРАЗИТЬ(ДополнительныеРеквизитыЗаказКлиента.Значение КАК СТРОКА(1000)))
    КОГДА СостоянияЗаказовКлиентов.Состояние = ЗНАЧЕНИЕ(Перечисление.СостоянияЗаказовКлиентов.ГотовКОтгрузке)
            И ДокументЗаказКлиента.Товары.Количество() > 3
        ТОГДА "Готов к сборке (" + (ВЫРАЗИТЬ(ДокументЗаказКлиента.Товары.Количество() КАК СТРОКА(1000))) + ")"
    ИНАЧЕ ЕСТЬNULL(СостоянияЗаказовКлиентов.Состояние, ЗНАЧЕНИЕ(Перечисление.СостоянияЗаказовКлиентов.Закрыт))
КОНЕЦ

Но ДокументЗаказКлиента.Товары.Количество() в запросе не работает. Придется под запрос добавлять. Как это лучше сделать?

Пока сделал так:

    ВЫБОР
        КОГДА НЕ ДокументЗаказКлиента.Проведен
            ТОГДА ЗНАЧЕНИЕ(Перечисление.СостоянияЗаказовКлиентов.ПустаяСсылка)
        КОГДА НЕ ДополнительныеРеквизитыЗаказКлиента.Значение ЕСТЬ NULL
                И ДополнительныеРеквизитыЗаказКлиента.Свойство.Заголовок = "Отметка о сборке"
            ТОГДА "Собран: " + (ВЫРАЗИТЬ(ДополнительныеРеквизитыЗаказКлиента.Значение КАК СТРОКА(1000)))
        КОГДА СостоянияЗаказовКлиентов.Состояние = ЗНАЧЕНИЕ(Перечисление.СостоянияЗаказовКлиентов.ГотовКОтгрузке)
                И ТоварыЗаказКлиента.КоличествоСтрок > 1
            ТОГДА ВЫБОР
                    КОГДА ТоварыЗаказКлиента.КоличествоТовар < 10
                        ТОГДА "Готов к сборке: " + ПОДСТРОКА("123456789", ТоварыЗаказКлиента.КоличествоТовар, 1)
                    ИНАЧЕ "К сборке: 10 и более"
                КОНЕЦ
        ИНАЧЕ ЕСТЬNULL(СостоянияЗаказовКлиентов.Состояние, ЗНАЧЕНИЕ(Перечисление.СостоянияЗаказовКлиентов.Закрыт))
    КОНЕЦ КАК Состояние,

При этом пришлось добавить табличную часть Товары:

ИЗ
    Документ.ЗаказКлиента КАК ДокументЗаказКлиента
        ЛЕВОЕ СОЕДИНЕНИЕ РегистрСведений.СостоянияЗаказовКлиентов КАК СостоянияЗаказовКлиентов
        ПО (СостоянияЗаказовКлиентов.Заказ = ДокументЗаказКлиента.Ссылка)
        {ЛЕВОЕ СОЕДИНЕНИЕ РегистрСведений.СостоянияЭД КАК СостоянияЭД
        ПО (СостоянияЭД.СсылкаНаОбъект = ДокументЗаказКлиента.Ссылка)}
        ЛЕВОЕ СОЕДИНЕНИЕ Документ.ЗаказКлиента.ДополнительныеРеквизиты КАК ДополнительныеРеквизитыЗаказКлиента
        ПО ДокументЗаказКлиента.Ссылка = ДополнительныеРеквизитыЗаказКлиента.Ссылка
        ЛЕВОЕ СОЕДИНЕНИЕ (ВЫБРАТЬ
            ЗаказКлиентаТовары.Ссылка КАК Ссылка,
            СУММА(ЗаказКлиентаТовары.Количество) КАК КоличествоТовар,
            МАКСИМУМ(ЗаказКлиентаТовары.НомерСтроки) КАК КоличествоСтрок
        ИЗ
            Документ.ЗаказКлиента.Товары КАК ЗаказКлиентаТовары
        
        СГРУППИРОВАТЬ ПО
            ЗаказКлиентаТовары.Ссылка) КАК ТоварыЗаказКлиента
        ПО ДокументЗаказКлиента.Ссылка = ТоварыЗаказКлиента.Ссылка

Вроде все работает как надо, но оказалось, что в заказы кроме товара включают услугу по доставке (разную: почтой, курьером). Она в сборке заказа не участвует. Как бы ее исключить из КоличествоСтрок и КоличествоТовар?

(45) вариант первый
Разность товары и услуги в разные табличные части
Вариант второй
А не пофиг? Услугу всегда считать собранной изначально
???

(46) Да, информация выводится для кладовщика, какие заказы нужно собирать в первую очередь "К сборке: 10 и более", а какие по мере выдачи заказов. Поэтому услугу надо исключить.
Пока написал такой вариант:

ИЗ
    Документ.ЗаказКлиента КАК ДокументЗаказКлиента
        ЛЕВОЕ СОЕДИНЕНИЕ РегистрСведений.СостоянияЗаказовКлиентов КАК СостоянияЗаказовКлиентов
        ПО (СостоянияЗаказовКлиентов.Заказ = ДокументЗаказКлиента.Ссылка)
        {ЛЕВОЕ СОЕДИНЕНИЕ РегистрСведений.СостоянияЭД КАК СостоянияЭД
        ПО (СостоянияЭД.СсылкаНаОбъект = ДокументЗаказКлиента.Ссылка)}
        ЛЕВОЕ СОЕДИНЕНИЕ Документ.ЗаказКлиента.ДополнительныеРеквизиты КАК ДополнительныеРеквизитыЗаказКлиента
        ПО ДокументЗаказКлиента.Ссылка = ДополнительныеРеквизитыЗаказКлиента.Ссылка
        ЛЕВОЕ СОЕДИНЕНИЕ (ВЫБРАТЬ
            ЗаказКлиентаТовары.Ссылка КАК Ссылка,
            ВЫБОР
                КОГДА МАКСИМУМ(ЗаказКлиентаТовары.Номенклатура.ТипНоменклатуры = ЗНАЧЕНИЕ(Перечисление.ТипыНоменклатуры.Услуга))
                    ТОГДА СУММА(ЗаказКлиентаТовары.Количество) - 1
                ИНАЧЕ СУММА(ЗаказКлиентаТовары.Количество)
            КОНЕЦ КАК КоличествоТовар,
            ВЫБОР
                КОГДА МАКСИМУМ(ЗаказКлиентаТовары.Номенклатура.ТипНоменклатуры = ЗНАЧЕНИЕ(Перечисление.ТипыНоменклатуры.Услуга))
                    ТОГДА МАКСИМУМ(ЗаказКлиентаТовары.НомерСтроки) - 1
                ИНАЧЕ МАКСИМУМ(ЗаказКлиентаТовары.НомерСтроки)
            КОНЕЦ КАК КоличествоСтрок
        ИЗ
            Документ.ЗаказКлиента.Товары КАК ЗаказКлиентаТовары
        
        СГРУППИРОВАТЬ ПО
            ЗаказКлиентаТовары.Ссылка) КАК ТоварыЗаказКлиента
        ПО ДокументЗаказКлиента.Ссылка = ТоварыЗаказКлиента.Ссылка

В расчете, что в заказе может присутствовать лишь одна услуга - доставка.