Ему ответил Гэри Линк (Gary Link), см. http://lists.ufl.edu/cgi-bin/wa?A2=ind1009C&L=RECMGMT-L&T=0&F=&S=&P=3813 , точку зрения которого поддержала также такой известный специалист, как Вирджиния Джоунс (Virginia A. Jones):Уважаемые коллеги, у меня есть вопрос, касающийся упомянутой выше темы, а именно:
Недавно мы приступили к внедрению положений нашего Перечня документов с указанием сроков хранения в отношении к нашим физическим документам по расчетам к поставщиками и кредиторами (accounts payable). Одновременно мы хотели бы на основании положений Перечня уничтожить и наши электронные документы этого же вида – с тем, чтобы продемонстрировать последовательность и согласованность наших действий при уничтожении информации на основе её содержания, а не просто в зависимости от носителя.
Проблема, с которой мы сейчас столкнулись, заключается в том, что программное приложение для бухгалтерского учёта, в котором содержится вся электронная информация, использует информацию об этих документах, т.е. информация по расчетам с поставщиками и кредиторами взаимосвязана с другими модулями («Главная книга», «Фонды» и т.д.). Так что если мы удалим или уничтожим информацию о расчетах с поставщиками, то вся остальная информация станет бесполезной - номера не будут совпадать, и т.д. Данные Главной книги и о фондах имеют для нас историческую ценность, и мы не хотели бы их уничтожить. Таким образом, с деловой точки зрения, хотя мы все согласны с тем, что можем уничтожить физические документы по расчетам с поставщиками, мы не хотим уничтожать или стирать соответствующую электронную информацию.
Мой вопрос следующий: как другие компании решают эту проблему? Я думаю, что не нам одним приходится решать такие сложные задачи. Как поступают другие?
Буду рад любым предложениям, комментариям, советам и т.д.
Заранее большое спасибо,
Владимир Альфаро
Влад, я тоже столкнулся с подобной, хотя и не идентичной ситуацией. С моей точки зрения, электронная версия такого рода документов имеет административно-практическое значение и налоговое значение (как ты описывал: имеется активная взаимосвязь со смежными системами), отличающее её от бумажной версии до такой степени, что бумажную и электронную версия следует рассматривать как два разных вида документов, и по-разному устанавливать им сроки хранения.Интересная ситуация, не правда ли? По моему, стоит взять её на заметку :)
Гэри Линк
Источник: архив форума
http://lists.ufl.edu/cgi-bin/wa?A0=RECMGMT-L
Мне кажется вывод не правильный , что будто бы ЭД и бумажный док. разные документы. Мне кажется что всему виной "программное приложение для бухгалтерского учёта" в котором просто разработчиками не предусмотрена возможность удаления документа.
ОтветитьУдалитьДуша радуется за предыдущий комментарий. Именно так! Поэтому в регламентирующих документационное обеспечение управления организаций и следует включать подобного рода существенные аспекты
ОтветитьУдалитьМне кажется вывод не правильный , что будто бы ЭД и бумажный док. разные документы.
ОтветитьУдалитьЯ бы тоже не стала говорить, что это разные документы, и подошла бы к проблеме так: функциональные возможности использования электронных документов отличаются от функциональных возможностей использования бумажных документов. Иногда это различие настолько велико, что существенно изменяется ценность документов - и, как следствие, могут назначаться и разные сроки хранения. Национальные Архивы США в одном из своих методических документов прямо советуют обращать на это внимание.
Относительно ПО Вы IMHO совершенно правы - если, скажем, при проектировании базы данных не заложить в её архитектуру возможность удаления объектов, то удаление станет невозможным, и придется информацию хранить в течение всего времени существования базы. Тем не менее, хотя такая ситуация является следствием ошибки - это все равно IMHO повод установить для информации в базе иной срок хранения, соответствующий фактическому, иначе потом в случае проверок и судебных разбирательств невозможно будет внятно объяснить, почему информация не была вовремя уничтожена.
К сожалению не всегда удается заложить - поскольку сие не прописано внятно в нормативке, например, ФЗ-1 написано что Удостоверяющий Центр обязан обеспечить уникальность открытого ключа, а за какой период не написано (вот дословно связка двух предложений: "проверяет уникальность открытых ключей электронных цифровых подписей в реестре сертификатов ключей подписей и архиве удостоверяющего центра" и далее "Срок архивного хранения составляет не менее чем пять лет.")- вывод - храним ключи вечно и сравниваем, чтобы добиться уникальности.
ОтветитьУдалитьДа, проблема понятна... Задам, может быть, дурацкий вопрос: А нельзя так настроить алгоритм генерации ключей (как-то использовав, скажем, дату), чтобы ключи, созданные в разные годы, заведомо не совпадали?
ОтветитьУдалитьmsm59>> вывод - храним ключи вечно
Ну, все-таки не вечно - скажем, до очередного изменения длины ключа :)
Ключи - это считай случайное число, и чем оно "случайней", тем ключ лучше, именно поэтому все уделяют такое внимание ДТС в том числе и аппаратным (соответственно вводить какие либо зависимости от даты или ещё чего не допустимо). В итоге существует очень малый шанс, но не нулевой, что вновь созданный ключ может совпасть с созданным ранее и такие ситуации следует отслеживать, не говоря уже о том, что по ФЗ-1 (и это правильно) допускает, что ключи создает клиент, а не УЦ, поэтому тут влиять вообще невозможно.
ОтветитьУдалитьНа тему длины ключа - ГОСТом длина ключа жестко определена. ГОСТ - это не RSA.
Поняла - простых решений нет.
ОтветитьУдалитьДа, кстати, - Минюст на днях утвердил новый Перечень управленческих документов (т.е. Перечень теперь - нормативный документ), и о сертификатах там не забыли. Скажем, ст.232 "Сертификаты ключа подписи - Постоянно (в форме электронного документа хранятся не менее 5 л. после исключения из реестра сертификатов ключей подписей)"
В следующей статье 233 - документы типа заявлений на создание ключей и сертификатов - 15 лет ЭПК, с замечательным комментарием: "после аннулирования (прекращения) действия сертификата ключа подписи и истечения установленного федеральным законом срока исковой давности". Если понимать буквально - это 15 лет + 3 года (стандартный срок исковой давности).
Или, скажем, ст.238 "Переписка о сертификатах ключа подписи - 15 лет ЭПК"