Отправлено: 07.07.26 12:52. Заголовок: История изменения накладных

Кто то делал в этом плане такую задачу ?
Собственно интересует сам интерфейс , что бы бух
смог быстро найти что ему нужно не сломав при этом глаза.
Gemini и ChatGpt я уже спрашивал....

 Отправлено: 07.07.26 13:48. Заголовок: Dima У меня было ~т..

Dima
У меня было ~так, сделано на VO2.5\7 (документы 2х уровневые, реестр и детальные строки, файлы\таблицы по месяцам)
- имеют log текстовыми файлами
- new запись в логе содержит все поля по ключу ID (имеет счетчик правок := 0)
- правки по ключу ID содержат имя поля, кто когда
Когда надо (для проверяющих) лог файлы съедаются в dbf таблицы, где правки - это пустая запись, только со значением исправленного поля поля, каждая строка имеет счетчик правок += 1, по ним и ключу ID (есть и др. поля) создаются тэги для просмотра в аналоге TsBrowse, т.е. имеем список реестра со счетчиком правок == 0 (все правки), ищем нужную, выбираем, попадаем на просмотр счетчик правок >= 0 (строки правок), причем, в Footer имеем последнее\тек. значение записи. Выбираем далее просмотр изменения строк документа и попадаем на просмотр строк-список дет.строк со счетчиком правок == 0 и далее все по похожей схеме, выбираем дет.строку - получаем просмотр счетчика правок >= 0 на нее и т.д. и т.п.
VO прога работала от ini настроек (~как сейчас есть в hmg), т.е. каждый просмотр это Run запуск ее с параметром ini и ID для scope фильтра. Справочники с правками работали в той же схеме. VO прога могла делать печать, в Excel и txt

 Отправлено: 07.07.26 13:59. Заголовок: SergKis Спасибо, по..

SergKis
Спасибо, понял!

 Отправлено: 07.07.26 17:37. Заголовок: Dima у меня в систем..

Dima у меня в системе реализовано довольно просто... Есть плоская таблица

 
 Jornal.dbf	      Шпион. Журнал учета операций. 
  
 codOper	c 4	Зашитый код операции (режима) 
 tabel		c 4	код операциониста 
 opDate	d 8	дата проведения операции 
 opTime	c 8	время операции (входа в задачу) 
 stat		n 1	0-авария,1-Да,2-ничего,3-зап.по правам,4-зап.условиям 
 qtyAll	n 6	время в секундах проведенное в режиме или 0 
 comm		c 150	подробное описание действий пользователя 
 name		c 10  имя компьютера в сети

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

Каждый документ имеет уникальный код и по нему можно извлечь историю. Как правило такие выяснения происходят крайне редко и такой информации достаточно

Есть отчет по данному журналу с ограничителями:

 
     @ 1,1 SAY "Для отчета пожалуйста введите: Код работника или ничего ...." 
     @ 2,1 SAY "Первые цифры кода режима (например 01 - отг. накладные) ...." 
     @ 3,1 SAY "Дата начала периода ........    и окончания периода ........" 
     @ 4,1 SAY "Начальное время - формат ЧЧ:ММ:СС ........ конечное ........" 
     @ 5,1 SAY "1-статистика работы в режимах,2-по сбоям,3-подробно о сбое ." 
     @ 6,1 SAY "Буквы входящие в имя компьютера (ничего по всем)  .........." 
     @ 7,1 SAY "Знаки входящие в описание операции.  Запятая как условие 'И'" 
     @ 8,1 SAY "............................................................" 
     @ 9,1 SAY "Цифру 1 - если необходимо анализировать также и архивы ж/о ." 
     @10,1 SAY "Введите знак-разделитель дроб.части, если экспорт в MsOff  ."

Например фрагмент отчета:

-***карева Л.А.                                    |0102 Изменение        |Изменена накладная SY2X Сумма 1551393.48(1551393.48)   
 USERPC                 29.06.26  (      ) 11:16:35|отгрузочной накладной |Склад 02(02) Клиент 04Z8(04Z8) Скидка 0.0000(0.0000)   
                                                   |                      |Дата 27.06.26(27.06.26) №_3755(3755)                   
 ---------------------------------------------------------------------------------------------------------------------------------- 
 -***карева Л.А.                                   |0102 Изменение        |ОТГРSY2X 71IK   CR  Торт "Рулет Сказка" 500            
 USERPC                 29.06.26  (      ) 11:17:15|отгрузочной накладной |150.67     2940.000  22.00   0.00                      
                                                   |                      |                                                       
 ---------------------------------------------------------------------------------------------------------------------------------- 
 -***карева Л.А.                                   |0102 Изменение        |ОТГРSY2X 6YDE   CR  Торт "Сникерс" 650                 
 USERPC                 29.06.26  (      ) 11:17:15|отгрузочной накладной |234.24     4732.000  22.00   0.00                      
                                                   |                      |                                                       
 ---------------------------------------------------------------------------------------------------------------------------------- 
 

 Отправлено: 07.07.26 17:42. Заголовок: AndreyZh Спасибо! ..

AndreyZh
Спасибо!
Тоже вариант.

 Отправлено: 07.07.26 18:52. Заголовок: Дим, привет. делал п..

Дим, привет.
делал примерно как и AndreyZh

тоже каждый документ имеет свой id , изменения пишутся в журнал изменений со структурой
id - ид изменяемого документа
table - имя изменяемой таблицы ( не алиас , а именно имя базы )
alias - имя алиаса
browse - имя бровса
person - ид сотрудника изменившего запись
dtime - timestamp изменения в формате времени HH:MM:SS,FFF
text - описание изменения

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

далее по полям журнала отдельный бровс с фильтрами ( использую механизм Fast Text Search от ADS - быстро ищет по вхождению )
хеш так же используется для реализации CTL-Z (отката последнего изменения ) - в этом случае запись в журнале удаляется

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

 Отправлено: 07.07.26 19:24. Заголовок: Haz Пасиб Игорь!..

Haz
Пасиб Игорь!

 Отправлено: 08.07.26 13:09. Заголовок: У меня - каждая накл..

У меня, когда юзер входит в накладную, в таблице "монитор" фиксируется дата/время входа

Во временной таблице - состояние накладной на момент входа:
--
код товара
количество
цена
--
После выхода из накладной - делается сравнение текущего её состояния и если есть изменения - созадется уникальный ID и по нему в третью таблицу пишется:
--
код товара
было, штук
стало, штук
было, цена
стало, цена
--
Если изменений не было - ID не создается, просто остается отметка, что "юзер сидел в этой накл NN минут".
--
Третья таблица формируется в отдельном каталоге одна на каждый календарный день. Ибо это, по сути, информационный мусор, который в среднем через 6..9 месяцев уходит в корзину.

PS: в процессе работы получил доп. бенефит: если выхода из накладной не зафиксировано, а на данной машине юзер "входит в программу", значит был RTE или что-то серьезнее. И юзер попадает в эту-же самую накладную, чтобы продолжтить в ней работу и корреетно ее провести и закрыть.

 Отправлено: 08.07.26 13:44. Заголовок: Sergy Спасибо!..

Sergy
Спасибо!

 Отправлено: 08.07.26 17:56. Заголовок: Gemini гугла вот так..

Gemini гугла вот такое предлагает.
Сдублировал ему вопрос нашего буха

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

Он ответил так

 
 Это отличная, классическая задача аудита. 
 Требование бухгалтера состоит из двух четких пожеланий:«Что, кто и когда» — это классический скриншот 
 сквозного протокола (лог-файла). 
 «Нажать и открыть сохраненный документ» — это функция «Снимок версии» (Snapshot), 
 когда по нажатию Enter программа временно загружает из архива состояние 
 накладной именно на тот момент времени и открывает её в стандартном режиме 
 просмотра (ReadOnly).Для реализации этого в консоли Harbour 
 идеально подходит структура «Лента событий с глубоким просмотром». 
  
 

Всем спасибо. Буду думать как лучше и удобнее сделать.
Собственно в самом начале я писал именно про интерфейс а не о том как базы организовать

PS
Посмотрел в ютуб ролики из 1с как там организовано...чёт мне не понравилось

 Отправлено: 08.07.26 20:48. Заголовок: Dima Так это практи..

Dima
Так это практически то, что я писал тебе о просмотре в VO TsBrowse (пропустил, не написал, что справочники так же подключаются к просмотру)
первая строка как была new с колонками, следующие строки колонки правки и в Footer тек. состояние и это как по реестру\списку документов\накладных (клиент, адреса, ... - заголовочная инфа и подножие док.), так и по детальным ее строкам (все с данными кто и когда, + пометка как удаленные), т.е. это база dbf и работа как в задаче, можно по ID перейти к тек. документу из осн. базы и в любом периоде для показа

 Отправлено: 08.07.26 20:49. Заголовок: SergKis OK..

SergKis
OK

 Отправлено: 10.07.26 09:56. Заголовок: Dima пишет: писал и..

Dima пишет:

цитата:

писал именно про интерфейс

Дим , мы не поняли😱
У меня так :
В tsbrowse клик правой мышкой по ячейке выпадает меню , в нем пункт история изменений В ЯЧЕЙКЕ,
Я отслеживаю не весь документ , а его поля по отдельности.
Там вываливает в окно бровса и пользователь видит кто что когда.
Соответственно отчеты можно клеить любые.
Была мысль подсвечивать измененные ячейки , но отказался.
Сделал отправку сообщения почтой об изменении всем согласовавшим первоначальный вариант.
Поскольку запоминается таблица , не важно в каком алиасе кто что делал, Все работает везде одинаково.

 Отправлено: 10.07.26 12:36. Заголовок: Haz Понято, дякую ..

Haz
Понято, дякую

 Отправлено: 10.07.26 18:50. Заголовок: https://i.ibb.co/DgP..

Вот в ТСБ такое же делал - историю изменения данных в записи абонента.
Там дальше открывается журнал-изменений, тоже ТСБ и список изменений оператором,
когда, кто и на что поменяли данные.

 Отправлено: Сегодня 10:08. Заголовок: Dima Я бы загонял с..

Dima
Я бы загонял снимок документа в хэш-массив, а далее, каждая ветка (например с ключем timestamp) содержит отличные элементы оригинала, все это хранить в json, можно в memo. Если данные уникальные, то легко делать слияние по шагам изменений.

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

 Отправлено: Сегодня 12:13. Заголовок: MIKHAIL Спасибо..

MIKHAIL
Спасибо