хочется такие нумера

ХХ011-000152 XML
ХХ011-000153 XLL
ХХ011-000154 XQL

где суффикс зависит от вида договора или контрагента


как я понимаю -- нужно будет руками устанавливать номер в обработчике объекта ПриУстановкеНовогоНомера
но где тогда хранить сам номер, чтобы запрос искать его максимум ?

В самом документе - не предлагать? )

(1) т.е. думаешь создать числовой индексируемый реквизит и искать его макс ?

а блокировки там всякие ?

может лучше отдельный РС ?

(2) А что, прямо из номера не?

(4) ????

(5) В запросе ПОДСТРОКА()

префикс тоже меняется -- причём в длине

(7)тогда в отдельном реквизите...

(8) или же в РС ?

а то вдруг в записано доке изменят вид "операции" и потом придётся изменить номер -- реквизит же не отработает

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

т.е. нумерация независимая для каждого вида операции?
а дыры в нумерации допустимы?

(11) а потом нужно всегда в обновлениях следить, откуда будет браться номер для
1. декларации по ндс
2. 1с-эдо

(12) для некоторых видов операций-- да

(13) в обновлениях надо следить, если 1с что-то меняет. А она это место меняет раз в 5 лет. В остальное время обновление будет проходить полностью в автоматическом режиме.

(15) сегодня номер на печать сф постоянно берётся из функции номера на печать, а номер для декларации по ндс из рс журнала учёта сф
т.е. нет единого стандарта
что завтра будет не известно

(14) если дыры в нумерации допустимы - веди в РС для каждого вида операций свой последний номер. Если не допустимы - придётся перенумеровывать при изменении вида операции... в принципе не так много кода но если данным много - может занять время

а хранить в самом документе

(17) не понял -- почему если пропуском нет, то достаточно в реквизите дока

(19) тебе вообще для чего поиск? что-бы выдать следующему или что-бы в запросе отобрать?

*выдать следующему очередной номер

(20) следующий и присвоить номер

(22) тогда в документе его вообще нет смысла хранить (я про чистое число), РС для хранения последнего выданного номера и все дела

смысл Рс делать? делаешь доп. реквизит, и по подписке формируешь туда свой номер

При дальнейшей загрузке выгрузке куда-либо, берешь этот код.

Есть механизЬм, который формирует номер, в типовых есть функция получающая "чистый номер" так понимаю что максимум надо получать для присвоения след. номера?

(26) так что быстрее обращение к рс или к шапке дока ?

(0) вариант "засунуть суффикс в префикс" и не вы..делываться не предлагать?

(28) там и суффикс, и префикс

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

(мимо проходя)
Фраза автора "где суффикс зависит от вида договора или контрагента" наводит на мысль, что в запросе на макс.номер,  нужен отбор по виду договора и/или контрагента.

(29) А если подумать? Например, про два(!) префикса?

(31) см в 13

(32) чем не нравятся нумера вида

ХХ011XML-000152
ХХ011XLL-000153
ХХ011XAL-000154

вместо (0) ?

(33) постоянно придётся следить за обновами от 1с в плане нумеров