Электронные документы и ЭЦП

1.1. Для production юридически значимое действие в авторизованной сессии должно сохранять конкретного пользователя, организацию, роль, основание полномочий, серверное время, неизменяемое содержимое, результат и контрольную сумму. Коммерческое согласование Заказа хранит отдельную проверяемую цепочку таких сообщений; активное членство подтверждает только внутреннюю авторизацию и не заменяет корпоративную доверенность. Операционный журнал статусов, не связанный с таким снимком, сам по себе полным доказательством волеизъявления не считается.

1.2. OTP, кнопка подтверждения, push или email-код являются цифровыми подтверждениями. Они могут выражать волю в согласованных процессах, но не обеспечивают неизменность содержимого и не являются ЭЦП.

1.3. Электронным документом в смысле Цифрового кодекса является цифровая запись, достоверность, принадлежность и неизменность которой обеспечены ЭЦП. PDF без связанной ЭЦП — только визуальная копия.

2.1. Платформа может формировать:

• Заказ и историю согласования его существенных условий;
• электронную накладную на поставку и её исправленные ревизии;
• payload приёмки с принятым количеством и расхождениями;
• акт возврата и историю решений по возврату;
• проверочный пакет с payload, hash, CMS, сертификатом и результатом проверки.

2.2. Документы aluber не являются ЭСФ, СНТ или документами иной государственной системы и не заменяют их. Каждая сторона самостоятельно оформляет обязательные формы.

3.1. До письменного решения бухгалтера и закрепления формы в учётной политике накладная aluber является дополнительной договорной записью и не заявляется как первичный учётный документ Поставщика или Покупателя.

3.2. Если стороны утверждают её как первичный документ, она формируется в момент соответствующей хозяйственной операции или непосредственно после неё и содержит обязательные реквизиты статьи 7 Закона о бухгалтерском учёте: наименование и дату, составителя и идентификационный номер, содержание, количественное и стоимостное измерение, должности, ФИО и подписи ответственных лиц.

3.3. Участнику операции и уполномоченному государственному органу по законному требованию предоставляется пригодная для печати бумажная копия электронного первичного документа; возможность скачать PDF не отменяет обязанность выдать такую копию.

3.4. Исправление первичного документа согласуется участниками, датируется и подтверждается подписями ответственных лиц в требуемом законом составе. Новая техническая ревизия без предусмотренного согласования и подписей сама по себе не считается бухгалтерским исправлением.

4.1. До выпуска сервер формирует канонический JSON с версией схемы, идентификаторами, сторонами, реквизитами, строками, количествами, ценами, адресом и временем. Порядок ключей детерминирован, а SHA-256 рассчитывается по точным байтам.

4.2. До создания ЭЦП подписант получает возможность ознакомиться с содержанием и явно подтвердить подписание. Подписывается envelope, содержащий документ, его hash, назначение подписи и одноразовый challenge.

4.3. PDF содержит номер, ревизию и SHA-256 и создаётся для чтения и печати. Если PDF включает более поздние логистические статусы, они явно отделяются от неизменяемого подписанного payload.

5.1. Подписание выполняется средством, совместимым с НУЦ РК, без передачи закрытого ключа Оператору. Пользователь самостоятельно обеспечивает сохранность ключа и не передаёт его третьим лицам.

5.2. Сервер принимает CMS только после доверенной проверки сертификата, цепочки, срока действия и отзыва, соответствия подписанного payload, ИИН подписанта и БИН представляемой организации.

5.3. Текущий контур ЭЦП предназначен только для юридических лиц и совместных ИП с присвоенным БИН, который включён в подписанный production allowlist. Обычный ИП, идентифицируемый ИИН, может использовать Заказы, накладные, PDF и приёмку без ЭЦП; подписание остаётся недоступным до отдельной модели сертификата, идентификатора и полномочий.

5.4. Без доверенного сервиса проверки полномочий корневого удостоверяющего центра Республики Казахстан создание и приём ЭЦП в production полностью недоступны. Внутренняя роль владельца является только дополнительным контуром доступа и не заменяет проверку полномочий по статье 61 Цифрового кодекса.

5.5. До запроса ИИН, полномочий или иных персональных данных из цифрового объекта государственного органа либо государственного юридического лица Оператор отдельно квалифицирует поток по статьям 8-1 и 10 Закона о персональных данных. Если исключение закона неприменимо, production-запрос закрыт до интеграции с государственным сервисом контроля доступа к персональным данным и сохранения его проверяемого подтверждения.

5.6. После подключения сервиса в доказательства включаются момент, идентификатор и ответ проверки полномочий; одного совпадения БИН в сертификате недостаточно. Ошибка, таймаут, устаревший результат или несовпадение закреплённого trust profile приводят к отказу в подписании.

6.1. Поставщик подписывает выпущенную ревизию накладной. Покупатель отдельно подписывает payload приёмки, который ссылается на hash накладной и содержит фактически принятое количество и расхождения.

6.2. Подпись покупателя не меняет подписанную накладную поставщика. Совокупность документов показывает, что было заявлено к передаче и что фактически принято.

6.3. Исправление оформляется новой ревизией со ссылкой на заменённую, её hash и причину. Прежняя ревизия и подписи остаются доступными и не перезаписываются.

7.1. В текущем пилотном контуре подписать или принять документ с ЭЦП может только пользователь с активной внутренней ролью владельца соответствующей организации; участники с ролью участника к подписанию не допускаются.

7.2. Внутренняя роль управляет доступом к функции, но не заменяет устав, приказ, доверенность, электронную доверенность или проверку полномочий через предусмотренный законом сервис. Подписант самостоятельно обеспечивает наличие действующего основания полномочий.

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

8.1. После успешной записи документ технически доступен адресату в кабинете. Зафиксированное сервером время записи само по себе не доказывает юридический момент получения адресатом: он определяется применимым договором и подтверждается отдельным неизменяемым receipt доставки. Уведомление по SMS или email носит вспомогательный характер, если договор прямо не установил иное.

8.2. Время фиксируется сервером в UTC и отображается в часовом поясе пользователя; для доказательства существования подписи во времени используется сервис метки времени, когда он доступен и требуется.

8.3. Сбой интерфейса не считается отказом стороны от права. Пользователь сообщает о недоступности в поддержку, а стороны используют согласованный резервный канал.

9.1. До включения ЭЦП в production Оператор предоставляет требуемый пунктом 4 статьи 61 Цифрового кодекса открытый сервис проверки подписей без входа в кабинет. Он проверяет переданный электронный документ или автономный evidence package, показывает результат проверки в необходимом объёме и не требует публичного раскрытия самого документа, ИИН либо коммерческих условий.

9.2. Отдельная QR-проверка по bearer-токену является только необязательным privacy-safe поиском сохранённого статуса и не заменяет обязательный открытый сервис криптографической проверки. Она по умолчанию выключена; при отключённом QR-контуре код ведёт в авторизованный кабинет. Минимальный QR-ответ не является повторной онлайн-проверкой сертификата на текущую дату и не раскрывает стороны, суммы, номера документов, ИИН, серийные номера или fingerprints сертификатов.

9.3. Авторизованная сторона проверяет целостность, связь сохранённых CMS и исторический результат серверной проверки в кабинете либо по выгруженному пакету в пределах утверждённой процедуры доступности и выгрузки.

9.4. Сторона документа может отдельно скачать PDF-копию и автономный JSON-пакет: канонический payload и его точные байты, CMS-подписи, данные сертификатов, хеши и сохранённые результаты проверки. Сам JSON-пакет содержит версию формата и служит машинно-читаемым manifest.

9.5. Электронный документ должен сохранять возможность обращения и проверки вне Платформы. Формат пакета и инструкция независимой проверки публикуются и версионируются до утверждения production-контура ЭЦП.

10.1. Электронные документы, подписи и доказательства хранятся неизменяемо в течение обязательного срока по законодательству и утверждённому графику. Резервные копии размещаются в Казахстане.

10.2. До прекращения доступа Оператор предоставляет стороне возможность выгрузить собственные документы и сообщает срок доступности read-only кабинета либо защищённого резервного канала. Конкретный срок, порядок восстановления доступа и массовой выгрузки определяются утверждённой offboarding-процедурой и не могут быть меньше обязательного по закону или отдельному договору.

11.1. О спорной подписи, утрате ключа или ошибке документа необходимо немедленно сообщить на webberdyev@gmail.com и в удостоверяющий центр. Оператор сохраняет доказательства, блокирует новые операции при обоснованном риске и не удаляет спорную запись.

11.2. Стороны вправе использовать государственный сервис проверки электронных документов, независимую экспертизу и судебные средства защиты.