Реферат: Система автоматизации документооборота. Электронный документ
Новеллы в Законе "О бухгалтерском учете" и НК РФ наиболее полно конкретизируются в приказе МНС России от 10.12.02 г. N БГ-3-32/705@ "Об организации и функционировании системы представления налоговых деклараций и бухгалтерской отчетности в электронном виде по телекоммуникационным каналам связи". [8]
В частности, в документе раскрываются такие вопросы, как: требования к программно-аппаратным средствам представления налоговых деклараций и бухгалтерской отчетности в электронном виде по телекоммуникационным каналам связи; процедура сопровождения налоговой и бухгалтерской отчетности в электронном виде; требования к специализированным операторам связи; правила использования средств ЭЦП и средств шифрования; порядок электронного документооборота при представлении налоговых деклараций и бухгалтерской отчетности в электронном виде.
Порядок представления налоговой декларации в электронном виде по телекоммуникационным каналам связи утвержден приказом МНС России от 02.04.02 г. N БГ-3-32/169. [9]
В частности, налогоплательщик обязан придерживаться следующих требований к обороту сведений в интерактивном режиме с налоговыми органами:
после подготовки информации, содержащей данные налоговой декларации, налогоплательщик подписывает ее ЭЦП уполномоченного лица налогоплательщика и отправляет в зашифрованном виде в налоговый орган по месту учета;
в течение суток в адрес налогоплательщика налоговый орган высылает квитанцию о приеме декларации в электронном виде. После проверки подлинности ЭЦП уполномоченного лица налоговым органом налогоплательщик сохраняет документ в своем архиве.
В заключение следует остановиться на вопросах, связанных с дальнейшим развитием электронного документооборота на корпоративном уровне.
Федеральный закон от 27.12.02 г. N 184-ФЗ "О техническом регулировании" позволяет организациям легитимизировать методологию и технологию электронного документооборота, которые они фактически используют. [10]
Это осуществляется посредством утверждения стандартов организаций. Стандарты организаций в соответствии со ст.17 Закона N 184-ФЗ могут разрабатываться и утверждаться организациями самостоятельно исходя из необходимости их применения в целях совершенствования производства и повышения качества продукции, выполнения работ, оказания услуг. Стандарты организаций могут утверждаться и в целях распространения и использования полученных в различных областях знаний результатов исследований (испытаний), измерений и разработок.
Одним из первых стандартов организаций в России является стандарт регионального благотворительного общественного фонда "Право и Интернет" - "Телемедицина. Общие положения" от 29.12.02 г. N 1-2512/2002. [11]
3. Процедуры разрешения конфликтов
Для нормального функционирования систем электронного документооборот (ЭДО) необходимо разработать процедуры разрешения возможных конфликтов. Стороной таких конфликтов (кроме участников ЭДО и фирмы-провайдера) может быть и фирма-разработчик программного обеспечения.
При описании всех процедур предполагается, что договор с фирмой-разработчиком учитывает наличие эталонного образца программного обеспечения (ПО), который может храниться только у фирмы-провайдера или у всех участников системы ЭДО, но при этом требуется выполнение двух основных условий.
Должно быть документально подтверждено, что каждому участнику системы ЭДО (включая фирму-провайдер) установлено программное обеспечение, соответствующее эталонному образцу. Хранение эталонных образцов организуется таким образом, чтобы исключить возможность изменения эталонного образца программного обеспечения без ведома сторон: участника, у которого данное ПО установлено, разработчика и фирмы-провайдера. Указанный режим может быть обеспечен, например, системой нескольких ключей, когда носитель с эталонным образцом хранится в конверте, опечатанном всеми заинтересованными сторонами, либо в сейфе с несколькими различными ключами.
Опишем теперь процедуры разрешения конфликтов, которые могут возникнуть в процессе функционирования систем ЭДО.
1. Одна из сторон отказывается от принятия на себя обязательств по документу, заверенному ее действующей цифровой подписью, причем последняя признается подлинной программой проверки другой стороны.
В этом случае проверяется целостность программного обеспечения сторон путем сравнения используемого программного обеспечения с эталонным образцом. Далее возможны следующие варианты:
а) если будет выяснено, что программное обеспечение одной из сторон отличается от эталонного, то вся ответственность (включая возмещение возможных убытков) лежит на данной стороне;
б) если же программное обеспечение сторон соответствует эталонным образцам, то повторно проверяется подлинность цифровой подписи с помощью программного обеспечения, соответствующего эталону. Если подпись признается действительной в результате повторной проверки эталонным ПО, а сторона, чьей подписью заверен документ, отказывается принять на себя обязательства по документу, то назначается экспертная комиссия, которая на основании изучения спорного документа на магнитном носителе, распечатки этого документа вместе с цифровой подписью под ним на бумажном носителе, образца цифровой подписи ответчика (открытого ключа), заверенного его личной подписью и мастичной печатью, выносит заключение о подлинности цифровой подписи и ее соответствии техническому описанию используемых алгоритмов.
2. Одна из сторон отказывается от приема и рассмотрения документа на основании того, что цифровая подпись другой стороны под документом воспринимается как фальшивая.
Тогда сторона, отказавшая в приеме документа, заверяет свой отказ от рассмотрения документа личной подписью и мастичной печатью, а вторая сторона повторно подписывает документ цифровой подписью и направляет его первой стороне.
Если новая подпись опять признается программой проверки первой стороны недействительной, то проверяется сохранность (соответствие эталонному образцу) программного обеспечения сторон. Здесь возможны следующие варианты:
а) нарушено программное обеспечение у автора документа - тогда отказ другой стороны от рассмотрения документа является правомерным;
б) разрушено программное обеспечение у стороны, отказавшейся от приема документа, - в данном случае она обязана возместить убытки, возникшие вследствие ее отказа от рассмотрения документа; основанием для привлечения к ответственности служит официальный отказ от приема документа.
Важное значение для нормального функционирования систем ЭДО имеет разработка процедур определения случаев, когда наступает ответственность разработчика программного обеспечения.
Алгоритмы, используемые в программном обеспечении ЭЦП, признаются ненадежными, если доказана практическая возможность за приемлемый срок:
а) либо подделать подпись под документом;
б) либо определить по образцу подписи и подписанным документам секретный ключ;
в) либо изменить документ, не нарушив подлинности подписи.
Программное обеспечение ЭЦП признается не соответствующим техническому описанию используемых алгоритмов, если документ, подписанный с использованием программного обеспечения, соответствующего эталонному образцу, одной стороной, воспринимается как фальшивый соответствующим эталонному образцу программным обеспечением другой стороны (при условии, что обе стороны используют действующие ключи подписывания).