Вход | Регистрация
 
1С:Предприятие :: 1С:Предприятие 8 общая

Общий реквизит табличных частей?

Общий реквизит табличных частей?
Я
   ppa32
 
09.08.19 - 03:30
Доброго времени суток, уважаемые дамы и господа

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

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

Суть задачи в том, чтобы при удалении строки (или создании новой) отслеживать, что было в новой строке, или что стало в добавленной.
 
 
   RomaH
 
1 - 09.08.19 - 07:05
ну так выгрузить конфу в файлы ...
   Троекратное ура
 
2 - 09.08.19 - 07:14
>Суть задачи в том, чтобы при удалении строки (или создании новой) отслеживать, что было в новой строке, или что стало в добавленной.

Версионирование? Запись изменений в регистр?
Чот не очень понятен финт ушами с гуидом.
   ppa32
 
3 - 09.08.19 - 07:19
(2) Да, запись изменений в регистр с последующей выгрузкой данных во внешнюю базу данных. У нас просто несколько филиалов, и я хочу централизовать механизм отслеживания изменений.
   ppa32
 
4 - 09.08.19 - 07:20
(1) не понял? Чем мне поможет выгруженная конфа для того, чтобы идентифицировать строку документа...
   Троекратное ура
 
5 - 09.08.19 - 07:26
(3) Вопрос - зачем ГУИД?
Запись в регистре, однозначно идентифицирующая строку, не подходит?
   RomaH
 
6 - 09.08.19 - 07:27
(4) тебе? - ничем
   Троекратное ура
 
7 - 09.08.19 - 07:27
Т.е. измерения "НаименованиеБД", "Объект", "НомерСтроки", ресурс "Значение". Всё.
   RomaH
 
8 - 09.08.19 - 07:29
(7) ты в курсе, что номер строки меняется при удалении строки выше, при сортировке ?
   ppa32
 
9 - 09.08.19 - 07:30
(5) Я думал на счёт регистра, но тут вопрос в том, как сопоставить запись регистра и саму строку? Я же не могу в регистре добавить реквизит с типом "Строка табличной части".
   ppa32
 
10 - 09.08.19 - 07:31
(8) Именно поэтому я и поднял вопрос здесь по поводу централизованного добавления ГУИДа в строки документов...
   RomaH
 
11 - 09.08.19 - 07:32
   ppa32
 
12 - 09.08.19 - 07:37
(11) Ну клёво. А дальше что с этой кучей файлов делать?
   ppa32
 
13 - 09.08.19 - 07:40
Может быть как - то из SQLя надёргать идентификаторов? как - то же он сопоставляет строки с шапкой, на то она и реляционная база данных...
   RomaH
 
14 - 09.08.19 - 07:40
(12) тогда смотри (6)
   Троекратное ура
 
15 - 09.08.19 - 07:44
(14) Советчик из тебя, канеш...

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

А что, задача настолько строго стоит прям до строки детализировать? Ну была ТЧ такая, стала после изменения другая, без привязки к строкам.
   Web00001
 
16 - 09.08.19 - 07:48
(12)Ну мне вернули мою колоду карт таро попробую вангануть и предположить, что ромаАШ(или ромаХ) хочет предложить, но стесняется, распарсить выгруженнуе файлы, добавить программно реквизит строка и загрузить обратно. Зачем? Мб он думает, тчо в этом проблема, мало понятно конечно из этих отрывистых сообщений. Не надо судить строго человека. Вдруг у него на клавиатуре буквы платные.
   RomaH
 
17 - 09.08.19 - 07:52
(16) "Возник вопрос: возможно ли как - то централизованно добавить ГУИД в табличные части документов, что - то вроде общего реквизита в табличную часть? Было бы очень удобно добавить во все ТЧ ГУИД,"

.... прикинь, именно это я предлагаю
вот не понятно откуда возник вопрос "Зачем" - потому-что (0) именно это и хочет
   МимохожийОднако
 
18 - 09.08.19 - 07:58
(0) Добавь текущую дату в каждую строку и вынеси в регистр сведений с измерениями НомерСтроки, Время, Регистратор , в ресурсы все поля этой строки
..
Но я так и не понял нахрена эта задача в таком виде.
   Web00001
 
19 - 09.08.19 - 08:01
(17)Там было, что-то еще про подписки на события, то есть тс больше беспокоит факт как заполнять этот реквизит что-бы было написано элегантно и работало всегда правильно. Как систематизировано с меньшими трудозатратами добавить, реквизит в тч, тоже наверное зададча и твой вариант даже неплох, если бы у тебя не были такие дорогие буквы и ты сразу бы сказал, что ты имеешь ввиду.
   ppa32
 
20 - 09.08.19 - 08:05
(15) Ага, именно так. Один нехороший человек правит строку в документе, или удаляет/добавляет, а потом волчицы из бухгалтерии начинают мне моск компосировать, мол, хто и пошто? "Это жеж сбой в программе был, когда устраните??????!!!!!!111"

А я ХЗ, какой гад это был, и в какой именно базе он это сделал.
   Троекратное ура
 
21 - 09.08.19 - 08:07
(20) Не, ты не понял.
Кто и пошто - ты увидишь, т.е. было в строке документа одно, стало другое, поменял такой-то.
При изменении порядка строк - ну сместится значение, это тоже видно будет.
Зачем однозначно идентифицировать каждую строку ТЧ?
   ppa32
 
22 - 09.08.19 - 08:08
(18) Добавить в строки ГУИД или дату или еще всё что угодно - это я смогу. Вопрос в том, чтобы однозначно идентифицировать строку ТЧ. Суть в том, чтобы сделать это добавление не сильно напряжным. Чтобы не добавлять этот реквизит в 100500 табличных частей, а как - то попроще...
   Троекратное ура
 
23 - 09.08.19 - 08:08
+(21) Просто смысл такой детализации неясен. Без неё задача реализуется просто, быстро и без лишнего геморроя, есть даже готовые решения неплохие.
   ppa32
 
24 - 09.08.19 - 08:12
(21) Потому что баз - хренова гора. Между ними хренова гора обменов. Кто - то где - то поменял некий документ, не понятно в какую сторону. Когда этому "кому - то" начинают задавать вопросы, он говорит, что строки не трогал, а "только делал всё как обычно, а это всё сбой в программе".
   ppa32
 
25 - 09.08.19 - 08:14
(21) Суть: в подписке на событие последовательно прохожу все метаданные объекта и ссылки. И если значение из объекта и из ссылки не совпадают, то пишу в регистр, что такой - то (гад) изменил то-то. И всё бы ничего, но когда строка удаляется, то сопоставить, какие строки были, и какие стали, невозможно.
   Троекратное ура
 
26 - 09.08.19 - 08:15
(24) Ты опять не понял. Базу идентифицировать несложно, объект - тоже, пользователя - вообще без проблем, всё это видно в записи регистра, куда ты будешь сохранять журнал изменений.
Я говорю про уровень детализации с уникальными гуидами строк - он очевидно избыточен для твоей постановки задачи. Ты без этой детализации сможешь видеть детальные изменения в табличной части. Порядок строк вообще не принципиален для получения полной информации по изменениям.
   МимохожийОднако
 
27 - 09.08.19 - 08:34
(20) Достаточно запретить пользователю редактировать проведенный и проверенный бухгалтером документ. И не надо городить огород. В одной из контор включил режим запрета редактирования документов не автором. Этого оказалось достаточным. Кто последний записал тот и виноват. А если по сабжу, то данная приблуда только усилит процесс разборок.
   FIXXXL
 
28 - 09.08.19 - 09:56
(25) можно же запросом сравнить две ТЧ, ссылки и объекта, разницу записать в твой РС...
   ppa32
 
29 - 12.08.19 - 02:41
(28) Верно. Но по каким критериям сопоставить табличные части? Например было в таблице 3 записи: 1, 2 и 3. Потом какой - то хороший человек взял и удалил строку №2. Соответственно, в объекте бывшая строка 3 получила номер 2.
   Троекратное ура
 
30 - 12.08.19 - 04:59
(29) Это разве принципиально?
Вот была у нас ТЧ такая, стала такая, разница наглядна, неважно, правили строки или удаляли какие-то.
 
 Рекламное место пустует
   Троекратное ура
 
31 - 12.08.19 - 05:00
Как пример, посмотрите "История изменений" в типовой. Там со строками не заморачиваются, просто выводят все различия, на моей памяти вопросов, кто какую строку удалял или местами их менял, не было.
   catena
 
32 - 12.08.19 - 07:02
(29)Такие ситуации видно глазами. Или у вас это происходит по 100 раз в день?
   МимохожийОднако
 
33 - 12.08.19 - 07:52
(29) Другой "нехороший" человек отсортировал строки. Нет смысла цепляться за строки. Цепляйся за весь блок. Кто,что и как менял-избыточная информация. Достаточно зафиксировать, что в целом было после последнего сохранения документа.
   APXi
 
34 - 12.08.19 - 08:28
Сейчас же вроде в новых платформах уже есть история.
   unregistered
 
35 - 12.08.19 - 08:59
(34) Автор хернёй страдает.
Есть платформенный механизм "история данных".
Есть механизм БСП "версионирование объектов", встроенный во все типовые последних версий.
И там и там нглядно видны все изменения - кем и когда сделанные.
Автор не в состоянии сформулировать - чего ему нужно и чем конкретно не устраивают существующие готовые инструменты.
   ptiz
 
36 - 12.08.19 - 09:42
(0) В 8.3 всё это есть и без костылей - гуидов.
   aleks_default
 
37 - 12.08.19 - 10:51
У фирмы 1с есть свой велосипедный завод
   APXi
 
38 - 12.08.19 - 11:01
(35) Возможно просто автор этого не знал. Я в прошлом также делал как и автор, только он для всех ТЧ хочет, а я делал для конкретных.
   ppa32
 
39 - 13.08.19 - 04:31
(35) Если базы разношёрстные, и некоторые из их никак не обновить до последнего релиза (переписанные до неузнаваемости), то как мне заюзать этот чудесный механизм? Я - то не против использовать уже изобретенный велосипед, но вот как? Отдельно БСП возможно ли как - то обновить, чтобы не трогать всё остальное?
   Троекратное ура
 
40 - 13.08.19 - 04:55
(39) Не парься, пиши в регистр в отдельную базу через одата, просто без лишних заморочек с гуидами.
   Троекратное ура
 
41 - 13.08.19 - 04:57
+(40) Вот готовое решение, например: https://help1c.by/hranenie-zhurnala-registratsii-vo-vneshney-baze/
   ppa32
 
42 - 13.08.19 - 05:14
(41) Такое решение я уже сделал,  но оно без детализации: просто хранение журнала вне 1с.
   Троекратное ура
 
43 - 13.08.19 - 05:22
(42) Упс, не то. Готовое решение называется вроде бы "Журнал изменений", у одного моего клиента такой стоял, собирал из зоопарка баз изменения с детализацией до реквизита.
   Сияющий в темноте
 
44 - 13.08.19 - 09:45
ну,для строки важно содержимое,если оно поменялось,то не важно,это новая строка или старая,а если не поменялось,то не важно,где она,и сменила ли позицию,а даже могла быть удалена и снова создана.
выполняем при записи сравнение того,что было с тем,что стало,и различия пишем в регистр. сравнение,желательно,без учета номера строки.

вот и все.
   ppa32
 
45 - 13.08.19 - 09:48
(44) Видимо, так и придется сделать.

Просто хотел избежать ситуации, когда в документе 100500 строк, первую удалили, вторая стала первой. В регистр запишется, что поменян каждый реквизит каждой строки %)
   Cyberhawk
 
46 - 13.08.19 - 09:50
"хотел избежать ситуации, когда в документе 100500 строк, первую удалили, вторая стала первой" // А если поменяли какое-нибудь поле ключа строки?
   Cyberhawk
 
47 - 13.08.19 - 09:51
Или ты хочешь чтоб ключ ("УИД") вобрал в себя все реквизиты ТЧ, кроме номера строки?
   ppa32
 
48 - 14.08.19 - 04:17
(47) Нет. ГУИД будет рандомно генериться в момент записи документа для тех строк, у которых он не заполнен. Соответственно, у каждой строки он всегда будет уникален. В интерфейсе его, разумеется, нельзя будет поменять.
   Garykom
 
49 - 14.08.19 - 04:29
На уровне БД 1С нет отдельных строк в ТЧ объектов, есть только целый объект с которым и манипулируем.
А то что этот объект имеет разные реквизиты и кроме то разные ТЧ в которых так же есть реквизиты это уже мелочи.

Короче приводи задачу к виду "отследить изменение объекта и любого его реквизита в т.ч. в любой строке ТЧ".
   Garykom
 
50 - 14.08.19 - 04:32
Имхо нужная хеш-функция (которая правильно обрабатывает перестановку строк в ТЧ как надо), перед записью каждый раз считаем хеш, если не сошелся то пишем куда то различия до записи и после записи.
И пофиг на какие то гуид и общие реквизиты, строки по данным в ним сопоставляем при надобности старые и новые.
   ppa32
 
51 - 14.08.19 - 05:01
(50) На счет хеша я думал уже, в принципе это может быть альтернативой, но тут вопрос в том, что каждый раз его пересчитывать будет достаточно затратно по ресурсам. А уже посчитанный его негде хранить...
   ppa32
 
52 - 14.08.19 - 05:03
(50) Если только может быть в отдельный поток выпихивать всё это дело, чтобы все эти пересчёты хэшей работали в асинхронном режиме, и у пользователей не было тормозов при проведении документа...
   kuzyara
 
53 - 14.08.19 - 06:32
   ppa32
 
54 - 14.08.19 - 06:43
(53) Мне это ничем не поможет, так как при записи документа он полностью перезаписывает ТЧ. Соответственно, если строка, которая имеет, например, ИД=1, была удалена, то при записи документа после удаления строки ИД=1 присвоится какой - то другой строке, скорее всего той, которая до удаления первой строки имела ИД=2.
   kuzyara
 
55 - 14.08.19 - 08:03
(54) >после удаления строки ИД=1 присвоится какой - то другой строке
вы про _LineNo а я про _KeyField
   kuzyara
 
56 - 14.08.19 - 08:16
>при записи документа он полностью перезаписывает ТЧ
вы проверяли?
   Cyberhawk
 
57 - 14.08.19 - 08:32
(48) Т.е. если пользователь скопировал строку и ничего в ней не изменил, а старую удалил из ТЧ, и пусть даже на тот же номер строки новая встала, что и у удаленной, то это будет считаться изменением ТЧ?
При загрузке данных, например, ТЧ перезаписывается целиком, даже если в ней ничего не поменялось. Такое себе версионирование у тебя выйдет...
   kuzyara
 
58 - 14.08.19 - 08:56
   ppa32
 
59 - 14.08.19 - 09:57
(58) Нечто похожее я начал делать. Но тут опять возвращаемся к тому, что необходим некий набор ключевых полей, то есть привязка к конкретной ТЧ. Например, у документа РеализацияТоваровУслуг есть колонка "Номенклатура", а у "СчетФактураВыданный" такой колонки нет. Причем если базы разные (БП, УТ, ЗУП), то и табличные части будут тоже разные. Соответственно, для каждой из них нужно будет задать набор ключевых столбцов. Гораздо проще тогда ГУИД в ТЧ добавить, и работать по единому механизму. А в некоторых документах ключевых столбцов в общем случае может и не быть: в платформе нигде нет проверки, чтобы в документе не было двух одинаковых строк.
   JeHer
 
60 - 14.08.19 - 10:12
(27) >>>Достаточно запретить пользователю редактировать проведенный и проверенный бухгалтером документ. Этого оказалось достаточным. Кто последний записал тот и виноват.

Я тупо забацал в расширение: кто последний записал объект, тот и редиска. Тому, кто раздаёт штрафы, похрен, что "соседка Оля знает мой пароль или менеджеры подменяют друг друга".
   ppa32
 
61 - 14.08.19 - 10:29
(55) Кейфилд меняется вместе с номером строки ))

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

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

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

В скуле все номера строк и ИД поменялись (удаленная строка была под №3, теперь там другая):
https://ibb.co/XxB44j6
   Вафель
 
62 - 14.08.19 - 10:32
а если строку удалят, а потом снова добавят?
как быть?
   МимохожийОднако
 
63 - 14.08.19 - 10:33
В некоторых типовых конфигурациях в табличных частях есть служебный реквизит КлючСтроки.
ИМХО, сохранять историю изменения табличной части практически тупиковый путь.
   Demasiado
 
64 - 14.08.19 - 11:12
Я может где-то не увидел, но в последних платформах версионирование объектов из коробки есть. Насколько помню, РС тоже логируются
   ppa32
 
65 - 15.08.19 - 01:56
(60) Это назначение виноватых ))
   tesseract
 
66 - 15.08.19 - 01:59
(65) Это повышение личной отвественности.
 
 Рекламное место пустует
   ppa32
 
67 - 15.08.19 - 02:52
(66) Странный у тебя ник для 1Сника))
   breezee
 
68 - 15.08.19 - 06:54
(0) ОФФ Вы же программист, а не заказчик, вы зарезать должны такие бредовые идеи, а не реализовывать их
   тарам пам пам
 
69 - 15.08.19 - 09:21
(59) В первом приближении можно попробовать автоматически определять - считать измерениями все нечисловые поля, а все числовые - считать ресурсами.

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

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

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

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


Список тем форума
Рекламное место пустует  Рекламное место пустует
Кaк может человек ожидaть, что его мольбaм о снисхождении ответит Тот, кто превыше, когдa сaм он откaзывaет в милосердии тем, кто ниже его? Петр Трубецкой
ВНИМАНИЕ! Если вы потеряли окно ввода сообщения, нажмите Ctrl-F5 или Ctrl-R или кнопку "Обновить" в браузере.