[ОТВЕТИТЬ]
Опции темы
28.01.2015 12:52  
FinSoft
Привет, Андрей.
Ты затронул краеугольную тему - обеспечение в системе аудиторского следа. По своей практике (в Купце это сделано было изначально) очень нужная штука. Разборки, кто что сделал в программе, возникают регулярно. Когда есть аудиторский след, все такие вопросы решаются быстро и без лишних эмоций.
Если ты собираешься серьезно поднять эту тему, то там следующие нюансы.
1. Система логирования изменений может быть одной из двух видов. Условно назовем их полная и транзакционная. Полная система предполагает сохранение старого и нового значений полей записей в базе данных. Транзакционная система предполагает сохранение только новых значений, точнее сказать, минимально необходимого количества информации.
В свое время у нас в профессиональном сообществе было бурное обсуждение, в ходе которого рассказывали как о своих разработках, так и идеях, подмеченных в некоторых зарубежных учетных системах.
Я сам остановился на транзакционной схеме, поскольку она позволяет минимизировать объем хранимой информации. Обратная сторона медали - анализировать историю изменений можно только вперед, начиная с момента создания записи. При полной системе можно делать анализ назад от текущего состояния.
2. Лог растет очень быстро, даже транзакционный. Для полноценно работающей фирмы с парой десятков рабочих мест достигнуть пары гигов в таблице лога легко. Поэтому я переношу информацию из оперативного лога в архив при создании резервной копии. Но и этого может быть недостаточно. Поскольку в Купце есть ограничение 2ГБ на физический файл с данными, архив переименовывается при приближении размера к 2ГБ, к имени добавляется год. Программа, соответственно, умеет делать сквозной анализ по всем физическим частям лога.
3. Желательно сразу стандартизировать весь процесс, так как вручную поддерживать логирование довольно затратно по мере развития системы. У меня в стандартных диалогах все делается автоматически, задумываться не надо. А в ручном коде приходится писать типа такого:
буфер = запись
что-то меняем
сохраняем запись с учетом старых значений в буфере.
 
28.01.2015 13:51  
AndreyZh
Извини за перенос в отдельную тему. Извинения: Сборник технологий универсальной системы УС Land

И снова - привет!

Цитата:
Сообщение от FinSoft
Ты затронул краеугольную тему - обеспечение в системе аудиторского следа. По своей практике (в Купце это сделано было изначально) очень нужная штука. Разборки, кто что сделал в программе, возникают регулярно. Когда есть аудиторский след, все такие вопросы решаются быстро и без лишних эмоций.
В УС это довольно древняя (появилась до 2000 г.) подсистема. Необходимость в ней, ты прав возникла из-за постоянных внутрифирменных разборок... конечно с привлечением к ним разработчика.

То, что ты называешь "лог", в УС называется "журнал операций" - jornal.dbf и в него пишутся все (с версии 1503 будет и изменение справочников) операции, изменяющие базу данных системы.

Есть ещё файл "статистики" statist.dbf, в который пишутся все факты использования любых режимов системы, в том числе построения отчетов (попытки доступа к ним, если запрещено). О нём потом!


Цитата:
Сообщение от FinSoft
Если ты собираешься серьезно поднять эту тему, то там следующие нюансы.
1. Система логирования изменений может быть одной из двух видов. Условно назовем их полная и транзакционная. Полная система предполагает сохранение старого и нового значений полей записей в базе данных. Транзакционная система предполагает сохранение только новых значений, точнее сказать, минимально необходимого количества информации...

Я сам остановился на транзакционной схеме, поскольку она позволяет минимизировать объем хранимой информации. Обратная сторона медали - анализировать историю изменений можно только вперед, начиная с момента создания записи. При полной системе можно делать анализ назад от текущего состояния.
Возможно в УС Лэнд - комбинированная схема: "последний" вариант документа (операции) существует лишь в базе, а в журнал пишется только факт создания документа (операции) с сохранением его важных реквизитов. Учитывая наличие правила "двойной записи операции" - в списке документов (операций) и в файле "истории операций" history.dbf его (документа) корректность и неизменяемость можно гарантировать.

При изменении или удалении документа в журнал пишется его "полный старый" вариант, возможно с детализацией до товара, если последнее не отключено в настройках. Приведу пример:

Код:

                                    Журнал операций за период с 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                                        
В нём отражена вся "история" от создания до удаления документа с отражением: имени пользователя, именем ПК в сети, датой, временем, режимом и подробное описание действия пользователя.


Цитата:
Сообщение от FinSoft
2. Лог растет очень быстро, даже транзакционный. Для полноценно работающей фирмы с парой десятков рабочих мест достигнуть пары гигов в таблице лога легко.
В принципе согласен, но у меня он маленько покомпактней: 5 пользователей на запись, около 600 документов в сутки за полгода набирается примерно 200мб. Сразу отмечу, что это сложности для пересылок базы по интернет, а ограничение размера файлов 32 разрядное... точно не могу сказать, но спец.форуме обсуждали тесты скорости и надежности примера с 2 файлами общего "веса" 300гб (у меня не было большего HDD) - "полёт был нормальный"

Цитата:
Сообщение от FinSoft
Поэтому я переношу информацию из оперативного лога в архив при создании резервной копии. Но и этого может быть недостаточно. Поскольку в Купце есть ограничение 2ГБ на физический файл с данными, архив переименовывается при приближении размера к 2ГБ, к имени добавляется год. Программа, соответственно, умеет делать сквозной анализ по всем физическим частям лога.
По несколько иным причинам, но так же есть режим отрезания (архивирования) части журнала и складирования этих архивов "вне БД", а точнее в каталог ls\dujornal (настраивается), там же лежит файл статистики. При анализе журнала операций, форму отчета показывал можно "присоединять" архивы к отчету по журналу.

Цитата:
Сообщение от FinSoft
3. Желательно сразу стандартизировать весь процесс, так как вручную поддерживать логирование довольно затратно по мере развития системы. У меня в стандартных диалогах все делается автоматически, задумываться не надо. А в ручном коде приходится писать типа такого:
буфер = запись
что-то меняем
сохраняем запись с учетом старых значений в буфере.
У меня, как заметил другой подход, но суть от этого не меняется
 
28.01.2015 19:57  
FinSoft
Несколько раз перечитал, но так и не понял.
Контрольный вопрос - можно ли в УС получить версию накладной на произвольную дату?
 
28.01.2015 22:22  
AndreyZh
Цитата:
Сообщение от FinSoft
Несколько раз перечитал, но так и не понял. Контрольный вопрос - можно ли в УС получить версию накладной на произвольную дату?
В принципе подвох понял и в данном контексте - НЕТ! В реальности могу, построив журнал по коду данной накладной видеть основные её реквизиты и список товаров с реквизитами накладной в динамике, т.е. если накладная правилась, то в журнале на конкретную дату могу четко определить её состояние. Это видно в приведенном примере создания, правки, удалении и прочих манипуляций с конкретной приходной накладной.

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



Часовой пояс GMT +3, время: 07:59.

Все в прочитанное - Календарь - RSS - - Карта - Вверх 👫 Яндекс.Метрика
Форум сделан на основе vBulletin®
Copyright ©2000 - 2016, Jelsoft Enterprises Ltd. Перевод: zCarot и OlegON
В случае заимствования информации гипертекстовая индексируемая ссылка на Форум обязательна.