УПП.В одном виде документа(без нумератора)
причем сбиласть назад например, для нового устанавливает пр00025
хотя есть уже более поздний пр00028
Переиндексация не помогла.Перезапись доков с большей нумерацией тоже.
Вопрос, в какой таблице SQL 1С хранит последние номера для доков ?
может там поправить ручками.

какая версия предприятия на 8.1 ли??

да 8.1 посл. релиз, но проблема тока в одном виде документа
пока нарисовалась

Вопрос, в какой таблице SQL 1С хранит последние номера для доков ?
может там поправить ручками.
Или она рассчитывает их

ап

в 81 есть команда которая "высвобождает" номера

(4) Она их рассчитывает п

(5) спасибо,щас поищу, а поточнее назв. команды если помните?
(6)какие то счетчики должны быть раз номера "залипают"

Такой гиморой возникает когда документ формируется в транзакции или ужет может и без нее. Это определнно глюк 1С 8.1 при включенном режиме нумерации объектов Освобождать автоматически. Воообщем в любом случае легко из этой ситуации не выпутаться - придется извращаться. Рарус из-за этой проблемы перевел свою конфу обратно на 1С 8.0. Нам эту проблему удалось решить но это стоило в некоторых случаях пропусках (нерегулярных) номеров для документов для кторых это не критично.

(8) спасибо за инфу.Как  же бороться, пока не понятно.Почитал:

РежимАвтонумерацииОбъектов (ObjectAutonumerationMode)
ОсвобождатьАвтоматически (AutoFree)
Описание:
Номер вне транзакции освобождается автоматически. При откате транзакции номера освобождаются автоматически вне зависимости от режима автонумерации объектов.
-тоже ничего не понятно

И что будет если в конфигураторе поставить Режим автонумерации объектов "Не Освобождать автоматически" - или так не надо ставить.
ВЕдь по умолчанию после перевода на 8.1 становится "Освобождать автоматически"

это не поможет

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

(12) понятно что это свойство лучше не менять.
получается тогда, что где то в базе 1С хранит номера (освобожденные или нет) или помечает их признаком
найти бы их и поправить ручками или может быть как то программно обработкой
Я даже таблицу дока быстро в SQL найти не могу там тока номера, а доков в УПП оч. много

пока проблема в одном доке, но если так и по остальным -то это уже будет большая проблема.Интересно это такая фича от 1С или баг который в очередном (вроде выпуск намечается) релизе должны поправить

Кароче, говорю че делать. Берешь ведро вазэлина, смазываещь все свои впуклости и вращательно - поступательными движениями начинаешь вставлять в себя канцелярские принадлежности.

(15) Как по Вашему опыту это поможет?
Попробую др. методами

Сэммитировал проблему:
1)При записи нового дока например с номером "06" откатил транзакцию- прервал запись.
2)потом записал новый док с номером "07" хотя авто номер присваивал "06"
3)потом записал новый док с номером "06"
4)потом ввожу новый док автонумерация присваевает номер "06"
типа он свободен, но при записи ругается что верно т.к. см. п.3

т.е. получается, что ОСВОБОЖДАТЬ установленные для новых доков номера МОЖНО - откатывая (не записывая доки) транзакции
А вот как бы научиться сообщить 1С, что типа такой то номер уже не свободен, а занят

Как научиться - Как научиться. Тебе в (15) уже дали подробный ответ.

мда..сколько раз ховорили что последовательность не означает непрерывность
остальное - дело техники

Друзья, наш коллектив разработчиков уже съел небольшую лохматую собаку на новых медотах автонумерации в 8.1.6.38. Особенно плачевны последствия автонумерации при применении вложенных транзакций (созданий объектов БД). Совутую всем у кого такие имеются не переходить на 8.1 по крайней мере до выхода нового релиза.

Можно попробовать:
ОбновитьНумерациюОбъектов(<Метаданные>)

(22) Подскажи пожалуйста, что именно выполняет этот метод?

"Выполняет обновление номеров в соответствии с номерами, записанными в базе данных. После вызова данного метода все выданные, но не записанные номера, становятся невалидными, т.к. не гарантируется их уникальность. Данный метод разрешено вызывать только администратору системы. "

(24) Ну это я читал, однако мне до сих пор непонятно.
Хочется примеров. Опытным путем что то плохо исследуется этот метод.

(25) Поэкспериментировал в "Примеры ИТС":
В конфигурации указал "He ocвoбoждaть aвтoмaтичecки".
Создаю документ Приход - номер 1, отказываюсь от создания. Создаю снова документ номер 2, еще и еще и еще. Каждый раз увеличивается номер. Потом выполняю ОбновитьНумерациюОбъектов и нумерация сбрасывается снова на 1.

Интерснее "ocвoбoждaть aвтoмaтичecки".
Например такие ситуации:
1) 1, 2, 4; новый номер 7
2) 1, 2, 4; новый номер 4
3) 1, 2, 4; новый номер 2
Признаюсь, у меня не было времени их проверять, т.к. сегодняшний день из-за этой проблемы весь прошел в сильной суматохе.

(27) Возможна ситуация когда одновременно создаются документы в нескольких транзакциях и соотвественно номера просто не успевают освобождаться.

(28) Самое интересное, что даже когда уже сделали свой нумератор (ПередЗаписью) все равно возникала ошибка "Код неуникален" при записи во вложенной транзакции.
Например (даже с одним подключением к базе работает и даже в файловом варианте).
Был последним номером у документа типа А ПП-62.
Создаем и записываем новый документ типа А - видим ПП-63. Все ок.
Теперь проводим документ типа Б ТР-032, который в проведении создает документ типа А. Большая вероятность того, что будет выдано сообщение об ошибке "Код неуникален при попытке записи документа типа А с номером ПП-64".

Мы были очень удивлены, что платформа не может записать документ с номером который не занят!!! Пока я не прочитал ни одного внятного объяснения этого явления.
В итоге шаг нашего нумератор был изменен с 1 на 2 =)
И пока все работает и описанной ошибки больше невозникает.
А нумерация документов типа А идет через 1.

апну еще.Проблема есть надо решать, как пока не понятно.Интересная любая инфа по этой проблеме.
Свои обработчики писать не выход.В УПП сотня документов, проблема может быть с любым

(30) 8.1 обладает механизмом подписки на события

(31)Знаю.
 Почитал в мартовском ИТС обзор нового механизма автонумерации.
Но, похоже что в посл. релизе 8.1.6.38 не все работает гладко как там написано
а именно не удаляются освобожденные номера после принудит.установке максимального номера, надеюсь что в новом релизе сделают как написано.
На данный момент ни один из реализованных механизмов автонумерации не устраивает

Эх, найти бы табличку, где эти освобожденные номера хранятся
можно было бы ручками править.Будет время поищу.

Поднимал эту тему еще в начале марта вот официальный ответ.

В файле v8Update в разделе изменений поведения указано:
В связи с изменением механизма автонумерации объектов получение очередного номера будет всегда выдавать последовательный номер, даже если предыдущий объект не записан.
Изменения были внесены не <случайно>, а с достаточно серьезной проработкой.

В версии 8.0 могла быть следующая ситуация.
Пользователь А открыл форму нового документа и получил номер 0001.
Пользователь Б открыл форму нового документа и получил номер 0002.
Пользователь А закрыл форму без записи.
Пользователь Б записал документ и закрыл форму.
При следующем открытии формы нового документа будет выдан номер 0003.
На месте номера 0001 имеется пропуск.
При одновременной работе нескольких пользователей это было вполне частое явление.
То есть никакой непрерывности в последовательности нумерации не было.
Но у пользователей работающих персонально возникало ощущение, что имеется непрерывность.

Что препятствовало параллельности.
Механизм получения нового номера считывал максимальный номер из базы данных.
Если номер формировался в транзакции (например, при записи или проведении документа создавался и записывался другой документ или элемент справочника), то, фактически, параллельность исключалась. Так как запись объекта была несовместима с получением максимального номера из базы данных (что вполне естественно).
Это не сильно мешало при нумерации в момент открытия формы, но радикально снижало параллельность (исключало) при включении в конфигурации любых алгоритмов создания и записи объектов в транзакции. Значительная часть внедренцев и разработчиков решений не обнаруживало причины этой проблемы и относило полностью нарушенную параллельность на счет общей проблемы реализации многопользовательской работы в платформе. Такое часто происходило и при <очень небольших доработках> выполненных сотрудниками заказчика, что сводило на нет всю работу внедренцев сдавших вполне работоспособную систему. Фактически минимальная доработка конфигурации приводила систему к полностью последовательной работе, так как два документа не могли быть записаны одновременно.
Это реально приводило к серьезным проблемам при внедрениях, и мы (если внедренец не мог сам обнаружить причину проблемы) без детального разбора работы конкретной конфигурации не могли дать рекомендацию как это исправить.
То есть получалось, что непрерывной нумерации на самом деле нет, но и параллельность также не обеспечивается.
Для непрерывной нумерации как в 8.0, так и в 8.1 нужно делать считывание и запись с блокировкой.

Другой проблемой являлось то, что механизм нумерации основывался на наличии в памяти объекта. Если реализовывать <тонкое> клиентское место (Web или любое другое), не держащее на стороне клиента объекта, то механизм нумерации фактически переставал работать, так как полученный номер при удалении объекта из памяти освобождался и выдавался следующему пользователю в качестве нового. Соответственно, получалось, что два пользователя вводят объекты с одинаковыми номерами.

Механизм нумерации 8.1 исключает обе этих проблемы. При получении номера в транзакции не возникает проблемы с параллельностью, так как, один раз считав максимальный номер из базы данных, система помнит его и автоматически увеличивает при выдаче очередного номера.
Это исключает описанные (весьма серьезные) проблемы с параллельностью при доработках конфигураций, включающих создание и запись объектов в транзакциях.
Это исключает проблемы с созданием специализированных клиентов, так как номер не возвращается при удалении объекта из памяти.

Действительно, обратной стороной этого решения является то, что для конкретного пользователя эксперимент с закрытием формы без записи и созданием нового документа приводит к появлению пропуска. Раньше ему казалось, что система заполняет пропуски. Хотя, по сути, это было не так, но пользователь не всегда замечал это. Это пользователю можно наглядно продемонстрировать.

Дополнение...

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

Но мне и бухам кажется, что наиболее неудачного решения придумать сложно....

(35) Спасибо за инфу.Интересно.Цель вроде у 1С благая, но что то перемудрили или не доделали.Штатными средствами 1С нельзя (или я еще не знаю?) решить проблему (0) или..

Вроде как совет в (22) помог для решения проблемы (0), но пользоваться часто так опасаемся
учитывая v8: 8.1 фоновое задание и ОбновитьНумерациюОбъектов()
Кто еще как борется или может быть что еще нового оп этой теме?
P.S. На мартовском диске ИТС есть в методич. поддержке 8.1 новый раздел про автонумерацию.
Пробовали и для "Режим автонумерации объектов" устанавливать метод "Не освобождать автоматически" т.е. при записи новый номер присваивать, вроде работает, но надо все же конфу значит. дорабатывать
Кто как борется с глюками новой нумерации?