Обеспечение аудиторского следа в оперативной работе с системой : КИС Lack & УС Land
22.11.2024 12:41
█ 28.01.2015 12:52
Привет, Андрей.
Ты затронул краеугольную тему - обеспечение в системе аудиторского следа. По своей практике (в Купце это сделано было изначально) очень нужная штука. Разборки, кто что сделал в программе, возникают регулярно. Когда есть аудиторский след, все такие вопросы решаются быстро и без лишних эмоций.
Если ты собираешься серьезно поднять эту тему, то там следующие нюансы.
1. Система логирования изменений может быть одной из двух видов. Условно назовем их полная и транзакционная. Полная система предполагает сохранение старого и нового значений полей записей в базе данных. Транзакционная система предполагает сохранение только новых значений, точнее сказать, минимально необходимого количества информации.
В свое время у нас в профессиональном сообществе было бурное обсуждение, в ходе которого рассказывали как о своих разработках, так и идеях, подмеченных в некоторых зарубежных учетных системах.
Я сам остановился на транзакционной схеме, поскольку она позволяет минимизировать объем хранимой информации. Обратная сторона медали - анализировать историю изменений можно только вперед, начиная с момента создания записи. При полной системе можно делать анализ назад от текущего состояния.
2. Лог растет очень быстро, даже транзакционный. Для полноценно работающей фирмы с парой десятков рабочих мест достигнуть пары гигов в таблице лога легко. Поэтому я переношу информацию из оперативного лога в архив при создании резервной копии. Но и этого может быть недостаточно. Поскольку в Купце есть ограничение 2ГБ на физический файл с данными, архив переименовывается при приближении размера к 2ГБ, к имени добавляется год. Программа, соответственно, умеет делать сквозной анализ по всем физическим частям лога.
3. Желательно сразу стандартизировать весь процесс, так как вручную поддерживать логирование довольно затратно по мере развития системы. У меня в стандартных диалогах все делается автоматически, задумываться не надо. А в ручном коде приходится писать типа такого:
буфер = запись
что-то меняем
сохраняем запись с учетом старых значений в буфере.
Ты затронул краеугольную тему - обеспечение в системе аудиторского следа. По своей практике (в Купце это сделано было изначально) очень нужная штука. Разборки, кто что сделал в программе, возникают регулярно. Когда есть аудиторский след, все такие вопросы решаются быстро и без лишних эмоций.
Если ты собираешься серьезно поднять эту тему, то там следующие нюансы.
1. Система логирования изменений может быть одной из двух видов. Условно назовем их полная и транзакционная. Полная система предполагает сохранение старого и нового значений полей записей в базе данных. Транзакционная система предполагает сохранение только новых значений, точнее сказать, минимально необходимого количества информации.
В свое время у нас в профессиональном сообществе было бурное обсуждение, в ходе которого рассказывали как о своих разработках, так и идеях, подмеченных в некоторых зарубежных учетных системах.
Я сам остановился на транзакционной схеме, поскольку она позволяет минимизировать объем хранимой информации. Обратная сторона медали - анализировать историю изменений можно только вперед, начиная с момента создания записи. При полной системе можно делать анализ назад от текущего состояния.
2. Лог растет очень быстро, даже транзакционный. Для полноценно работающей фирмы с парой десятков рабочих мест достигнуть пары гигов в таблице лога легко. Поэтому я переношу информацию из оперативного лога в архив при создании резервной копии. Но и этого может быть недостаточно. Поскольку в Купце есть ограничение 2ГБ на физический файл с данными, архив переименовывается при приближении размера к 2ГБ, к имени добавляется год. Программа, соответственно, умеет делать сквозной анализ по всем физическим частям лога.
3. Желательно сразу стандартизировать весь процесс, так как вручную поддерживать логирование довольно затратно по мере развития системы. У меня в стандартных диалогах все делается автоматически, задумываться не надо. А в ручном коде приходится писать типа такого:
буфер = запись
что-то меняем
сохраняем запись с учетом старых значений в буфере.
█ 28.01.2015 13:51
Извини за перенос в отдельную тему. Извинения: Сборник технологий универсальной системы УС Land
И снова - привет!
То, что ты называешь "лог", в УС называется "журнал операций" - jornal.dbf и в него пишутся все (с версии 1503 будет и изменение справочников) операции, изменяющие базу данных системы.
Есть ещё файл "статистики" statist.dbf, в который пишутся все факты использования любых режимов системы, в том числе построения отчетов (попытки доступа к ним, если запрещено). О нём потом!
При изменении или удалении документа в журнал пишется его "полный старый" вариант, возможно с детализацией до товара, если последнее не отключено в настройках. Приведу пример:
В нём отражена вся "история" от создания до удаления документа с отражением: имени пользователя, именем ПК в сети, датой, временем, режимом и подробное описание действия пользователя.
И снова - привет!
Цитата:
В УС это довольно древняя (появилась до 2000 г.) подсистема. Необходимость в ней, ты прав возникла из-за постоянных внутрифирменных разборок... конечно с привлечением к ним разработчика. FinSoft ➤ Ты затронул краеугольную тему - обеспечение в системе аудиторского следа. По своей практике (в Купце это сделано было изначально) очень нужная штука. Разборки, кто что сделал в программе, возникают регулярно. Когда есть аудиторский след, все такие вопросы решаются быстро и без лишних эмоций.
То, что ты называешь "лог", в УС называется "журнал операций" - jornal.dbf и в него пишутся все (с версии 1503 будет и изменение справочников) операции, изменяющие базу данных системы.
Есть ещё файл "статистики" statist.dbf, в который пишутся все факты использования любых режимов системы, в том числе построения отчетов (попытки доступа к ним, если запрещено). О нём потом!
Цитата:
Возможно в УС Лэнд - комбинированная схема: "последний" вариант документа (операции) существует лишь в базе, а в журнал пишется только факт создания документа (операции) с сохранением его важных реквизитов. Учитывая наличие правила "двойной записи операции" - в списке документов (операций) и в файле "истории операций" history.dbf его (документа) корректность и неизменяемость можно гарантировать. FinSoft ➤ Если ты собираешься серьезно поднять эту тему, то там следующие нюансы.
1. Система логирования изменений может быть одной из двух видов. Условно назовем их полная и транзакционная. Полная система предполагает сохранение старого и нового значений полей записей в базе данных. Транзакционная система предполагает сохранение только новых значений, точнее сказать, минимально необходимого количества информации...
Я сам остановился на транзакционной схеме, поскольку она позволяет минимизировать объем хранимой информации. Обратная сторона медали - анализировать историю изменений можно только вперед, начиная с момента создания записи. При полной системе можно делать анализ назад от текущего состояния.
1. Система логирования изменений может быть одной из двух видов. Условно назовем их полная и транзакционная. Полная система предполагает сохранение старого и нового значений полей записей в базе данных. Транзакционная система предполагает сохранение только новых значений, точнее сказать, минимально необходимого количества информации...
Я сам остановился на транзакционной схеме, поскольку она позволяет минимизировать объем хранимой информации. Обратная сторона медали - анализировать историю изменений можно только вперед, начиная с момента создания записи. При полной системе можно делать анализ назад от текущего состояния.
При изменении или удалении документа в журнал пишется его "полный старый" вариант, возможно с детализацией до товара, если последнее не отключено в настройках. Приведу пример:
Код:
Журнал операций за период с 28.01.15 по 28.01.15 Стр. 1
----------------------------------------------------------------------------------------------------------------------------------
ФИО работника / ИмяПК, Дата,Время |Режим работы программы| Подробное описание операции пользователя с программой
----------------------------------------------------------------------------------------------------------------------------------
|0238 Дублирование |Создана копия прихода 0E6T без распределения. Новый
ANDREY 28.01.15 ( ) 13:36:10|накладной без |приход 0E7D от поставщика 018E Каштан СПб ООО
|распределения. ПРИХОД.|
----------------------------------------------------------------------------------------------------------------------------------
|0217 Распределение и |Для прихода 0E7D сделано распределение и возможна
ANDREY 28.01.15 ( ) 13:36:23|изготовление отгрузки.|отгрузка (и оплата). Клиент 018E Каштан СПб ООО на
|Приход от поставщика |склад 03
----------------------------------------------------------------------------------------------------------------------------------
|0209 Изменение |Изменена проводимость у накл. и связанных фин.
ANDREY 28.01.15 ( ) 13:36:26|обязательности у накл.|документов 0E7D от 26.01.15 на 018E Каштан СПб ООО
|и ее фин. документов. |Новый признак НЕТ
----------------------------------------------------------------------------------------------------------------------------------
|0240 Откат (удаление) |Откат распределения для ПРИХОДА 0E7D Клиент 018E
ANDREY 28.01.15 ( ) 13:36:34|операции |Каштан СПб ООО
|распределения. Приход |
----------------------------------------------------------------------------------------------------------------------------------
|0202 Изменение |ПРИХ0E7D 3FD9 Т-296н
ANDREY 28.01.15 ( ) 13:36:36|приходной от |3.99 16000.000 18.00 0.00
|поставщика накладной |
----------------------------------------------------------------------------------------------------------------------------------
|0202 Изменение |ПРИХ0E7D 3FD8 Т-297н
ANDREY 28.01.15 ( ) 13:36:36|приходной от |5.70 16000.000 18.00 0.00
|поставщика накладной |
----------------------------------------------------------------------------------------------------------------------------------
|0202 Изменение |Изменена накладная 0E7D от клиента 018E Каштан СПб
ANDREY 28.01.15 ( ) 13:36:40|приходной от |ООО (018E) от даты 26.01.15(26.01.15) на сумму 63840.
|поставщика накладной |00(155040.00)
----------------------------------------------------------------------------------------------------------------------------------
|0203 Удаление не |ПРИХ0E7D 3FD9 Т-296н
ANDREY 28.01.15 ( ) 13:36:46|распределенной |3.99 16000.000 18.00 0.00
|приходной накладной |
----------------------------------------------------------------------------------------------------------------------------------
|0203 Удаление не |Удалена нераспределенная накладная и все связанные
ANDREY 28.01.15 ( ) 13:36:46|распределенной |документы 0E7D от 26.01.15 на 018E Каштан СПб ООО
|приходной накладной |Сумма 63840.00
Цитата:
В принципе согласен, но у меня он маленько покомпактней: 5 пользователей на запись, около 600 документов в сутки за полгода набирается примерно 200мб. Сразу отмечу, что это сложности для пересылок базы по интернет, а ограничение размера файлов 32 разрядное... точно не могу сказать, но спец.форуме обсуждали тесты скорости и надежности примера с 2 файлами общего "веса" 300гб (у меня не было большего HDD) - "полёт был нормальный" FinSoft ➤ 2. Лог растет очень быстро, даже транзакционный. Для полноценно работающей фирмы с парой десятков рабочих мест достигнуть пары гигов в таблице лога легко.
Цитата:
По несколько иным причинам, но так же есть режим отрезания (архивирования) части журнала и складирования этих архивов "вне БД", а точнее в каталог ls\dujornal (настраивается), там же лежит файл статистики. При анализе журнала операций, форму отчета показывал можно "присоединять" архивы к отчету по журналу. FinSoft ➤ Поэтому я переношу информацию из оперативного лога в архив при создании резервной копии. Но и этого может быть недостаточно. Поскольку в Купце есть ограничение 2ГБ на физический файл с данными, архив переименовывается при приближении размера к 2ГБ, к имени добавляется год. Программа, соответственно, умеет делать сквозной анализ по всем физическим частям лога.
Цитата:
У меня, как заметил другой подход, но суть от этого не меняется FinSoft ➤ 3. Желательно сразу стандартизировать весь процесс, так как вручную поддерживать логирование довольно затратно по мере развития системы. У меня в стандартных диалогах все делается автоматически, задумываться не надо. А в ручном коде приходится писать типа такого:
буфер = запись
что-то меняем
сохраняем запись с учетом старых значений в буфере.
буфер = запись
что-то меняем
сохраняем запись с учетом старых значений в буфере.
█ 28.01.2015 19:57
Несколько раз перечитал, но так и не понял.
Контрольный вопрос - можно ли в УС получить версию накладной на произвольную дату?
Контрольный вопрос - можно ли в УС получить версию накладной на произвольную дату?
█ 28.01.2015 22:22
Цитата:
В принципе подвох понял и в данном контексте - НЕТ! В реальности могу, построив журнал по коду данной накладной видеть основные её реквизиты и список товаров с реквизитами накладной в динамике, т.е. если накладная правилась, то в журнале на конкретную дату могу четко определить её состояние. Это видно в приведенном примере создания, правки, удалении и прочих манипуляций с конкретной приходной накладной. FinSoft ➤ Несколько раз перечитал, но так и не понял. Контрольный вопрос - можно ли в УС получить версию накладной на произвольную дату?
Ты же "хочешь" видеть нечто типа "скана" накладной в любой момент времени, когда над ней производились действия... Такого нет.
█ 04.02.2019 14:39
Сегодня день встряхивания "мощей"? Всплыла задача почему отчет в статистику, созданный в 2010 году для организации другого типа бизнеса даёт расхождения с другими отчетами... Разобрался и пришлось его дорабатывать по бизнес процессы другой фирмы. В очередной раз похвалил себя за хорошую документацию исходного кода - это к теме: https://olegon.ru/showthread.php?t=17102
Но не по этому поводу поднята эта древняя тема, а так навеяло
Уже 2 недели между делом занимаюсь глобальной переделкой всего комплекса из-за нюансов не продуманных двадцать лет назад. Надеюсь это позволит избежать новым проектировщикам такого рода проблем? Уже переделаны сотни режимов, но только по приходным ТТН и на возврат от покупателей - начать и кончить!
От куда ноги растут? Была сверка с большим контрагентом, было обнаружено десятки "пропавших" возвратных накладных и как всегда нужно было выявить: кто? когда? и зачем? их удалил.
Я, как знающий "глубины" системы на выяснение по одной ТТН истратил 30 минут... Были сделаны манипуляции: добавлена ТТН, изменен товар (сумма) и клиент, удалена.
Программа каждое это действо фиксировало в журнале операций с отражением большого числа (изменяемых) атрибутов ТТН... Всё, кроме единственного уникального идентификатора - номера накладной, который имелся в акте сверки.
Суть переделки комплекса "УС Land": по каждой операции со всеми типами документов, а их под тысячу, в журнал (аудиторский след) писать так же номер и его изменение... При это постараться не допускать ошибок с синтаксисе программы, т.е. проверяя каждое изменение - "закат солнца в ручную"
Но не по этому поводу поднята эта древняя тема, а так навеяло
Уже 2 недели между делом занимаюсь глобальной переделкой всего комплекса из-за нюансов не продуманных двадцать лет назад. Надеюсь это позволит избежать новым проектировщикам такого рода проблем? Уже переделаны сотни режимов, но только по приходным ТТН и на возврат от покупателей - начать и кончить!
От куда ноги растут? Была сверка с большим контрагентом, было обнаружено десятки "пропавших" возвратных накладных и как всегда нужно было выявить: кто? когда? и зачем? их удалил.
Я, как знающий "глубины" системы на выяснение по одной ТТН истратил 30 минут... Были сделаны манипуляции: добавлена ТТН, изменен товар (сумма) и клиент, удалена.
Программа каждое это действо фиксировало в журнале операций с отражением большого числа (изменяемых) атрибутов ТТН... Всё, кроме единственного уникального идентификатора - номера накладной, который имелся в акте сверки.
Суть переделки комплекса "УС Land": по каждой операции со всеми типами документов, а их под тысячу, в журнал (аудиторский след) писать так же номер и его изменение... При это постараться не допускать ошибок с синтаксисе программы, т.е. проверяя каждое изменение - "закат солнца в ручную"
█ 04.02.2019 18:40
Привет, Андрей. Для строк документов я пишу в лог идентификатор записи строки и идентификатор записи заголовка документа. Идентификатор заголовка документа - это так называемое "hot field" лога. Такие поля отмечаются специальной меткой в словаре, базовые процедуры работы с логом генерятся автоматически.
В сам лог пишутся только заполненные поля при добавлении записи, поля с измененными значениями при изменениях, идентификатор записи при удалении. Ну и hot поля.
Анализ лога на высоком уровне (всякие аналитические отчеты) строится путем раскрутки от создания записей до заданных моментов времени. Это довольно сложный функционал. Зато в логе хранится минимум информации (она также автоматически упаковывается на системном уровне). Даже при таком раскладе логи растут быстро и превышают размеры самой базы данных. Поэтому лог еще безразмерный, он может состоять из нескольких файлов с определенными названиями. Программа автоматически выполняет анализ по всем составным частям.
В сам лог пишутся только заполненные поля при добавлении записи, поля с измененными значениями при изменениях, идентификатор записи при удалении. Ну и hot поля.
Анализ лога на высоком уровне (всякие аналитические отчеты) строится путем раскрутки от создания записей до заданных моментов времени. Это довольно сложный функционал. Зато в логе хранится минимум информации (она также автоматически упаковывается на системном уровне). Даже при таком раскладе логи растут быстро и превышают размеры самой базы данных. Поэтому лог еще безразмерный, он может состоять из нескольких файлов с определенными названиями. Программа автоматически выполняет анализ по всем составным частям.
Часовой пояс GMT +3, время: 12:41.
Форум на базе vBulletin®
Copyright © Jelsoft Enterprises Ltd.
В случае заимствования информации гипертекстовая индексируемая ссылка на Форум обязательна.
Copyright © Jelsoft Enterprises Ltd.
В случае заимствования информации гипертекстовая индексируемая ссылка на Форум обязательна.