Система документооборота в веб-сервисе: счета, акты, договоры, файлы, статусы и доступы

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

Хороший документооборот в веб-сервисе - это не просто раздел "Файлы". Это управляемый жизненный цикл документов: создание, загрузка, генерация, проверка, согласование, отправка, подписание, хранение, скачивание, архивирование, отзыв, повторная выдача и аудит действий. У каждого документа должны быть владелец, тип, статус, версия, связь с заказом или договором, права доступа и история.

Для B2B-порталов, личных кабинетов, SaaS, сервисов заявок, маркетплейсов, платформ с API и интеграций с 1С документооборот часто становится одной из самых ценных функций. Клиент хочет не просить менеджера "пришлите акт еще раз", а зайти в кабинет и скачать нужный документ. Бухгалтер хочет видеть, какие документы сформированы и какие требуют действия. Руководитель хочет контролировать сроки, статусы и риски. А владелец сервиса хочет, чтобы документы не были отдельной ручной жизнью вне продукта.

Когда веб-сервису нужен документооборот

Документооборот нужен не каждому сайту. Если сайт просто показывает услуги и принимает заявки, достаточно формы обратной связи и email-уведомления. Но как только веб-сервис начинает обслуживать реальные операции, документы становятся частью продукта.

Система документов нужна, если:

• клиенты получают счета, акты, договоры, спецификации или закрывающие документы;

• есть личный кабинет клиента или партнера;

• заказ проходит несколько статусов;

• документы формируются из данных системы;

• менеджеры согласуют договоры или коммерческие предложения;

• клиент должен загружать файлы;

• бухгалтерия работает с оплатами и актами;

• документы приходят из 1С, CRM, ERP или другой учетной системы;

• есть несколько юридических лиц, филиалов или компаний-клиентов;

• разные роли должны видеть разные файлы;

• требуется история версий;

• нужно понимать, кто скачал, загрузил, изменил или удалил документ;

• документы влияют на оплату, доступ, поставку или выполнение услуги.

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

Какие документы бывают в веб-сервисе

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

Чаще всего в веб-сервисах встречаются:

• счета;

• акты;

• договоры;

• приложения к договору;

• спецификации;

• коммерческие предложения;

• закрывающие документы;

• накладные;

• счета-фактуры;

• квитанции;

• чеки;

• сертификаты;

• инструкции;

• технические паспорта;

• заявки;

• отчеты;

• анкеты;

• согласия;

• доверенности;

• загруженные клиентом файлы;

• внутренние служебные документы.

У каждого типа разные правила. Счет может быть связан с заказом и оплатой. Акт - с периодом оказания услуги. Договор - с компанией, юридическим лицом, версией и сроком действия. Сертификат - с товаром или партией. Загруженный файл клиента - с заявкой и проверкой. Отчет - с периодом, фильтрами и правами пользователя.

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

Документ как сущность, а не просто файл

Главная архитектурная ошибка - считать документ обычным файлом. Файл - это бинарное содержимое: PDF, DOCX, XLSX, JPG, PNG или архив. Документ - это бизнес-сущность.

У документа должны быть:

• тип;

• номер;

• дата;

• статус;

• владелец;

• компания;

• филиал, если он нужен;

• связанный заказ, заявка, платеж или договор;

• текущая версия;

• автор;

• источник;

• права доступа;

• срок действия;

• комментарии;

• история событий;

• файлы;

• метаданные;

• признак архива.

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

Такой подход особенно важен для личных кабинетов и B2B-порталов. В статье про разработку B2B-портала документы рассматриваются как часть взаимодействия с клиентом. В этой статье фокус уже глубже: как сделать сам документ управляемым объектом веб-сервиса.

Жизненный цикл документа

Документ редко появляется и сразу становится финальным. Обычно он проходит несколько этапов.

Пример жизненного цикла:

• черновик;

• создан;

• ожидает проверки;

• на согласовании;

• согласован;

• отправлен клиенту;

• просмотрен;

• скачан;

• ожидает подписи;

• подписан;

• отклонен;

• отменен;

• заменен новой версией;

• архивирован.

Для разных типов документов статусы отличаются. У счета важны "выставлен", "оплачен", "просрочен", "отменен". У акта - "сформирован", "отправлен", "подписан", "отклонен". У договора - "проект", "на согласовании", "подписан", "истек", "расторгнут". У клиентского файла - "загружен", "на проверке", "принят", "нужна замена".

Статус должен быть понятен пользователю и сотруднику. Если клиент видит "обработан", но не понимает, что делать дальше, статус бесполезен. Лучше использовать статусы, связанные с действием: "Ожидает подписи", "Нужно заменить файл", "Счет оплачен", "Акт доступен для скачивания".

Счета, оплаты и закрывающие документы

Счета и акты часто связаны с оплатами. Но статус платежа и статус документа - не одно и то же.

Счет может быть:

• создан;

• отправлен;

• ожидает оплаты;

• частично оплачен;

• оплачен;

• просрочен;

• отменен;

• заменен;

• возвращен в работу.

Платеж при этом может быть успешным, ожидающим подтверждения, отмененным или возвращенным. Акт может появляться после оплаты, после оказания услуги, по окончании периода или вручную бухгалтером. Если смешать эти статусы, система начнет показывать неверную картину.

В веб-сервисе нужно связать:

• счет;

• заказ;

• платеж;

• чек;

• акт;

• договор;

• компанию;

• ответственного;

• юридическое лицо;

• статус оплаты;

• статус закрывающего документа.

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

Договоры и версии

Договор - один из самых чувствительных типов документов. Его нельзя просто заменить новым файлом без истории. Нужно понимать, какая версия была отправлена, какая подписана, кто ее загрузил, кто согласовал и какая действует сейчас.

Для договоров важно хранить:

• номер;

• дату;

• стороны;

• юридические лица;

• статус;

• срок действия;

• версию;

• основание изменения;

• связанные приложения;

• спецификации;

• ответственного менеджера;

• историю согласований;

• подписанные файлы;

• дату подписания;

• архив старых версий.

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

Для первого релиза не всегда нужен сложный редактор договоров внутри веб-сервиса. Часто достаточно загрузки файлов, статусов, версий, комментариев и прав доступа. Генерацию шаблонов и электронное подписание можно добавлять позже, если процесс действительно этого требует.

Генерация PDF и шаблоны документов

Некоторые документы можно загружать вручную, а некоторые лучше формировать автоматически из данных системы. Например, счет, акт, заявка, спецификация, коммерческое предложение, отчет или подтверждение заказа.

Для генерации нужны:

• шаблон;

• данные клиента;

• реквизиты;

• позиции заказа;

• суммы;

• налоги;

• даты;

• номера;

• подписи и печати, если они используются;

• QR-код или ссылка, если нужны;

• правила округления;

• язык документа, если сервис международный;

• версия шаблона.

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

Если шаблон меняется, старые документы не должны внезапно "перерисовываться" по новой форме без истории. Для юридически и финансово значимых документов важно сохранять именно тот файл, который был выдан клиенту в конкретный момент.

Загрузка файлов пользователями

В веб-сервисах пользователи часто загружают документы сами: реквизиты, акты, договоры, сертификаты, фотографии, сканы, заявки, технические задания, отчеты, прайс-листы, доверенности или подтверждения.

Для загрузки нужно продумать:

• кто может загружать файлы;

• какие типы файлов разрешены;

• максимальный размер;

• количество файлов;

• обязательность файла;

• связь с заявкой, компанией или заказом;

• статус проверки;

• комментарий при отклонении;

• замену файла;

• хранение старой версии;

• уведомление ответственного;

• журнал загрузки.

OWASP отдельно выделяет риски unrestricted file upload: загруженные файлы могут создавать угрозы для сервера, клиентов, хранилища и конфиденциальных данных. Поэтому загрузку нельзя делать как простую публичную папку. Нужны ограничения расширений, проверка содержимого, лимиты размера, безопасные имена, хранение вне публичной директории, проверка прав и запрет выполнения загруженных файлов.

Безопасное хранение файлов

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

Безопасное хранение должно учитывать:

• приватное файловое хранилище;

• случайные технические имена;

• отсутствие исходного имени в публичном пути;

• проверку прав при скачивании;

• временные ссылки;

• ограничения срока действия ссылки;

• запрет индексации;

• резервное копирование;

• шифрование, если это требуется моделью риска;

• контроль удаления;

• журнал скачиваний.

Если документ скачивается через backend, сервер может проверить пользователя, компанию, роль, статус документа и связь с объектом. Если файл лежит напрямую в `/uploads/docs/contract.pdf`, такую проверку сделать нельзя. В B2B и SaaS это критично: один документ может принадлежать конкретной компании, филиалу, заказу или пользователю.

Роли и доступы к документам

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

Пример ролей:

• владелец компании;

• администратор компании;

• бухгалтер;

• закупщик;

• менеджер;

• технический специалист;

• сотрудник филиала;

• партнер;

• клиент;

• модератор;

• сотрудник поддержки платформы;

• системный администратор.

Бухгалтер может видеть счета и акты, но не видеть технические вложения. Технический специалист может видеть спецификации, но не финансовые документы. Менеджер платформы может видеть документы своих клиентов, но не все компании. Сотрудник филиала может видеть только документы своего филиала. Поддержка может видеть метаданные, но не иметь права скачивать чувствительный файл без причины.

Права нужно проверять на backend. Скрыть кнопку в интерфейсе недостаточно. Пользователь может попробовать открыть прямую ссылку, подставить ID документа или вызвать API напрямую. Эта логика тесно связана с темой мультиарендности в SaaS и B2B-сервисах.

Компании, филиалы и юридические лица

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

Нужно определить:

• кто является владельцем документа;

• к какой компании он относится;

• относится ли он к конкретному филиалу;

• какое юридическое лицо указано в документе;

• кто может видеть документ внутри клиента;

• кто может редактировать метаданные;

• кто может скачать файл;

• кто может заменить версию;

• кто может архивировать документ.

Если компания состоит из нескольких филиалов, документы могут иметь разные контуры доступа. Руководитель сети видит все. Администратор филиала видит только свой филиал. Бухгалтерия может видеть документы по всем юридическим лицам. Внешний подрядчик видит только документы, к которым его подключили.

Если эти правила не заложить в модель данных, потом придется переделывать не только интерфейс, но и API, хранение, отчеты, уведомления и импорт документов.

Документы в личном кабинете

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

В личном кабинете полезны:

• список документов;

• фильтры по типу;

• фильтры по статусу;

• поиск по номеру;

• дата документа;

• связанный заказ;

• сумма, если документ финансовый;

• статус оплаты;

• кнопка скачивания;

• комментарий менеджера;

• признак новой версии;

• уведомление о действии;

• история подписания или согласования.

Если документов много, нужны фильтры и поиск. Если клиент работает с несколькими компаниями, нужно переключение контекста. Если есть филиалы, нужно показывать принадлежность документа. Если документ требует действия, это должно быть видно: "подписать", "проверить", "заменить файл", "оплатить счет".

Материал логично связан со статьей Личный кабинет для клиентов и партнеров, но здесь акцент именно на документной части кабинета.

Документы в админ-панели

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

В админке нужны:

• список документов;

• фильтры по типу, статусу, компании, дате и ответственному;

• карточка документа;

• загрузка файла;

• генерация документа;

• замена версии;

• изменение статуса;

• отправка клиенту;

• комментарии;

• история событий;

• доступы;

• ошибки генерации;

• ручная повторная обработка;

• архив;

• экспорт списка.

Для финансовых и юридических документов действия должны быть защищены ролями. Не каждый менеджер должен отменять счет, заменять договор или удалять акт. Важные действия нужно логировать: кто сделал, когда, что изменил и почему.

Такая админка продолжает тему админ-панели для веб-сервиса, но с отдельной логикой для файлов, версий и статусов.

Согласование документов

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

Согласование может включать:

• автора;

• проверяющего;

• юридический отдел;

• бухгалтера;

• руководителя;

• клиента;

• срок;

• комментарии;

• возврат на доработку;

• новую версию;

• финальное утверждение.

Не всегда нужно строить сложный BPM-процесс. Иногда достаточно статусов, ответственного и комментариев. Но если согласование влияет на деньги или обязательства, нужны правила: кто может перевести документ в следующий статус, кто видит комментарии, что происходит при отклонении, можно ли менять файл после согласования.

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

Электронная подпись и юридическая значимость

Если веб-сервис должен не просто хранить документы, а обеспечивать юридически значимый электронный документооборот, нужно отдельно проектировать электронную подпись, идентификацию сторон, сертификаты, форматы, хранение подписанных файлов и правовую схему.

ФНС России указывает, что отношения в области применения электронной подписи регулируются Федеральным законом от 06.04.2011 № 63-ФЗ, а сам закон определяет понятие электронной подписи и ее виды: простая, усиленная неквалифицированная и усиленная квалифицированная. В материалах ФНС также отмечается, что квалифицированная электронная подпись применяется в юридически значимом электронном документообороте.

Для разработки это означает: нельзя обещать "электронную подпись как у всех" без юридической проработки. Нужно понять:

• какой вид подписи нужен;

• кто подписывает;

• как проверяется личность;

• где хранится подписанный файл;

• как фиксируется дата и время;

• как проверяется действительность подписи;

• нужны ли машиночитаемые доверенности;

• какие системы ЭДО участвуют;

• какие договоры и регламенты нужны.

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

Интеграция с 1С, CRM и ЭДО

Документы редко живут только в веб-сервисе. Счета, акты и договоры могут формироваться в 1С, CRM, ERP, системе ЭДО или бухгалтерском сервисе. Веб-сервис может быть витриной и кабинетом, а источником части документов остается учетная система.

Нужно определить:

• какая система является источником документа;

• где создается номер;

• где меняется статус;

• где хранится файл;

• кто может заменить документ;

• как часто идет синхронизация;

• что делать при ошибке обмена;

• как связывать документы с заказами и клиентами;

• какие внешние ID сохранять;

• какие события отправлять обратно.

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

Подробнее связь с учетными системами раскрыта в статье Интеграция сайта с 1С, а архитектурный слой интеграций - в статье Разработка платформы с API.

Импорт и экспорт документов

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

Для импорта нужно продумать:

• формат данных;

• связь файла с клиентом или заказом;

• правила именования;

• поиск дублей;

• проверку типа файла;

• размер;

• отчет об ошибках;

• очередь обработки;

• ручную проверку;

• откат или архивирование.

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

Экспорт должен учитывать права доступа. Если пользователь видит только один филиал, архив не должен включать документы всей компании. Общая логика массовых загрузок, очередей и отчетов раскрыта в статье Импорт и экспорт данных в веб-сервисе.

Поиск, фильтры и навигация по документам

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

Нужны:

• поиск по номеру;

• поиск по названию;

• фильтр по типу;

• фильтр по статусу;

• фильтр по компании;

• фильтр по договору;

• фильтр по заказу;

• фильтр по дате;

• фильтр по сумме;

• фильтр по ответственному;

• фильтр по филиалу;

• сортировка;

• быстрые вкладки.

Для клиента часто важны простые фильтры: "Счета", "Акты", "Договоры", "Требуют действия", "За период". Для администратора нужны более точные параметры: статус обработки, ошибка генерации, источник, автор, компания, внешний ID.

Если документ связан с несколькими сущностями, это нужно показывать в карточке: заказ, платеж, договор, клиент, заявка, филиал. Иначе пользователь скачивает файл, но не понимает, к чему он относится.

Уведомления о документах

Документооборот без уведомлений заставляет пользователей постоянно проверять кабинет вручную. Но уведомления должны быть привязаны к статусам и действиям.

Можно уведомлять о событиях:

• счет выставлен;

• счет просрочен;

• акт сформирован;

• договор ожидает согласования;

• документ подписан;

• документ отклонен;

• нужна новая версия;

• файл загружен клиентом;

• документ доступен для скачивания;

• ошибка генерации;

• срок действия договора скоро закончится.

Не нужно отправлять уведомления обо всем подряд. Если каждое техническое изменение статуса превращается в письмо, пользователь перестанет обращать внимание. Сервисные сообщения должны быть полезными: что произошло, к какому документу относится, что нужно сделать и где открыть файл.

Аудит действий

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

Журнал действий помогает:

• расследовать спорные ситуации;

• защищать коммерческие данные;

• контролировать работу сотрудников;

• проверять доступ поддержки;

• разбирать ошибки интеграций;

• готовить отчетность;

• понимать историю документа.

Аудит должен быть защищенным. Нельзя позволять обычному пользователю редактировать историю действий. Для чувствительных документов стоит хранить причину действия: например, почему поддержка открыла документ клиента или почему менеджер заменил файл после согласования.

Персональные данные и конфиденциальность

Документы могут содержать персональные данные: ФИО, телефон, email, паспортные сведения, адрес, подпись, реквизиты, сведения о заказах, платежах и договорных отношениях. Для российского бизнеса важно учитывать требования 152-ФЗ "О персональных данных": цели обработки, доступы, защита, хранение, политика и согласия, если они требуются конкретным процессом.

С технической стороны нужно минимизировать риски:

• не хранить лишние документы;

• ограничивать права;

• закрывать прямые ссылки;

• удалять временные файлы;

• контролировать экспорт;

• вести журнал скачиваний;

• не отправлять чувствительные файлы в общие чаты;

• не писать персональные данные в технические логи;

• ограничивать доступ сотрудников поддержки;

• хранить документы столько, сколько нужно бизнесу и закону.

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

Версии, архив и удаление

Удаление документов должно быть осторожным. Если документ связан с заказом, оплатой, договором или юридическим процессом, его нельзя просто стереть по кнопке без последствий.

Лучше использовать статусы:

• активен;

• заменен;

• архивирован;

• отозван;

• удален логически;

• удален физически по регламенту.

Версии помогают сохранять историю. Если договор заменили, старая версия может быть недоступна клиенту, но сохранена в архиве для внутренней проверки. Если счет отменили, он не должен пропасть из истории. Если файл загружен ошибочно, нужно понимать, кто и когда это сделал.

Физическое удаление может быть нужно по регламенту, политике хранения или запросу субъекта данных, если применимо. Но оно должно выполняться управляемо, с учетом резервных копий, связанных объектов и юридических ограничений.

Производительность и большие файлы

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

Нужно предусмотреть:

• лимит размера файла;

• лимит количества файлов;

• проверку типа;

• фоновую генерацию тяжелых PDF;

• очереди для массовых операций;

• прогресс обработки;

• безопасное скачивание;

• временные ссылки;

• сжатие или предпросмотр, если нужно;

• удаление временных файлов;

• мониторинг хранилища.

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

Ошибки документооборота

Документы часто ломаются не потому, что файл не скачался, а потому что бизнес-данные неверные.

Типичные ошибки:

• неверные реквизиты;

• неправильная сумма;

• старая версия договора;

• документ виден не той компании;

• файл лежит по публичной ссылке;

• акт сформирован не за тот период;

• счет не связан с платежом;

• статус документа не совпадает со статусом заказа;

• клиент получил документ без доступа;

• PDF сформировался без части данных;

• интеграция с 1С не передала файл;

• уведомление ушло без вложения или с неверной ссылкой.

Для таких случаев нужны логи, понятные статусы и ручные инструменты. Администратор должен видеть, что именно не получилось: ошибка шаблона, нет данных, недоступна 1С, файл не прошел проверку, нет прав, внешний ID не найден.

Что включить в первый релиз

Первый релиз документооборота не обязан быть сложной системой ЭДО. Важно закрыть основной процесс и не заложить опасных упрощений.

Для MVP часто достаточно:

• типы документов;

• загрузка файлов;

• список документов;

• карточка документа;

• связь с компанией, заказом или договором;

• базовые статусы;

• права доступа;

• скачивание через backend;

• история действий;

• уведомления по ключевым событиям;

• админ-панель;

• простая генерация PDF, если она критична;

• интеграция с 1С или ручная загрузка, если учетная система пока не подключена.

Электронную подпись, сложное согласование, массовые архивы, автоматическую сверку, редактор шаблонов, полноценный ЭДО и расширенную аналитику можно добавлять позже. Но безопасность файлов, права доступа, связь документа с бизнес-сущностью и история действий должны быть в основе с первого релиза.

Как тестировать документооборот перед запуском

Документы нужно тестировать не только по кнопке "Скачать". Нужно проверить весь сценарий: создание, данные, статус, доступ, файл, уведомление и историю.

Минимальный чек-лист:

• загрузка разрешенного файла;

• отказ файла запрещенного типа;

• лимит размера;

• генерация PDF;

• корректность реквизитов;

• корректность суммы;

• связь с заказом;

• связь с компанией;

• доступ клиента;

• запрет доступа чужой компании;

• доступ разных ролей;

• скачивание через backend;

• прямой URL не открывает файл без прав;

• замена версии;

• архивирование;

• изменение статуса;

• отправка уведомления;

• ошибка интеграции;

• повторная обработка;

• экспорт списка документов;

• аудит действий.

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

Частые ошибки при разработке документооборота

Первая ошибка - считать документ просто файлом. Без типа, статуса, владельца и истории файл не становится частью бизнес-процесса.

Вторая ошибка - хранить документы в публичной папке. Для B2B, SaaS и личных кабинетов скачивание должно проходить через проверку прав.

Третья ошибка - не делать версии. Замена договора или счета без истории создает риск споров.

Четвертая ошибка - смешивать статусы документов, заказов и платежей. Они связаны, но не равны.

Пятая ошибка - давать всем пользователям компании доступ ко всем документам. Даже внутри одной организации нужны роли.

Шестая ошибка - не логировать скачивание и замену файлов. Для документов история действий часто важна не меньше самого файла.

Седьмая ошибка - обещать юридически значимый ЭДО без проработки подписи, идентификации и правовой схемы.

Восьмая ошибка - не тестировать данные внутри PDF. Файл может скачиваться, но содержать неправильную сумму или реквизиты.

Как описать документооборот в ТЗ

Чтобы получить точную оценку разработки, нужно описать не "раздел документов", а конкретные процессы.

В ТЗ стоит указать:

• какие типы документов нужны;

• кто создает документы;

• какие документы загружаются вручную;

• какие формируются автоматически;

• какие приходят из 1С, CRM или ЭДО;

• какие статусы есть у каждого типа;

• кто видит документы;

• кто может скачать;

• кто может заменить файл;

• нужны ли версии;

• нужны ли согласования;

• нужна ли электронная подпись;

• какие уведомления нужны;

• какие документы связаны с платежами;

• какие документы связаны с заказами;

• нужен ли экспорт;

• какие файлы разрешены;

• какие лимиты по размеру;

• какие действия логируются;

• какие сценарии должны быть в первом релизе.

Такое описание помогает точнее оценить сроки и не перепутать простой файловый раздел с полноценным документооборотом. Общие принципы подготовки требований есть в статье Как подготовить техническое задание на разработку.

Как Wcoders подходит к документообороту

Для Wcoders документооборот в веб-сервисе - это часть операционной архитектуры. Сначала нужно понять, какие документы участвуют в процессе, кто их создает, какие статусы важны, как они связаны с клиентом, заказом, оплатой, договором, 1С, CRM и личным кабинетом.

После этого проектируются:

• модель документа;

• типы документов;

• статусы;

• версии;

• права доступа;

• хранение файлов;

• генерация PDF;

• загрузка и проверка файлов;

• личный кабинет;

• админ-панель;

• интеграции;

• уведомления;

• аудит;

• тестовые сценарии.

Такой подход помогает не раздувать первый релиз, но заложить надежный фундамент. Можно начать с загрузки, списка документов, статусов и прав доступа, а потом добавить генерацию, согласование, ЭДО, массовые операции и аналитику. Главное - с самого начала относиться к документу как к бизнес-сущности, а не как к случайному файлу в папке.

Связанный пример из портфолио

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

FAQ

Можно ли начать с простого раздела "Документы"?

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

Нужно ли генерировать PDF автоматически?

Не всегда. Если документов мало или они готовятся в 1С, CRM или бухгалтерии, можно начать с ручной загрузки. Автоматическая генерация нужна, когда документы создаются часто и строятся по понятным шаблонам.

Чем документ отличается от файла?

Файл - это содержимое. Документ - это бизнес-объект: тип, номер, дата, статус, версия, владелец, права, связь с заказом или договором, история действий и один или несколько файлов.

Нужно ли делать электронную подпись в первом релизе?

Только если она нужна бизнес-процессу и юридическая схема уже понятна. Во многих MVP достаточно хранить статусы, файлы и вручную загружать подписанную версию. Полноценную ЭП и ЭДО лучше проектировать отдельно.

Как защитить документы от доступа чужих пользователей?

Файлы нужно хранить приватно, а скачивание проводить через backend с проверкой пользователя, компании, роли, статуса и связи документа с объектом. Прямые публичные ссылки для чувствительных документов опасны.

Нужны ли версии документов?

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

Какие документы чаще всего нужны в B2B-кабинете?

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

Что важнее: интеграция с 1С или удобный кабинет документов?

Это разные уровни. 1С может быть источником счетов и актов, а кабинет - удобным интерфейсом для клиента. Если интеграция пока не готова, можно начать с ручной загрузки, но модель документа лучше сразу сделать совместимой с будущим обменом.

Итог

Система документооборота в веб-сервисе нужна, когда документы становятся частью регулярной работы: счета, акты, договоры, спецификации, файлы, статусы, согласования, доступы и история действий. Это не папка с PDF, а отдельный слой продукта, который связывает клиента, менеджера, бухгалтерию, заказ, оплату, 1С, CRM и личный кабинет.

Надежный документооборот начинается с модели: какой это документ, кому он принадлежит, в каком статусе находится, какая версия актуальна, кто может его видеть, кто может заменить, где хранится файл и какие действия уже произошли. Без этой модели документы быстро уходят в ручные переписки и становятся источником ошибок.

Если сделать документооборот правильно, веб-сервис становится полезнее для бизнеса и клиента: документы не теряются, доступы контролируются, статусы понятны, история сохраняется, а команда перестает зависеть от ручной отправки файлов и просьб "найти тот самый акт".