Доброго времени суток, уважаемые дамы и господа

Возник вопрос: возможно ли как - то централизованно добавить ГУИД в табличные части документов, что - то вроде общего реквизита в табличную часть? Было бы очень удобно добавить во все ТЧ ГУИД, а в подписке на событие сделать его заполнение там, где он не заполнен.

Можно, конечно, вручную допилить ГУИД в строки, но очень хочется создать красивое универсальное решение.

Суть задачи в том, чтобы при удалении строки (или создании новой) отслеживать, что было в новой строке, или что стало в добавленной.

ну так выгрузить конфу в файлы ...

>Суть задачи в том, чтобы при удалении строки (или создании новой) отслеживать, что было в новой строке, или что стало в добавленной.

Версионирование? Запись изменений в регистр?
Чот не очень понятен финт ушами с гуидом.

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

(1) не понял? Чем мне поможет выгруженная конфа для того, чтобы идентифицировать строку документа...

(3) Вопрос - зачем ГУИД?
Запись в регистре, однозначно идентифицирующая строку, не подходит?

(4) тебе? - ничем

Т.е. измерения "НаименованиеБД", "Объект", "НомерСтроки", ресурс "Значение". Всё.

(7) ты в курсе, что номер строки меняется при удалении строки выше, при сортировке ?

(5) Я думал на счёт регистра, но тут вопрос в том, как сопоставить запись регистра и саму строку? Я же не могу в регистре добавить реквизит с типом "Строка табличной части".

(8) Именно поэтому я и поднял вопрос здесь по поводу централизованного добавления ГУИДа в строки документов...

https://dl.dropboxusercontent.com/s/7vkmwaf9uzcrjb3/2019-08-09_07h31_38.png?dl=0

(11) Ну клёво. А дальше что с этой кучей файлов делать?

Может быть как - то из SQLя надёргать идентификаторов? как - то же он сопоставляет строки с шапкой, на то она и реляционная база данных...

(12) тогда смотри (6)

(14) Советчик из тебя, канеш...

(13) Как вариант, в принципе.

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

(12)Ну мне вернули мою колоду карт таро попробую вангануть и предположить, что ромаАШ(или ромаХ) хочет предложить, но стесняется, распарсить выгруженнуе файлы, добавить программно реквизит строка и загрузить обратно. Зачем? Мб он думает, тчо в этом проблема, мало понятно конечно из этих отрывистых сообщений. Не надо судить строго человека. Вдруг у него на клавиатуре буквы платные.

(16) "Возник вопрос: возможно ли как - то централизованно добавить ГУИД в табличные части документов, что - то вроде общего реквизита в табличную часть? Было бы очень удобно добавить во все ТЧ ГУИД,"

.... прикинь, именно это я предлагаю
вот не понятно откуда возник вопрос "Зачем" - потому-что (0) именно это и хочет

(0) Добавь текущую дату в каждую строку и вынеси в регистр сведений с измерениями НомерСтроки, Время, Регистратор , в ресурсы все поля этой строки
..
Но я так и не понял нахрена эта задача в таком виде.

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

(15) Ага, именно так. Один нехороший человек правит строку в документе, или удаляет/добавляет, а потом волчицы из бухгалтерии начинают мне моск компосировать, мол, хто и пошто? "Это жеж сбой в программе был, когда устраните??????!!!!!!111"

А я ХЗ, какой гад это был, и в какой именно базе он это сделал.

(20) Не, ты не понял.
Кто и пошто - ты увидишь, т.е. было в строке документа одно, стало другое, поменял такой-то.
При изменении порядка строк - ну сместится значение, это тоже видно будет.
Зачем однозначно идентифицировать каждую строку ТЧ?

(18) Добавить в строки ГУИД или дату или еще всё что угодно - это я смогу. Вопрос в том, чтобы однозначно идентифицировать строку ТЧ. Суть в том, чтобы сделать это добавление не сильно напряжным. Чтобы не добавлять этот реквизит в 100500 табличных частей, а как - то попроще...

+(21) Просто смысл такой детализации неясен. Без неё задача реализуется просто, быстро и без лишнего геморроя, есть даже готовые решения неплохие.

(21) Потому что баз - хренова гора. Между ними хренова гора обменов. Кто - то где - то поменял некий документ, не понятно в какую сторону. Когда этому "кому - то" начинают задавать вопросы, он говорит, что строки не трогал, а "только делал всё как обычно, а это всё сбой в программе".

(21) Суть: в подписке на событие последовательно прохожу все метаданные объекта и ссылки. И если значение из объекта и из ссылки не совпадают, то пишу в регистр, что такой - то (гад) изменил то-то. И всё бы ничего, но когда строка удаляется, то сопоставить, какие строки были, и какие стали, невозможно.

(24) Ты опять не понял. Базу идентифицировать несложно, объект - тоже, пользователя - вообще без проблем, всё это видно в записи регистра, куда ты будешь сохранять журнал изменений.
Я говорю про уровень детализации с уникальными гуидами строк - он очевидно избыточен для твоей постановки задачи. Ты без этой детализации сможешь видеть детальные изменения в табличной части. Порядок строк вообще не принципиален для получения полной информации по изменениям.

(20) Достаточно запретить пользователю редактировать проведенный и проверенный бухгалтером документ. И не надо городить огород. В одной из контор включил режим запрета редактирования документов не автором. Этого оказалось достаточным. Кто последний записал тот и виноват. А если по сабжу, то данная приблуда только усилит процесс разборок.

(25) можно же запросом сравнить две ТЧ, ссылки и объекта, разницу записать в твой РС...

(28) Верно. Но по каким критериям сопоставить табличные части? Например было в таблице 3 записи: 1, 2 и 3. Потом какой - то хороший человек взял и удалил строку №2. Соответственно, в объекте бывшая строка 3 получила номер 2.

(29) Это разве принципиально?
Вот была у нас ТЧ такая, стала такая, разница наглядна, неважно, правили строки или удаляли какие-то.

Как пример, посмотрите "История изменений" в типовой. Там со строками не заморачиваются, просто выводят все различия, на моей памяти вопросов, кто какую строку удалял или местами их менял, не было.

(29)Такие ситуации видно глазами. Или у вас это происходит по 100 раз в день?

(29) Другой "нехороший" человек отсортировал строки. Нет смысла цепляться за строки. Цепляйся за весь блок. Кто,что и как менял-избыточная информация. Достаточно зафиксировать, что в целом было после последнего сохранения документа.

Сейчас же вроде в новых платформах уже есть история.

(34) Автор хернёй страдает.
Есть платформенный механизм "история данных".
Есть механизм БСП "версионирование объектов", встроенный во все типовые последних версий.
И там и там нглядно видны все изменения - кем и когда сделанные.
Автор не в состоянии сформулировать - чего ему нужно и чем конкретно не устраивают существующие готовые инструменты.

(0) В 8.3 всё это есть и без костылей - гуидов.

У фирмы 1с есть свой велосипедный завод

(35) Возможно просто автор этого не знал. Я в прошлом также делал как и автор, только он для всех ТЧ хочет, а я делал для конкретных.

(35) Если базы разношёрстные, и некоторые из их никак не обновить до последнего релиза (переписанные до неузнаваемости), то как мне заюзать этот чудесный механизм? Я - то не против использовать уже изобретенный велосипед, но вот как? Отдельно БСП возможно ли как - то обновить, чтобы не трогать всё остальное?

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

+(40) Вот готовое решение, например: https://help1c.by/hranenie-zhurnala-registratsii-vo-vneshney-baze/

(41) Такое решение я уже сделал,  но оно без детализации: просто хранение журнала вне 1с.

(42) Упс, не то. Готовое решение называется вроде бы "Журнал изменений", у одного моего клиента такой стоял, собирал из зоопарка баз изменения с детализацией до реквизита.

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

вот и все.

(44) Видимо, так и придется сделать.

Просто хотел избежать ситуации, когда в документе 100500 строк, первую удалили, вторая стала первой. В регистр запишется, что поменян каждый реквизит каждой строки %)

"хотел избежать ситуации, когда в документе 100500 строк, первую удалили, вторая стала первой" // А если поменяли какое-нибудь поле ключа строки?

Или ты хочешь чтоб ключ ("УИД") вобрал в себя все реквизиты ТЧ, кроме номера строки?

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

На уровне БД 1С нет отдельных строк в ТЧ объектов, есть только целый объект с которым и манипулируем.
А то что этот объект имеет разные реквизиты и кроме то разные ТЧ в которых так же есть реквизиты это уже мелочи.

Короче приводи задачу к виду "отследить изменение объекта и любого его реквизита в т.ч. в любой строке ТЧ".

Имхо нужная хеш-функция (которая правильно обрабатывает перестановку строк в ТЧ как надо), перед записью каждый раз считаем хеш, если не сошелся то пишем куда то различия до записи и после записи.
И пофиг на какие то гуид и общие реквизиты, строки по данным в ним сопоставляем при надобности старые и новые.

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

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

(0) http://blog.1c-ei.ru/2010/02/1_26.html
?

(53) Мне это ничем не поможет, так как при записи документа он полностью перезаписывает ТЧ. Соответственно, если строка, которая имеет, например, ИД=1, была удалена, то при записи документа после удаления строки ИД=1 присвоится какой - то другой строке, скорее всего той, которая до удаления первой строки имела ИД=2.

(54) >после удаления строки ИД=1 присвоится какой - то другой строке
вы про _LineNo а я про _KeyField

>при записи документа он полностью перезаписывает ТЧ
вы проверяли?

(48) Т.е. если пользователь скопировал строку и ничего в ней не изменил, а старую удалил из ТЧ, и пусть даже на тот же номер строки новая встала, что и у удаленной, то это будет считаться изменением ТЧ?
При загрузке данных, например, ТЧ перезаписывается целиком, даже если в ней ничего не поменялось. Такое себе версионирование у тебя выйдет...

(57) Книга знаний: История изменений реквизитов документа, реквизитов табличных частей документа а если так?

(58) Нечто похожее я начал делать. Но тут опять возвращаемся к тому, что необходим некий набор ключевых полей, то есть привязка к конкретной ТЧ. Например, у документа РеализацияТоваровУслуг есть колонка "Номенклатура", а у "СчетФактураВыданный" такой колонки нет. Причем если базы разные (БП, УТ, ЗУП), то и табличные части будут тоже разные. Соответственно, для каждой из них нужно будет задать набор ключевых столбцов. Гораздо проще тогда ГУИД в ТЧ добавить, и работать по единому механизму. А в некоторых документах ключевых столбцов в общем случае может и не быть: в платформе нигде нет проверки, чтобы в документе не было двух одинаковых строк.

(27) >>>Достаточно запретить пользователю редактировать проведенный и проверенный бухгалтером документ. Этого оказалось достаточным. Кто последний записал тот и виноват.

Я тупо забацал в расширение: кто последний записал объект, тот и редиска. Тому, кто раздаёт штрафы, похрен, что "соседка Оля знает мой пароль или менеджеры подменяют друг друга".

(55) Кейфилд меняется вместе с номером строки ))

Исходный документ:
https://ibb.co/0VzLS5m

Он же в SQL:
https://ibb.co/Z6yYV7J

Удалил строчку, где количество было 9 шт, сохранил:
https://ibb.co/Tb1f3sP

В скуле все номера строк и ИД поменялись (удаленная строка была под №3, теперь там другая):
https://ibb.co/XxB44j6

а если строку удалят, а потом снова добавят?
как быть?

В некоторых типовых конфигурациях в табличных частях есть служебный реквизит КлючСтроки.
ИМХО, сохранять историю изменения табличной части практически тупиковый путь.

Я может где-то не увидел, но в последних платформах версионирование объектов из коробки есть. Насколько помню, РС тоже логируются

(60) Это назначение виноватых ))

(65) Это повышение личной отвественности.

(66) Странный у тебя ник для 1Сника))

(0) ОФФ Вы же программист, а не заказчик, вы зарезать должны такие бредовые идеи, а не реализовывать их

(59) В первом приближении можно попробовать автоматически определять - считать измерениями все нечисловые поля, а все числовые - считать ресурсами.

Проблема с дублирующимися строками решается через дополнительное поле "количество строк". Т. е. рассчитываешь колонку "количество строк" и сворачиваешь таблицу по измерениям перед расчетом изменений. Дубли строк будут тогда видны одной строкой с "количество строк" > 1.

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

А дальше для сравнения таблиц использовать что-то из http://catalog.mista.ru/public/326983/

(68) Да идея-то не бредовая; просто не нужно слова заказчика воспринимать как техническое решение - заказчику нужно просто УВИДЕТЬ различия в таблицах, а для этого достаточно типовых решений с доработанной формой вывода различий. Ему по барабану, как оно будет храниться - это как раз задача программиста.