Notal System: справочники

В Notal System есть сущности "Задача", "Документ", "Пользователь", задачи организованы в бизнес-процесс, который описывается через "Состояния" и "Переходы". По сути, это основной конструктор, из которого все там строится. В этом наборе не хватает одной важной возможности - нет Справочников, к примеру - списка Контрагентов. Для того, чтобы реализовать эту возможность, рассмотрим их назначение и возможности использования.

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

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

Способы использования справочников
1. Хранение информации. Список контактов полезен сам по себе, особенно если в нем организован поиск и отбор по реквизитам. Считаем хранение долгополезной информации базовой функцией справочников.
2. В качестве реквизита других объектов. К примеру, у задачи/документа мы можем завести допреквизит Клиент типа "справочник.Контрагенты" и иметь под рукой нужную справочную информацию. Более интересное использование - поиск всех задач/документов, у которых одним из реквизитов (или определенным реквизитом) является данный элемент данного справочника.
3. Для формирования документов по шаблону. Сейчас мы умеем создавать документ на основе шаблона, передавая в него контекст архива и/или задачи. Если у документа уже будут заданы и заполнены реквизиты типа справочник (или у задачи), то возможности для заполнения текста документа значительно расширяются.

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

Общая конструкция справочников
Надо иметь общий список справочников, из которого каждый справочник можно открыть в списке. Список одноуровневый. Из списка можно открыть элемент справочника для просмотра или редактирования.
Каждый справочник имеет свей id (число) и Наименование (к примеру, id=1 "Контрагенты"). Управление доступом осуществляется на уровне справочника в целом Т.е. если пользователь имеет доступ к справочнику "Контрагенты", то ко всем его элементам в равной степени. Управление доступом осуществляется по следующим параметрам:

• Просмотр справочника в списке (используется в т.ч. для заполнения реквизитов задачи или документа)
• Просмотр элемента со всеми его реквизитами
• Добавление нового элемента
• Редактирование элемента справочника (удаление не предусмотрено)

Справочник имеет свой набор реквизитов, которые могут иметь тип:

• Число
• Строка
• Дата
• Справочник определенного типа
• (возможно) Пользователь

Отображение в списке каждого реквизита может настраиваться (id виден всегда). Так же каждый реквизит может использоваться для отбора (числа и даты по интервалу значений; строки по "содержит", "не содержит", "начинается с", "не начинается с"; справочники по конкретному элементу) - это вполне заменит многоуровневость списков.
Сортировку предполагаем только по реквизитам типа строка, число, дата (в т.ч. по id и наименованию). Желательно иметь быстрый поиск по мере набора на клавиатуре (если несложно реализовать).
Для редактирования элементов и для просмотра применяется одна форма - самая простая, типа той, что мы используем для допреквизитов задачи. Позже можно задуматься над редактором форм.
Элемент справочника всегда имеет экранное представление в виде пары id+Наименование. Надо предусмотреть стандартные кнопки открытия списка для выбора элемента и открытия реквизита (выбранного элемента) на просмотр. Это должно быть сделано одинаково во всех местах, где справочник может использоваться как реквизит - в задачах, в документах и в справочниках (когда один справочник имеет реквизит типа другой справочник).

Стандартные отчеты по справочнику
1. Печатная форма списка. Должна учитывать установленные видимость реквизитов, сортировку и отбор.
2. Печатная форма элемента справочника. Очевидно.
3. Объекты со ссылками на данный элемент справочника. Выбираем элемент справочника и смотрим все задачи, все документы и все другие справочники, у которых данный элемент выбран в качестве какого-либо из реквизитов. Настройки данного отчета: выбор типа и ограничения объектов для поиска: к примеру, задачи данного бизнес-процесса, задачи в активных состояниях, только документы или документы данной категории. В частности, так можно посмотреть все подчиненные элементы данного элемента справочника - к примеру, все Контакты данного Контрагента.
4. Объекты с косвенными ссылками на данный элемент справочника. Примерно то же, что и предыдущий отчет, но сначала мы находим все элементы всех справочников, которые имеют данный элемент своим реквизитом, а потом строим предыдущий отчет уже по множеству найденных элементов. Это имеет смысл, если у нас есть конструкция типа "подчиненный справочник" - у справочника "Контакты" есть реквизит "Контрагент", то есть фактически мы имеем Контрагента и его Контакты (работников). К примеру, к Письмам (категория документов) у нас привязан только Контакт - нам интересно собрать всю переписку с данным Контрагентом. То есть по Контрагенту мы находим все его Контакты, а потом по этим Контактам - все документы.

Специальное использование справочников
Справочник Контактов надо использовать для отправки писем: создали документ с данным контактом и сразу отправили его по электронной почте по адресу, указанному в Контакте.
Можно рассмотреть возможность привязки элемента справочника к исполнителю и наоборот - привязку исполнителя к элементу справочника. То есть к пользователю мы можем привязать контакт и хранить там расширенную информацию о пользователе, а можем к контакту привязать пользователя, т.е. с этим контактом работает данный пользователь. Это требует додумывания.
Формирование и хранение выборок из справочников. Из справочника Контрагенты по определенным критериям выбрали возможных клиентов, разбили список на несколько частей и каждой части назначили исполнителя, который обзвонит этх потенциальных клиентов. Что это за объект - такая выборка и как с ней работать - требует додумывания.

Импорт/экспорт через XML
Требуется импорт справочников через XML - к примеру, выгрузкой из 1С. Критерии выгрузки - не важно. Проверка дубликатов при загрузке, причем дубликаты могут выявляться по реквизитам, не по id или Наименованию - к примеру, Контрагетов проверяем по ИНН.
Также желательно иметь экспорт справочников в XML.

Необходимые изменения, напрямую не связанные со справочниками
Поскольку одним из основных использований справочников является заполнение документов по шаблону, то надо сменить очередность действий при создании документа:

• нажимаем кнопку [создать новый]
• выбираем шаблон
• заполняем/редактируем описание документа
• заполняем реквизиты (допполя) документа
• и только теперь формируем документ по шаблону

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

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

Клиент Notal System - перехват событий в офисных программах

Постановка проблемы
Большинство документов СЭД (системы электронного документооборота) редактируются в офисных программах - нас интересуют ставшие стандартом де-факто Ms Office и Open Office. В них требуется научиться делать следующие вещи:

• Перехватывать закрытие документа
• Перехватывать печать документа
• Отличать документ, полученный из Notal System, от просто документа на локальном компе
• Различать взятые из Notal System документы по типу - взятые на просмотр и взятые на редактирование
• Различать, из какой именно базы Notal System взят документ - пользователь может с одного компа работать с несколькими базами

Если мы можем перехватить печать документа и можем понять, что он получен из Notal System, то дальше можем после печати сохранить новую версию в СЭД или более интересные штуки типа логирования печати и т.п.

Требования к опознанию документов как взятых из СЭД Notal System
Считаем, что вмешиваться во внутреннюю структуру документа мы не можем - для офисных документов это в принципе возможно, но хотелось бы иметь механизм, который бы не зависел от типа файла и мог бы быть распространен на другие типы файлов (к примеру, на инженерную графику - t-flex и т.п. имеют встроенные языки программирования, так что в будущем и на них можно портировать те же механизмы.
То есть у нас имеется не так много способов различать файлы:

• Складывать взятые из СЭД файлы в определенную папку (или структуру папок)
• Записывать имя файла в БД на локальном компе и потом сверяться с этими записями
• Всю нужную информацию кодировать в имени файла

Поскольку СЭД Notal System работает в веб-интерфейсе, то не всё подконтрольно: разные браузеры складывают документы в разные папки, причем не всегда это можно настраивать. Кроме того, использовать локальную БД нежелательно, поскольку это переусложнит клиентскую часть и может потеряться гибкость веб-технологий.
Опознавать документ будем по имени файла, причем это опознание должно быть устойчиво к некоторым модификациям имени файла которые делают браузеры: к примеру, при повторном скачивании файла браузеры по-разному модифицируют его имя - Opera добавляет в конце " (1)", " (2)" и т.д., Mozilla Firefox добавляет "-1", "-2" и т.д.

Структура имени файла документа из Notal System
Различать разные базы Notal System будем по ключевому числу NN - целое трехзначное число, желательно простое или произведение двух двузначных простых чисел. Зададим его и тогда формат взятого из Notal System документа будет таким (жирным выделены константные части:

iiii_vvvE=AAAAAAABBB=

где iiii - id документа в Notal System (переменое число знаков, цифры, не может начинаться с 0),
vvv - номер версии документа (переменое число знаков, цифры, не может начинаться с 0),
E - указатель на то, что документ взят на редактирование; для взятых на просмотр ставим знак V,
AAAAAAA - случайное число 7 цифр с ведущими нулями, если требуется. Должно быть больше 1000.
BBB - проверочный код, 3 цифры с ведущими нулями, если требуется; вычисляется по формуле BBB = AAAAAAA mod NN, т.е. остаток от деления AAAAAAA на ключевое число NN.
Знаки "_" и "=" задают структуру имени файла. Всё, что идет после второго знака "=", при аналие отбрасывается.
Структура имени файла позволяет узнать id документа и узнать, взят ли документ на редактирование или только на просмотр. Номер версии документа для работы программы не важен, но полезен для пользователя. Случайное число в имени файла гарантирует, что дважды взяв документ из СЭД мы получим разные имена файлов. Проверка соотношения чисел AAAAAAA и BBB позволяет с большой долей надежности установить базу Notal System, из которой взят документ.

Расчет вероятности ложного опознания базы-источника документа
Считаем, что сама специфическая структура имени файла однозначно указывает на то, что файл взят из СЭД Notal System. Пусть на локальном компьютере пользователя зарегистрированы две базы с ключевыми числами NN₁ и NN₂. Тогда вероятность того, что одновременно выполняются два соотношения

• BBB = AAAAAAA mod NN₁
• BBB = AAAAAAA mod NN₂

равна 1/НОК(NN₁, NN₂), где НОК - наименьшее общее кратное. Поскольку мы выбираем NN₁ и NN₂ простыми, то формула упрощается до 1/(NN₁*NN₂). Поскольку оба числа трехзначные, то полученная вероятность гарантированно меньше 10^-4 и почти всегда меньше 10^-5, что позволяет нам не заботиться о ложных срабатываниях (по крайней мере в первой версии клиентской части Notal System).

Необходимые доработки серверной части Notal System

• Добавить в раздел общей информации системы ключевое число
• Создать механизм задания ключевого числа - вручную или случайно из списка подходящих простых чисел (контроль того, что все эти числа для установленных на нашем сервере баз различны, осуществляем пока вручную)
• Написать функцию API, которая запрашивает у базы ее ключевое число (понадобится для конфигурирования ini-файла клиента)

Информация в ini-файле на машине клиента
В файле notalconfig.ini, расположенном в папке C:\NotalSystem\conf\, раздел каждой базы (имя раздела [base*], где "*" означает любой текст без пробелов) должен содержать следующие строки:

URL = http://test.notalsystem.ru/ - веб-адрес базы Notal System
KeyNumber = 449 - ключевое число
Name = "Тест" - название базы: произвольный краткий текст, нужен для показа в диалоговых окнах и т.п.

Сейчас считаем, что пользователь руками редактирует ini-файл, позже можно сделать конфигуратор клиента.

Что должна делать клиентская программа в офисном пакете
Для каждого офисного пакета (и в будущем - для программ инженерной графики) настраиваем отдельно, но одинаковый функционал:

• Перехватываем закрытие документа и определяем базу
  • Если он взят на редактирование и изменен, то предлагаем отправить новую версию документа в СЭД
• Перехватываем печать документа и определяем базу
  • Если он взят на редактирование и изменен, то печатаем и после этого отправляем новую версию документа в СЭД. Вариант: спрашиваем пользователя, делать ли это, если нет, то не отправляем новую версию, но и не печатаем.
  • Если он взят на просмотр и изменен, то не печатаем. Вариант: предупреждаем об этом пользователя, проверяем, что он имеет право редактировать этот документ, предлагаем ему сохранить отредактированную версию в СЭД (тут используется механизм, который мы используем для добавления новых версий документов из 1С, т.е. не беря предварительно документ на редактрирование.
  • Если документ не был изменен, то печатаем без каких-либо иных действий.

Позже к этому функционалу можем добавить логирование печати (потребуются соответствующие функции API).

Особенности реализации перехвата событий в Ms Office
Нас интересуют только Ms Word и Ms Excel. В этих программах перехват событий организован по-разному.
В Excel подключенная надстройка загружается как рабочая книга, так что в контейнере ThisWorkbook размещаем предопределенную функцию Workbook_Open(), а в ней включаем перехват событий через специальный класс.
В Word в шаблоне, расположенном в папке Word\STARTUP, создаем модуль AutoExec с процедурой MAIN(), которая запускается при загрузке Word. Перехват событий в ней организуется аналогично Excel.

Особенности реализации перехвата событий в Open Office
В Open Office для всех типов файлов работает единый механизм, организация перехвата событий там требует отдельного описания.

Распечатка документов из СЭД: проблема несовпадения

У нас на заводе автоматизированы несколько бизнес-процессов на Notal System - системе управления задачами и документооборотом. Вот в одном бизнес-процессе - ремонте модельной оснастки - обнаружилась засадливая проблема. Последовательность действий такова (упрощенно):

• все начинается с создания дефектной ведомости - документа с описанием проблемы и необходимых действий (текстовый документ в формате Open Office)
• создается задача и к ней цепляется дефектная ведомость
• дефектная ведомость распечатывается и подписывается всяким начальством
• задача передается на исполнение
• ...(потом много чего происходит)...
• после выполнения работ задача поступает в ОТК, который открывает дефектную ведомость и по ней проверяет, все ли работы выполнены.

И вот тут обнаруживается проблема - иногда оказывается, что дефектная ведомость пуста. То есть на бумаге-то она заполнена, а в электронном виде - нет. Все прелести электронного документооборота - псу под хвост.
В чем причина этой проблемы? Чисто технически, дефектная ведомость создается по шаблону в Notal System, то есть заполняется минимальный набор реквизитов, а собственно содержательная часть - дефекты и необходимые работы - являются неформализованной информацией и пишутся технологом в текстовом редакторе. То есть созданный в СЭД (системе электронного документооборота) по шаблону документ (файл) открывается на редактирование, редактируется, распечатывается и в СЭД отправляется новая версия. Вот в этой последней последовательности действий возможны ошибки:

• документ взят на редактирование, отредактирован, распечатан, но новая версия в СЭД не отправлена (в СЭД такой документ будет виден как взятый на редактирование)
• документ взят из СЭД на просмотр, отредактирована локальная копия, распечатана. В СЭД тогда будет только первоначальная, пустая по сути, редакция документа.

Что с этим делать? Вариантов несколько.
Радикальный вариант. Полностью отменить бумажные документы и перейти на электронные. Не годится по следующим причинам:

• в цеху все равно нужна бумажная распечатка - проще к станку принести бумажку в кармане, чем компьютер;
• всякое начальство привыкло к бумажкам и засадить их за компы - задача весьма сложная, требуется серьезная мотивация (проблемы ОТК таковой не являются);
• подпись на бумажке все-таки более юридически значима, чем запись в базе данных и ЭЦП.

В общем, отметаем это решение за излишнюю радикальность.
Автоматизированное порождение конечного документа. Это как распечатка накладной из 1С: там все заполняешь в диалоговом окне, а потом нажимаешь на кнопку [Печать] и формируется печатная форма. Решение тоже не годится - слишком уж вариативно содержание дефекой ведомости, там могут быть и таблицы, и эскизы. То есть если бы дефектная ведомость была бы хорошо формализуемым документом, то она и порождалась бы из системы планирования производства, а не из СЭД. В конце концов, всегда есть такие категории неструктурированных документов - те же письма, к примеру. Надо решать задачу на уровне СЭД при условии, что документ будет редактироваться пользователем в текстовом редакторе или электронных таблицах - грубо говоря, в Ms Office или Open Office.
Административные и воспитательные меры. Что если воспитать/убедить/запугать пользователей, чтобы они отрабатывали правильную последовательность действий до конца? Это сделать надо, конечно, но человек вообще склонен делать ошибки - одна эта мера явно недостаточна.
Модификация функции печати. Что если при печати перехватывать это событие и автоматически обновлять версию документа в СЭД? Вот это - решение! Надо сделать следующее:

• в редакторе опознавать документ как взятый из СЭД (мы же не хотим, чтобы пользователь не мог нормально работать с файлами на своем локальном компе);
• при открытии в СЭД документа в режиме просмотра запретить его редактирование в текстовом редакторе - то есть документ распечатать можно, а изменить и потом распечатать - нельзя;
• при печати документа если он взят на редактирование в СЭД сохранять в ней новую версию документа. То есть распечатал - документ закрылся и отправился в СЭД.

Осталось научиться перехватывать события печати и открытия документа в Open Office (в Ms Office умею), и запрограммировать клиентскую часть Notal System.

Электронный архив - набросок проектной документации

Есть у нас проблема: куча информации лежит в экселевских таблицах, текстовых документах и т.п. С этими файлами ведется двоякая работа:
а) В один xls-файл несколько пользователей вносят информацию - маленькие кусочки, но ежедневно. В основном это ежедневная сводка для руководства. Работать с файлом по сети - бывает, Excel начинает виснуть. Да и пойди пойми, кто сейчас занял файл.
Примечание: да, знаю, что по уму это не в файле хранить надо, а в базе данных. Возражения тут следующее: руководство очень часто меняет формат этой сводки, нужная информация должна умещаться на одной-двух страницах; так что разумной автоматизации не получается - поди пойми, что в следующий раз понадобится, а что мешать будет.
б) Разные группы пользователей должны иметь разный доступ к документам, в основном быстро найти и открыть на просмотр. Рулить на уровне NTFS неудобно, к тому же если все в файлах, то имена у этих файлов как автор захочет. Неудобно, в общем.
в) Случайная порча файла - случается; быстро восстановить предыдущую копию - а она хорошо если вчерашняя, а надо бы получасовой давности.

Вот чтобы это все как-то разгрести и хочется положить все такие файлы на web-сервер, зарегистрировать их в базе данных и нормально с ними работать - хранить историю версий, работать не по сети, а "скачал - отредактировал - вернул". И чтобы специальный робот смотрел выбранные каталоги на выбранных машинах, и если файлы изменились, добавлял их новые версии в базу данных. В общем, функции электронного архива и системы управления версиями.
Понятно, что таких систем имеется много; но все же напишем свою, больше для того, чтобы разобраться в потребностях, да и с нашим трекером удобней будет состыковывать. Ниже - набросок проектной документации.

1. Общие требования к ЭА

Номинальная емкость системы - 1,000,000 документов, т.е. ID это шестизначное целое число с ведущими нулями. Реальная емкость, исходя из которой рассчитываем сейчас объемы и скорости - 10,000 документов.
Система предназначена для хранения файлов, которые мы считаем бинарными - т.е. без анализа их содержимого. Реально там будут текстовые файлы (форматы txt, doc, odt, pdf, htm и т.п.), файлы электронных таблиц (xls, ods), всевозможные файлы инженерной графики и изображения (в основном отсканированные образы документов).
Быстрая работа системы требуется с текущими версиями документов, добавление нового документа/новой версии, получение одной предыдущей версии документа. Работа с более ранними версиями может быть не быстрой - это гораздо более редкое событие.


2. Хранение файлов в ЭА

Файлы хранятся в папке на сервере, точнее - по подпапкам (не более 100 файлов в папке для ускорения работы с файлом). При помещении в ЭА файл переименовывается - новое имя совпадает с его ID в ЭА с ведущими нулями, расширение остается прежним.
Версии файла нумеруются четырьмя знаками, имя файла версии имеет вид ID_VER, где ID 6 знаков, VER четыре знака. Версии файла, кроме предпоследней, могут храниться как в виде файла на сервере, так и в tar-архиве для экономии места.
Для каждого файла (ID) может быть установлен режим хранения его версий - к примеру, храним одну ежедневную версию (на конец дня), или храним все версии возраста менее недели, потом оставляем из них ежедневные версии, а по истечении месяца - только еженедельные. В заархивированном виде лучше хранить те версии, которые уже предназначены для весного хранения (или можно их разбить по разным архивным файлам).


3. ER-диаграмма ЭА




4. Функции ядра ЭА

Все функции возвращают два результата: успешно или нет; в случае успеха - запрошенное действие (описывается ниже в каждой функции), в случае неудачи - код причины неудачи.

В каждую функцию передается как один из аргументов Пользователь, от имени которого вызывается функция. Две цели: (1) проверить права, может ли данный пользователь выполнять эту функцию; (2) записать в БД имя пользователя как актора действия (там, где это требуется).

ДобавитьНовыйДокумент(Файл /поток загрузки/)
- возвращает ID файла в ЭА

ВзятьДокумент(ID файла, Режим= просмотр/редактирование)
- возвращает поток скачивания файла. Имя файла - то, что задано как пользовательское в БД, можно в комбинации с ID
- если файл взят на редактирование, то устанавливает в БД блокировку на него с указанием имени взявшего файл пользователя

ДобавитьВерсиюДокумента(ID файла, Файл /поток загрузки/)
- возвращает номер версии файла (пред. + 1)

ОсвободитьЗанятыйДокумент(ID файла)
- функцию может выполнять пользователь, взявший файл (не стал редактировать), а также пользователь со спецправами - менеджер. Пример: человек взял файл на редактирование и заболел, надо иметь возможность файл разблокировать пусть даже его работа потеряется.

ПолучитьРеквизитыДокумента(ID файла)
- возвращает список пар "реквизит/значение"

УстановитьРеквизитыДокумента(ID файла, новые реквизиты)
- функция для редактирования всяческих реквизитов файла в БД; новые реквизиты - список пар "реквизит/новое значение"

ПолучитьВерсиюФайлаПоНомеру(ID файла, номер версии)
- возвращает поток скачивания файла. Имя файла - то, что задано как пользовательское в БД, можно в комбинации с ID и номером версии

ПолучитьСписокВерсийФайла(ID файла)
- список троек "номер версии/дата версии/статус (есть ли реально)"


5. Взаимодействие с пользователями и приложениями

В основном с электронным архивом пользователь будет работать не напрямую, а через трекер - практически все документы относятся к какому-нибудь бизнес-процессу, он либо положен в 1С (тогда ID файлов храним там), либо для его автоматизации заводим экземпляр трекера с соответствующей диаграммой состояний, и храним ID файлов в инцидентах.



6. Роботы ЭА

В электронном архиве работают два робота (программы, запускающиеся по времени, раз в сутки).

Робот-архиватор раз в сутки проверяет, не обновились ли указанные в листах-шаблонах файлы (и не появились ли новые), и добавляет новую версию в электронный архив. Требуется в основном для программных файлов на макроязыке 1С (формат txt, ert), места они занимают немного, а когда срочно исправляешь ошибку, можно и забыть сохранить предыдущую версию (особо полезно, когда исправление ошибки привело к возникновению новой - понять, что не так).
Обратное действие к действиям робота - развернуть программные файлы в тех версиях, которые были на определенную дату. Это важно, если мы хотим восстановить старую архивную копию 1С - внутренний программный код сохраняется, а все внешние отчеты и программные модули надо хранить отдельно. Вот для этого робот-архиватор и нужен.

Робот-хранитель чистит и упаковывает архив. Когда экономисты делают свои сводки, то им полезно иметь версии файла после каждой правки - чтобы в случае порчи быстро откатиться назад к последней нормальной версии. Но затем хранить эти версии (десяток за день) не надо - это чисто рабочий материал. Поэтому у каждого документа в ЭА мы указываем режим хранения - какие версии сколько хранить, к примеру "вечное" хранение только для последней версии за сутки, а все другие версии этих суток удаляются. Может, не сразу - через три дня. Да и хранить их в виде файлов слишком роскошно - старые версии сжимаем в архив. Все это делает робот-хранитель.

------------------------------

Вот примерно такой первый набросок. По ходу дела буду додумывать. Хотя бы систему прав - как удобно сделать.