Прошу совет.

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

Или есть способы умнее? Какие?

Может я дурость выдумываю и можно еще какимто образом задать связь?

(0) А номер+дата разве не уникальны?

А= Прав(Строка(Новый УникальныйИдентификатор),9);

(0) Не идиотствуй
У меня вот в Почте России была необходимость сократить ГУИД, потому что его нужно было печатать на конверте и он должен уместиться в окно на конверте определенной ширины
А тут высосанная из пальца пурга
Используй ГУИД и делай новый реквизит, возможно доп, а не конфигураторский

(2) Рукалицо

(2) Дубли будут.

(0) Фактическая длина номера документа какая?

(0) Этот реквизит есть в обеих базах или только в одной?

Если только в одной то придумывай Хеш-функцию

(6) Номер документа могут поменять вручную, как и дату... Реквизит в 9-ть символов есть только в одной базе, в которой будут создаваться документы, и туда будут присваиваться "уникальное значение". То-есть эти уникальные значения в первой базе будут создаваться на лету каждый раз, и каждый раз они должны быть ФИКСИРОВАННО-уникальными

(3) Я это уже обдумал. Очень затруднительно сделать новый реквизит по некоторым причинам. Пока ищу вариант с имеющимся реквизитом.

Но это как крайний вариант - новый реквизит.

Я так понимаю, GUID - он всегда фиксированный и уникальный, пока есть документ в базе (в любом состоянии реквизитов, помечен на удаление или проведен?)

(8) 8 символов номера + 1 символ для года. Вот тебе и уникальность. Если номер документа длиннее 8 - задай префикс.

(10) Да, спасибо. Так уже работает. Я именно подобным образом и сделал. НО - беспокоит, что могут вручную изменить номер документа. И это вызвало у меня этот вопрос.
А так как документ связан с платежом денег - то меня это вдвойне озадачило

А вопрос - минимизировать ошибку..

То-есть самый верный вариант - использовать GUID и новый реквизит.

Ведь нельзя присвоить GUID документа одной базы - Новому документу другой базы в момент его создания?

(11) А зачем тебе этот реквизит вообще? Номер в документе хранится, дата тоже.

(9) на гуид соль, имя базы например, sha16 и прав 9. Кусок хеша тоже хеш

(1) ты не поверишь...

(13) Проверять, что в базе №2 уже существуе документ, который соответствует документу в Базе №1. Если в базе №2 такого документа нет - создать его, но создать только один!!! раз.

(14) Да... сейчас почитаю что и как

(11) Нет слов
Беги оттуда, пока у них не стрельнула твоя говноподелка
Или делай ГУИД, хоть на допсвойствах, но только не строй здание из говна и палок
Стрельнет же, голову оторвут и собакам выкинут и будут сто раз правы, таких говноподелочников так и надо учить, гнать отовсюду ссаными тряпками

а что мешает хранить там уникальный порядковый номер объекта в системе? присавивая последовательно при записи.
и что мешает сделать соотвествие (регистр сведений) номер - ГУИД дока?
а напрямую, подъемом основания системы счисления, до 9 байт штатный ГУИД не уменьшить. Если только до юникодной 8-символьной строки (16 байт)

(12) Можно, но не нужно
Хотя по сравнению с твоей свистоперделкой — даже этот вариант просто эталон качества, надежности и инженерной мысли

(1) До первого Обменданными.Загрузка = Истина

Есть решение, но оно не самое красивое:
Создаете пустой справочник.
Длина номера = 9
И пользуетесь нумератором справочника....

(22) Ну и делаете подписку на событие в любой транзакционной процедуре, где создаете новый элемент справочника, и его код используете как уникальный нумератор.
(14) не совсем

Если это восьмёрка, то лучше РС, а не справочник

(24) В РС надо будет получать текущее значение, ставить упр блокировки и делать запись.
Далеко не факт что будет быстрее.
А тут менеджер клатера Вам дает уникальный код. Платформенная проверка на дубли.

(25) заодно в справочник писать ссылку на док. "чтоб два раза не вставать"

Я все понял. Буду делать реквизит, с длинной 32 символа, и туда писать GUID из первой базы. Это самый верный и 100% вариант.

(26) Что бы 2 раза не вставить - только при создании нового и в транзакции. Все ок будет.

(27) На уровне документации гарантируется только то что в одной таблице ссылочных данных не может быть 2 записи с одинм ГУИД.
То что ГУИД TimeBased и то что процедура Вам 2 раза не выплюнет одно значение - не гарантируется

Если кроме как для обмена это нахрен не надо то я бы выкинул пары УИД-УИД во внешнюю базу или просто в отдельный регистр/справочник в одну из баз.

А еще лучше при обмене создавать документы с тем же УИД для парных доков ))

(30) Поздравляю, Вы изобрели MDM

(28) "не вставАть".
чтоб по "микрогуиду" сразу найти документ.

(32) То что будет дальше меня мало интересует - архитектурное решение которое будет удовлетворять задаче я предложил, дальше мне она не интересна

(33)ага.. "я стратегией занимаюсь"©

(29) Так мне нужно GUID уже готового документа. Он может поменяться с течениев времени в пределах одной базы?

(35) Если ну очень захотеть - то может

При нормальном развитии событий - нет

(35) нет

(36) (37) Значит это то, что мне нужно. Если при нормальной работе - это константа - то это то,что мне надо!


(38) Спасибо!

(38) Я залезу в SQL и поменяю.
По этому и говорю, что теоретически - возможно, но это уже не нормальный сценарий

(39) но, помни, что запросом уид не достать

(22) при высокой нагрузке платформа легко создаст два элемента справочника с одинаковыми кодами или два документа с одинаковыми номерами. Проверено на MS SQL + платформа 8.3.10.2252. Из за этого создание нужного уникального идентификатора вынесли на уровень СУБД.

(41) ... О... так я его по ссылке определяю как: XMLСтрока(Док.Ссылка)

(40) это будет уже другой документ

(39) ты же не изобрел РС СоответствияОбъектовИнформационныхБаз?

(42) Это как правило когда rmmanager у плохо.
Такие случаи надо исследовать.
Из того что видел я - какой нибудь г...но отчет без отборов запускаешь, но там не только нумератор летит.

(45) Нет

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

(48) По крайней мере это мониторится простейшим запросом.
Выбрать
Сумма(Ссылка),
Код
Из Справочник.ИмяСправочника
СгрпуппироватьПо
Код
Имеющие Сумма(Ссылка)>1

Но при нормальной работе сервера 1с такого быть не должно. Если эта ситуация есть - то есть проблемы которые надо искать и устранять.

Выбрать
Количество(Ссылка),
Код
Из Справочник.ИмяСправочника
СгрпуппироватьПо
Код
Имеющие Сумма(Ссылка)>1
Конечно же количество)))

Выбрать
Количество(Ссылка),
Код
Из Справочник.ИмяСправочника
СгрпуппироватьПо
Код
Имеющие Количество(Ссылка)>1

Тьфу)

(49) зачем запускать в работу инструмент, требующий постоянного контроля, если можно использовать штатные механизмы СУБД для генерации уникальных значений?

(53) Вопрос больше риторический.
Это всего лишь один из вариантов.
А зачем использовать лагучее 1с если есть что то.

я делал эту задачу как и на справочниках так и на регистрах.
250+ активных юзеров, единственное что за сервером следили. Проблем не было.
Но действительно коллизии возможны, если хочется железобетона - или РС с упр блокировками или SQL

(45) О, прозвучала дельная мысль, если нельзя делать новый реквизит :))