Подписка "ПередЗаписьюДокумента()" #622893

Есть подписка на данное событие, в процедуре подписки прописан код: Мне необходимо неважно запишится документ или нет,  мне надо чтобы РС в любом случае перезаписался, а он редиска, когда документа получает Отказ на запись не сохраняет изменений.... что не так то сделано?

потому что в транзакции

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

что это за поля ?

есть варианты как схитрить?

DocID - ID в каком виде ?

по коду видно, что это ЧИСЛО!

А если перенести в подписку ПриУстановкеНовогоНомера?

дело в , там транза идет, а по скольку 1С туповата и не имеет разделенных транз, то попытка написать НачатьТранзу не приводит к успеху.

для какиз целей ?

мне, что выложить ТЗ сюда в полном объеме?!

не подходит, необходимо проаналиировать перед записью именно, может чего добавили в документ!

я к тому, что где ты потом будешь это использовать ?

А какой смысл сохранять инфу в регистре, если в документе ввели абра-кадабру и он даже не записывается? Если док новый - у него и ссылки еще нет

есть смысл!

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

В РС. поля счетчики: тут это обговаривалось...

просто в случае реализации не учол транзакцию, а счас тестирую и вижу проблему...

жесть

Запускай обработку, которая запишет.

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

к

жесть в том. что данные надо отдавать не в базу 1С. По ИД числовом шапки документа и строки ТЧ. Для этого мне необходимо хранить последнии счетчики, чтобы когда будет записыватся новая строка или новый документ взялся счетчик+1.

гуид храниться в каком формате ?

ты что убить меня этим вопросом решил?

боюсь ребят наткнемся тогда на неуникальность :(

вся жесть состоит в том, что для строк документов и их шапок надо присвоить числовые ИД, чтобы при обмене в другую БД это выгружать.

что со строками ТЧ собрался сделать?

строки будет определять так 1ая -- числоАйдиДока 2ая -- числоАйдиДока+1 3ая -- числоАйдиДока+2 ...

ну в этом что-то есть. я правда не увидил момента:

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

Ну и отдавай. Только через планы обмена

стоп. Ну у тебя же документ не записался, значит и твой регистр менять не надо. У тебя же в регистре номер последнего документа. Непонятно, чего ты паришься? То есть ответ был уже в .

дело в том, что я изменил в документе его реквизиты :(

+ Code        или Не ОбщегоНазначения.ЕстьТабЧастьДокумента("Товары",МетаданныеДокумента) Тогда

но это изменение не сохранилось. Значит получается, что не изменил реквизиты.

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

вот гуид в число, я не увидил самой интересной функции Ч = бфМат.ПереводИзСистемыСчисленияВЧисло(СтрGUID, 16); чего там внутри-то?!

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

в этом тоже есть идея, присваивать ИД только во время обмена.

дел в том, что пример по коду выше: проверяем заполнены ли реквизит Шапки и ТЧ, если что-то не заполнено идем ниже. Читаем данные счетчиков в РС. Доплюсовуем эти счетчики и проставляем в реквизит документа. Идет сбой при проведении так как пользователь например указал завышенное к-во. Пользователь исправляет к-во и делает "Записать". на верхнем уровне в проерке уже реквизиты в документе DocID и DocRecID заняты, а РС не знает об этом.

то есть при получении из РС DocID  = 100 в документ ставим DocID = 101 сбой в транзе, в РС не зашло изменения (101 и 1001), а вот в документ эти реквизиты установились. И при следующий записи, когда пользователь исправил замечания мы не присвоим никакого ID. Потом след. документ записуем и берем эти же (101 и 1001) - уникальность нарушена.

вижу рабочий вариант только . минус его это перезапись документов.

А ты в РС храни не последний, а гуид конкретного документа.

так у тебя другая ситуация совсем. У тебя транзакция документа прошла успешно, у тебя регистр не записался.

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

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

относительно Гуида в число и обратно нашол и протестил, мне не подходит, так как ИД  Ч вот примеры: КонецФункции e5c93656-da45-11e1-94ee-2c768aa92b8d 305 437 964 834 603 041 129 328 196 376 110 640 013 e5c93656-da45-11e1-94ee-2c768aa92b8d

то есть даже если я и переведу мой ГУИД документа в число а он: 305 437 964 834 603 041 129 328 196 376 110 640 013 не соответсвует разрядности :(

рост регистра он будет равен шапки+ тч строки

хоть бери плин под скулем выполни через адо жостко INSERT :(

При обмене с другой базой сделали составной ключ - гуид регистратора + номер строки. При приходе гуида регистратора сторонняя база полностью перезаписывает все записи с первой частью ключа = гуид.

Со стороны другой базы никто ничего делать не будит НИКОГДА!