Сделал через перебор значений реквизитов через метаданные, складываю в список значений сначала общие, потом шапку, потом построчно табличную часть. Полученный список значений преобразовываю во внутренню строку и получаю ее хэш МД5. Аналогично рассчитывается и хэш элементов справочников-реквизитов документа. Всё отлично, только всё считается долго, хотелось бы побыстрее.

Функция глПолучитьХэшДокумента(Док)

   Вид = Док.Вид();

   ТабРекв = СоздатьОбъект("ТаблицаЗначений");
   ТабРекв.НоваяКолонка("Реквизит");
   ТабРекв.НоваяКолонка("Значение");
   
   Сч = 0;
   Для Сч = 1 По Метаданные.ОбщийРеквизитДокумента() Цикл
       ТабРекв.НоваяСтрока();
       Реквизит = Метаданные.ОбщийРеквизитДокумента(Сч).Идентификатор;
       
       Если Реквизит = "Хэш" Тогда
           Продолжить;
       КонецЕсли;
       
       ТабРекв.Реквизит = Реквизит;
       ТабРекв.Значение = Док.ПолучитьАтрибут(Реквизит);
   КонецЦикла;

   Для Сч = 1 По Метаданные.Документ(Вид).РеквизитШапки() Цикл
       
       Реквизит = Метаданные.Документ(Вид).РеквизитШапки(Сч).Идентификатор;
       Значение = Док.ПолучитьАтрибут(Реквизит);
       
       ТабРекв.НоваяСтрока();
       ТабРекв.Реквизит = Реквизит;
       ТабРекв.Значение = Значение;
       
   КонецЦикла;

   Док.ВыбратьСтроки();
   Пока Док.ПолучитьСтроку() = 1 Цикл
       Для Сч = 1 По Метаданные.Документ(Вид).РеквизитТабличнойЧасти() Цикл
           Реквизит = Метаданные.Документ(Вид).РеквизитТабличнойЧасти(Сч).Идентификатор;
           Значение = Док.ПолучитьАтрибут(Реквизит);
           
           ТабРекв.НоваяСтрока();
           ТабРекв.Реквизит = Реквизит;
           ТабРекв.Значение = Значение;
           
       КонецЦикла;
   КонецЦикла;
   
   СписокРеквизитов = СоздатьОбъект("СписокЗначений");
   ТабРекв.ВыбратьСтроки();
   Пока ТабРекв.ПолучитьСтроку() = 1 Цикл

       Значение = ТабРекв.Значение;
       
       Если (ПустоеЗначение(Значение) = 1) ИЛИ (Значение = Док)  Тогда
           Продолжить;
       КонецЕсли;
       
       Тип = ТипЗначения(Значение);
       
       Если Тип = 11 Тогда
           Спр = СоздатьОбъект("Справочник." + Значение.Вид());
           Если Спр.НайтиЭлемент(Значение) = 1 Тогда
               Значение = глПолучитьХэшЭлементаСправочника(Спр.ТекущийЭлемент());
           Иначе
               Продолжить;
           КонецЕсли;
           
       ИначеЕсли Тип = 12 Тогда
           Если ПустоеЗначение(Значение.Хэш) = 1 Тогда
               Док = СоздатьОбъект("Документ");
               Если Док.НайтиДокумент(Значение) = 1 Тогда
                   ТекХэш = глПолучитьХэшДокумента(Док.ТекущийДокумент());
                   Док.Хэш = ТекХэш;
                   Док.Записать();
                   Значение = Док;
               Иначе
                   Продолжить;
               КонецЕсли;
           КонецЕсли;
           Значение = Значение.Хэш;
       КонецЕсли;
       
       
       СписокРеквизитов.ДобавитьЗначение(Значение);
       
   КонецЦикла;

   Сервис = СоздатьОбъект("Сервис");
   Хэш = Сервис.ПолучитьХэшМД5(ЗначениеВСтрокуВнутр(СписокРеквизитов));
   
   Возврат Хэш;
   
КонецФункции

посмотри Formex
там вроде есть процедура рассчета md5

а .. ну да - ты вроде через него и получаешь
пардон

Пока читал нашел косяк в функции - передаваемый параметр Док и создаваемый объект Док, в случае, когда реквизит тоже документ.

для чего такой изврат?

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

а что модифицированость уже не устраивает?

тем более что можно получить ид документа

Да, модифицированность в ряде случаев устраивает. А ИД документа - он же не изменится если я количество изменю на 1?

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

или это рисуешь лог измененией ... чего меняли в документах?

(0)  1. Почему бы не заменить конструкцию

Док.ВыбратьСтроки();
   Пока Док.ПолучитьСтроку() = 1 Цикл

на ВыгрузитьТабличнуюЧасть?


2. Теперь кусок...

ТабРекв.ВыбратьСтроки();
   Пока ТабРекв.ПолучитьСтроку() = 1 Цикл

       Значение = ТабРекв.Значение;
       
       Если (ПустоеЗначение(Значение) = 1) ИЛИ (Значение = Док)  Тогда
           Продолжить;
       КонецЕсли;
       
       Тип = ТипЗначения(Значение);
       
       Если Тип = 11 Тогда
           Спр = СоздатьОбъект("Справочник." + Значение.Вид());
           Если Спр.НайтиЭлемент(Значение) = 1 Тогда
               Значение = глПолучитьХэшЭлементаСправочника(Спр.ТекущийЭлемент());
           Иначе
               Продолжить;
           КонецЕсли;
           
       ИначеЕсли Тип = 12 Тогда
           Если ПустоеЗначение(Значение.Хэш) = 1 Тогда
               Док = СоздатьОбъект("Документ");
               Если Док.НайтиДокумент(Значение) = 1 Тогда
                   ТекХэш = глПолучитьХэшДокумента(Док.ТекущийДокумент());
                   Док.Хэш = ТекХэш;
                   Док.Записать();
                   Значение = Док;
               Иначе
                   Продолжить;
               КонецЕсли;
           КонецЕсли;
           Значение = Значение.Хэш;
       КонецЕсли;
       
       
       СписокРеквизитов.ДобавитьЗначение(Значение);
       
   КонецЦикла;

Это, конечно, надежно... Почему бы не сделать проще: полученную таблицу ТабРекв сохраняем в строку. Строку - хэшируем.

Всяко должно быть быстрее.

(11) А если в табличной части есть Номенклатура, в которой только изменили комментарий?

(12)ну так отслеживай это при изменение комментария в самой номенклатуре ... а то тебе придется отлавливаться все доки ... в которых есть номенклатура и там логировать

(13) Ну да, верно говоришь

Хотя нет. Хэш ВСЕХ документов должен будет измениться, где есть эта номенклатура. Другое дело, что ПЕРЕСЧИТАТЬСЯ он должен только когда этот документ будут трогать.

(15) Не усложняй... Изменилась номенклатура - это одно. Изменился документ - это другое...

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

(17) Раз пошла такая пьянка - хэшируй заодно и движения документа.

+18 По аналогии с (11): движения -> в ТЗ. ТЗ в строку. По строке - хэш...
P.S. Гы-гы-гы..  Игла в яйце, яйцо в утке, утка в зайце...  :)

(17)и что теперь будешь все документы перепроводить?

(19) Движения регистрировать смысла нет. Задача - получить гарантированно уникальный хэш документа, в зависимости от совокупности текущих значений реквизитов объекта.
(20) Только в случае, когда будет осуществлена попытка записи документа с изменившемся хэшем.

(21) Хэш нужен для каких целей?

(21)ну тогда вот тебе задача ... а что если в номенклатуре изменят реквизит объектного типа который так-же может повлиять на проведение документа ... то есть не выберут новый объект ... а именно изменят какой-то реквизит у этого объекта

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

(23) Думаю надо при расчете хэша документа просто брать хэш справочника, который будет расчитан при записи элемента.

а если тмц изменит не тот кто смотрит документ ... а кто-то другой ...

тогда аллах-акбар, тем более если давят "Записать"

(21)я имел ввиду ... зашел я в тмц ... изменил счет затрат ... записал ... при записи будешь все документы перепроводить?

Пустое это все, часто проще исправить ошибку чем искать виноватых. Которые к моменту поиска могут уже благополучно уволиться.

(28) Все то не буду. Нажало некто "ОК" - в ПриЗаписи посмотрели текущий хэш по Контексту, сравнили с имеющимся - идентично, значит записывать/перепроводить не надо, просто закрыли форму и вуаля.

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


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

(31) Да, соглашусь, но давят обычно сначала Провести, потом ОК, да если еще и ПриЗаписиПерепроводить(1), то имеем целых 3, а то и 4 проведения.

А так, надо проводить - провели, даже если сам документ не меняли, а только изменили ГлубинуКредита у Контрагента.

(32)после провести ... модифицированость в ноль ... если человек откроет тмц из табличной ... модифицированость в истину

(34) Да, это очень хороший вариант, но если ГлубинаКредита или КатегорияНоменклатуры была изменена, то перепроводить НАДО, даже если документ не менялся.

А так - открыли, 1С посмотрела - модифицированность на нуле, нахрена напрягаться...

(35)если я открыл тмц ... и изменил в ней что-то ... что не влияет на проведение ... но твой хэш по всем реквизитам изменился ... документ получается надо перепровести

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

Накладные расходы на расчет хэша по метаданным всё равно не превышают расходы на проведение документа. Но всё равно хотелось бы его считать побыстрее.

(38) А теперь раскладку по времени приведи. Сколько ты по-времени экономишь? Если, конечно, экономишь....

а теперь вопрос ... я уже намекал ... но думай

итак имеем тмц ... отнесеную на счетзатрат1 ... имеем около 5000 проведенных документов в разных периодах, в том числе и закрытых ...

что будет делать твоя программа когда я зайду в справочник и поставлю счетзатрат2

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

+40 Однако...  Отвечаешь быстрее, чем я спрашиваю..  :)

Хэш считается примерно 1,5 секунды и на клиенте (т.е. на вялом клиенте может достигать значения 2-2,5 сек.). А проведение одного документа с табличной частью 10 строк - 4 сек. (а есть документы и с гораздо большим количеством строк). Умножь его на 2 и добавь повышение возможности возникновения блокировок при (пере)провдении - вот тебе и гешефт.

>> проведение одного документа с табличной частью 10 строк - 4 сек.
Не пора ли в консерватории что-то поменять? Может лучше оптимизацией кода заняться, чем всякими хэшами

(44) Пора конечно )))

Так делай, а не ищи лишних приключений

(46) Хорошо.

(41) Программа будет в случае записи/проведения будет записывать/проводить этот документ, т.к. у него изменился хэш. Сейчас она итак записывает/проводит по требованию оператора. Количество записей/проведений может быть уменьшено, если реквизита документа не модифицировались.

проведение заявки из 216 строк - 10 секунд, (SQL, 30 пользователей), у кого меньше?

Занятная штука. Однако лучше обойти, чем вляпаться. Я бы шел по пути ограничения прав и включения режима просмотра документа с выключением кнопки.

во что вляпасться-то? сделай константо или хэшируй только большие документы с ТЧ > 100 поз

(0) Почитал ветку и так и непонял - нахрена? За что боремся? Или просто практикуемся от нечего делать?

(49) проведение заявки или корректирующей заявки из 700-900 строк - порядка 1-2 сек

не.. у меня тоже была идея такой эже хеш сделать.. потом подумал и отказался.. ну его на, проще это забороть административными методами и запретом изменений задним числом. Если изменения задним числом - норма - то надо что-то в консерватории менять, а если это эпизодические вынужденные действия - то проблем нет..
.
сделал в доке два реквизита:
Маркер1 и Маркер2
ПриЗаписи маркер1 пишется в маркер2, в маркер1 пишется изменено+дата+время+имяпользователя
при выгрузке дока в бухию маркеры сдвигаются аналогично, в маркер1 пишется выгружено+дата+время+имяпользователя.
.
маркер1 отображаю в титуле окна.
.
все, этого достаточно...