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

(0) Основной вопрос конечно - "Нафуя?"
Имхается мне, что тут решается задача Заказчика не попу, может все же нормально решить?

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

Автор дятел
Оставить нумерации заявок и реализаций как были
При вводе реализации на оснве заявки в номер реализации подставлять номер заявки
Все

автор дятел*2
При нумерации в прелелах года зпросто може т получиться когда номер реализации будет неуникальным
Например
Конец года заявка покупателя 1000
Новый год
Реализация в новом году с номером 1000 (согласно поставленным условиям)
В новом году заявки начинают ну менроваться заново
И где нибудь в районе конца года получается заявка с номером 1000 и реализация с номером 1000
Итого в одном году два документа с одинаковым номером
Все (__o__)

(2) нумерация для документов ЗП и РТиУ должна быть единая числовая. от 1,2,3,4 и т.д. К примеру звонит клиент оператор формирует ЗП с номером 50. Звонит следующий клиент формируется заявка с номером 51. Помимо звонков, покупатели приходят за покупками в центр продаж, где им сразу формируется документ РТиУ, с номером 52 и т.д. По ранее сформированным заявкам, покупатели могут оплачивать безналом и по оплаченным ЗП формируется накладная, НО ТОЛЬКО С НОМЕРОМ РАНЕЕ СОЗДАННОГО ЗП. (в нашем примере 50 и 51). В конце дня все документы РеализацииТиУ экспортируются во внешнюю БД.

(3,4) нумератор для ЗП и РеализацииТиУ числовой, не уникальный, не периодический. НО все равно в какой то момент происходит задвоение.

ну ??? что может быть ((((

Читай (3)

(6) убери нафиг все накорябанное ручками
Верни все к типовой онфиге
Дальше сделай по п3

(9) ты понял что я написал? Формироваться могут как ЗП -> РТиУ, так и РТиУ (сразу). Какой номер будет у реализации следующим ???? Если у ЗП был к примеру 50?

(10) запретить реализации без заявок
И не морочиться

Как только появится заявка по которой не будет реализации - дырка в порядке нумерации реализаций; бушка начнет страпонить ТС ...

(12) это нормально. что дырка в порядке нумерации РеализацийТиУ (главное чтобы была уникальность отгрузок), и главное чтобы не было задвоений.

(13) НДС платите ?

(14) понял, тебя. Здесь не важно последовательность, другие требования.

(14) При чем тут НДС?
Нумерация "без дырок" - это фетиш некоторых больных на голову бухов. Никаких законодательных или регламентирующих требований на сей счет не существует.

(16) Налоговая вопросы задает - что вы от нас прячете если видит пробел в нумерации; а так да, регламента нигде нет.

(11) >> запретить реализации без заявок

+100

Можно еще разрулить префиксами.
Установить в подразделении, где выписывают РТиУ без ЗП (в центре продаж) свой префикс документов - будет у них своя нумерация в потоке документов.

(11) как вариант да. но это координально. (18) а почему нумератор то не срабатывает?

(19) глюкануть могло, бывает такое. Попробуйте прогнать ОбновитьНумерациюОбъектов () для этих доков.

(20) ппц. это полная лажа

(0) А как ты сделал, что у тебя номер был Реализации был такой как и Заказа. Или это все нумератор сделал?

(22) при создании нового документа РТиУ на основании заказа копируется и номер из ЗП.

(23) Копируется программно ? Или назначсется системой на основании нумератора ?

(23) тогда смотрите (4). Если при переходе через год вы назначаете реализации номер от прошлогодней заявки, то тем самым рискуете создать дубликаты - это раз, и возможно, перенесете нумератор следующего года черт знает на какую позицию - это два. Мне кажется, что если года в заявке и реализации различаются, то номер реализации надо брать все-таки с года реализации (в порядке исключения), в противном случае ваша система не будет правильно работать.

(23) Ну вот в этот момент, как (24) намекает, вполне все может и полететь

(24) интерактивно. юзер на основании ЗП создает РТиУ и в этот момент присваивается значение номера из ЗП для номера РТиУ.

(25) нумератор не периодический

(24)программно

(26) ну а как? если номер уже условно занят к примеру ЗП, то какая разница какой номер перезаписывается в РТиУ ?

(30) следующий номер ЗП или РТиУ должны идти с новым номером!!!

(17) Налоговую послать в жпо. Требование последовательной сквозной нумерации есть только для ПКО и РКО.

(30) Не знаю как, но ходит поверье, если ты ну начинаешь что то указывать нумератору, то он начинает вести себе не предсказуемо. Я не утверждаю, что проблема именно в этом. Но я бы на это грешил.

Если проблема в этом глюке, мне кажется, тебе сделать подписку на событие УстановкаНовогоНомера и назначить ее и тому и тому документу и самому там уже назначать нужные номера.

(27) Собст-на. Нет у тебя нумератора ... из (0) "создал свой нумератор (числовой), неуникальный" - не имеет смысла; не создал ты его или оздал криво; не работает он у тебя ...

(32) Не сквозной. А последовательной. Разницу чуешь ?

Сквозной должна быть нумерация с/ф; если таковая есть ...
как, такой зубр как, ты мог забыть ?

Прошу прощения. Но подниму тему еще раз. Как все таки перебрать НОВЫЕ НЕ ЗАПИСАННЫЕ еще документы ? Спасибо.

(37) эээ... Ни как. Их же нет в базе.

Возможно речь о документах, которые открыты у пользователя.

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