Как создать веб-приложение для бухфирмы: клиенты и сроки

Цели продукта и сценарии работы бухгалтерской фирмы

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

Какие задачи приложение должно закрыть

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

2. Документы: запросы на недостающие файлы, хранение и быстрый поиск, контроль версий (чтобы «последняя_финал2.xlsx» не становилась нормой).

3. Сроки и обязательства: календарь отчётности и платежей, напоминания, контроль просрочек, понимание «что горит сегодня» на уровне команды и руководителя.

Для кого продукт (и какие сценарии важны)

Руководитель видит загрузку, риски по срокам и качество сервиса (где клиенты «зависают»).

Бухгалтер работает по понятному списку задач: запросил документы → получил → подготовил отчёт → отправил → зафиксировал результат.

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

Клиент (портал) загружает документы, видит список запросов и ближайшие дедлайны без лишних писем и мессенджеров.

Показатели успеха

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

Границы проекта: что не делаем в первой версии

Чтобы объём не расползался, в MVP обычно не включают: полноценное ведение бухгалтерии внутри системы (проводки/расчёт зарплаты), сложную аналитику, кастомные отчёты «под каждого», встроенный ЭДО/подпись. Первая версия должна прежде всего навести порядок в сервисе: клиенты → документы → сроки → ответственность.

Пользователи и ключевые сценарии: от онбординга до сдачи отчётов

Прежде чем рисовать экраны и выбирать стек, важно договориться: для кого именно вы делаете веб‑приложение и какие повторяющиеся «истории» оно должно закрывать. У бухфирм обычно 4 роли, и у каждой — своя мотивация и свои боли.

Роли и потребности

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

Руководитель смотрит на загрузку команды, риски просрочек и качество сервиса: где затыки, кто перегружен, какие клиенты «тянут» больше всего.

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

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

Типовые сценарии, которые стоит поддержать в MVP

Онбординг клиента: создание карточки, выбор набора услуг, назначение ответственных, стартовый список документов.

Запрос документов: сформировать запрос (лучше из шаблона), поставить срок, получить загрузку в привязке к запросу, напомнить при задержке.

Закрытие периода: собрать первичку, сверить оплаты/акты, зафиксировать «период закрыт», оставить комментарии и решения по спорным операциям.

Сдача отчётности: календарь дедлайнов, контроль готовности, отметка «сдано/принято», хранение квитанций и версий файлов.

Главные боли пользователей

Хаос в файлах (разные папки, дубли, непонятные версии), бесконечные переписки в мессенджерах, «потерянные» просьбы и забытые сроки — всё это превращается в стресс и штрафные риски.

Как собирать требования без лишней теории

Проведите 6–10 коротких интервью по ролям и разберите 10–20 последних реальных кейсов: где возникала задержка, какой документ искали, какое решение принимали.

Затем соберите карту процесса «как есть»: шаги, участники, входы/выходы, точки контроля. Это даст понятный список экранов и статусов — основу для прототипов и ТЗ.

Модель данных: клиенты, компании, документы и сроки

Правильная модель данных — это «скелет» продукта: если связи между клиентом, задачами, документами и сроками заданы ясно, команда меньше спорит, а пользователи быстрее находят нужное.

Базовые сущности

В MVP обычно достаточно следующих объектов:

• Клиент (контактное лицо, каналы связи, ответственный менеджер).
• Компания (ООО) / ИП (реквизиты, система налогообложения, регион, доступы).
• Договор (номер, дата, срок, файл-скан, привязка к клиенту и компании).
• Услуга/тариф (что делаем регулярно: бухучёт, зарплата, отчётность; периодичность; SLA).
• Задача (кто делает, что именно, чек‑лист, связанный документ/дедлайн).
• Документ (тип, период, источник: клиент/внутренний, статус, версия).
• Дедлайн (дата/время, тип: отчёт/оплата/запрос, ответственность).

Связи и статусы: кто что должен

Ключевая цепочка выглядит так: клиент ↔ компания ↔ услуги ↔ задачи ↔ документы ↔ дедлайны. Например, «Сдать РСВ за Q3» — это дедлайн, к нему привязаны задачи («собрать данные», «сформировать отчёт», «отправить»), а задачи требуют документы (выгрузки, первичка).

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

Версии, комментарии, теги и поиск

Документу нужны версии (v1, v2…), комментарии (почему заменили), теги (налоги, зарплата, банк) и поля для поиска: тип, период, компания, автор загрузки. Это позволяет искать не «по папкам», а по смыслу.

История изменений (аудит)

Фиксируйте события: кто и когда загрузил, переименовал, сменил статус, согласовал, удалил/восстановил. Такой журнал решает споры, упрощает контроль качества и помогает разбирать инциденты без лишних переписок.

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

Когда у бухфирмы десятки компаний на обслуживании, «память команды» быстро превращается в риск. Поэтому управление клиентами стоит строить вокруг понятной карточки и прозрачных статусов — так меньше ручных уточнений и проще контролировать качество.

Единая карточка клиента

Карточка — это одно место, где собраны контакты, реквизиты, договорные условия и услуги (тариф, состав работ, дополнительные поручения). Сюда же удобно добавлять историю обращений: что запросили, чем закончилось, кто отвечал.

Важно, чтобы данные были структурированы (поля), а не только в комментариях — тогда их можно фильтровать и использовать в отчётах.

Списки клиентов с фильтрами

Список клиентов должен быть рабочим инструментом, а не справочником. Минимально нужны фильтры:

• по ответственному (кто ведёт клиента сейчас)
• по статусу (лид/в онбординге/активен/на паузе/закрыт)
• по сегменту (ИП/ООО, отрасль, тариф)
• по рискам (частые просрочки, нет документов, конфликтные коммуникации)

Так руководитель быстро понимает нагрузку, а бухгалтер — приоритеты дня.

Шаблоны онбординга

Онбординг лучше делать шаблонами: чек‑лист документов, стандартные задачи, типовые сроки. Выбираете «шаблон обслуживания» — система сама создаёт нужные пункты и напоминания. Это снижает зависимость от конкретного сотрудника и ускоряет старт работы.

Импорт/экспорт для отчётности

Даже в MVP полезны базовые выгрузки: список клиентов с ключевыми полями, статусами и ответственными — для отчёта руководителю или сверки. А импорт помогает быстро перенести стартовую базу без ручного ввода и ошибок.

Документы: хранение, версии, запросы и быстрый поиск

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

Структура хранения: меньше папок, больше смысла

Базовая схема понятна всем: клиент → период → тип документа (например, «ООО Ромашка → 2025-1кв → Банк/Счета/Кадры»).

Но вместо разрастания вложенных папок выгоднее опираться на теги: «первичка», «исправление», «срочно», «для проверки». Теги помогают строить выборки без «археологии» в дереве папок.

Запрос документов у клиента

Запрос должен занимать минуту: бухгалтер создаёт запрос, система формирует ссылку на загрузку или короткую форму в клиентском портале.

Важно предусмотреть ограничения: допустимые типы файлов, максимальный размер, запрет на исполняемые форматы, подсказки «что именно нужно». Хорошая практика — шаблоны запросов (например, «закрытие месяца»), чтобы не писать одно и то же.

Версии и контроль качества

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

На статус «принято» можно повесить чек‑лист (например, «есть подпись», «совпадают суммы», «период верный») и обязательные поля.

Поиск и быстрый доступ

Поиск должен работать по названию, тегам, типу документа, периоду, статусу и ответственному. Для скорости нужны «Избранное», «Последние файлы» и сохранённые фильтры (например, «нужны правки за текущий месяц»).

Политика хранения и удаления

Заранее задайте сроки хранения по типам документов и принцип «минимально необходимого». Доступ — по ролям (кто видит, кто скачивает, кто удаляет), а любые действия — в журнале. Это снижает риски и упрощает внутренние проверки.

Дедлайны и календарь: контроль сроков без просрочек

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

Какие сроки учитывать

Минимальный набор типов дедлайнов:

• Отчётность (декларации, расчёты, статистика) — периодические и предсказуемые.
• Платежи (налоги, взносы) — часто требуют ранних внутренних дат «на подготовку».
• Ответы на требования — нерегулярные, с жёсткими датами и высоким риском.
• Внутренние дедлайны — контрольные точки внутри фирмы: «получить первичку», «сверить обороты», «согласовать с клиентом».

Откуда берётся дедлайн

Практично поддержать три источника:

1. Ручной — сотрудник создал срок из карточки клиента/компании.

2. По шаблону услуги — например, услуга «УСН: ежеквартальная отчётность» автоматически создаёт даты на год вперёд.

3. Из календаря периодов — централизованный справочник периодов и правил (месяц/квартал/год), чтобы при смене периода система пересчитывала будущие сроки без хаоса.

Напоминания и эскалации

Срок работает только если понятно: кому, когда и что делать при просрочке. Настройте цепочку: уведомление ответственному → напоминание руководителю группы → эскалация партнёру/админу, плюс обязательный комментарий «почему просрочено».

Панели контроля

Для ежедневной работы нужны простые виды: «сегодня / неделя / месяц», отдельные фильтры «просроченные» и «критичные» (например, осталось меньше N дней). Важно, чтобы руководитель видел нагрузку по сотрудникам и клиентам.

Связь с задачами и документами

Дедлайн не должен закрываться «галочкой». Правило: закрытие возможно только при выполненных задачах и подтверждениях — например, загружен финальный файл отчёта, есть отметка «отправлено» и прикреплена квитанция/подтверждение. Так сроки превращаются из календаря в управляемый процесс.

Задачи и рабочие процессы: кто что делает и когда

Чтобы приложение реально снимало хаос, «задача» должна быть не просто напоминанием, а единым контейнером работы: что сделать, кому, к какому сроку, какие документы нужны и какой следующий шаг.

Какие задачи нужны в бухфирме

Минимальный набор видов задач стоит заложить сразу, чтобы не превращать систему в универсальный «список дел»:

• запрос документов у клиента (с перечнем и сроком ответа)
• подготовка отчёта/декларации (с этапами)
• согласование с клиентом (что именно согласуем)
• оплата/счёт/акт (контроль оплаты и закрывающих)
• консультация (запрос, итог, фиксация договорённостей)

Ответственные, наблюдатели и контекст

У задачи должен быть один ответственный — тот, кто ведёт её до результата. Плюс наблюдатели: руководитель группы, менеджер клиента, юрист/кадровик по необходимости.

Чек‑листы помогают не забыть мелочи (например: «проверить ОКВЭД», «сверить ИНН/КПП», «сформировать квитанции»). Комментарии и упоминания (@) заменяют переписку в мессенджерах и сохраняют историю решений прямо рядом с делом.

Шаблоны и повторяемость

Повторяющиеся задачи — сердце бухгалтерского сервиса. Удобно заводить шаблоны по услуге (например, «УСН квартал»), по типу клиента и по периоду. Из шаблона автоматически создаются задачи на месяц/квартал с уже назначенными ролями, чек‑листом и типовыми сроками.

Статусы и простые правила

Чтобы команда одинаково понимала прогресс, задайте понятные статусы:

• «Новая» — ещё не взяли в работу
• «В работе» — выполняем, всё необходимое есть
• «На ожидании» — ждём клиента/банк/ФНС, срок ответа фиксирован
• «Готово» — результат передан, следующий шаг понятен

Важно: «На ожидании» должно требовать причину и дату, когда вернёмся.

Отчётность для руководителя

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

Безопасность и доступы: роли, аудит и защита данных

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

Роли и права: доступ «по минимуму»

Продумайте матрицу доступов сразу в разрезе:

• по клиентам/компаниям (сотрудник видит только «свои» организации или закреплённый пул);
• по типам документов (например, первичка, кадровые, банковские, доверенности);
• по действиям: просмотр, загрузка, скачивание, удаление, изменение статусов, выдача доступов.

Важно разделить «бухгалтер может работать с документами» и «администратор может управлять доступами» — это разные риски.

Безопасный вход и управление сессиями

Минимальный набор: 2FA, политика паролей, журналы входов (дата, устройство, IP), а также управление сессиями — возможность принудительно завершить активные сессии при увольнении, смене пароля или подозрительной активности.

Шифрование и хранение

Закладывайте шифрование при передаче (TLS) и при хранении: данные в базе, файлы, резервные копии. Для файлов отдельно определите, где они лежат (объектное хранилище/сервер), как ограничивается прямой доступ и как реализована безопасная ссылка на скачивание.

Логи и аудит: кто сделал действие

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

Что прописать в требованиях: соответствие и риски

В ТЗ зафиксируйте: модель ролей, требования к 2FA, сроки хранения логов, RPO/RTO для резервного копирования, процедуру реагирования на инциденты, а также требования к персональным данным (например, 152‑ФЗ и, при необходимости, локализация хранения). Формулируйте честно: не «абсолютная защита», а измеримые меры и зоны ответственности.

Клиентский портал: самообслуживание без лишних переписок

Клиентский портал — это «витрина» вашей работы для клиента и одновременно способ разгрузить команду от бесконечных писем и уточнений. Хороший портал не пытается заменить бухгалтерию: он даёт клиенту понятные действия и понятный прогресс.

Минимальный кабинет: только то, что нужно каждый месяц

В первой версии достаточно трёх экранов:

• Загрузка документов: перетаскивание файлов, понятные подсказки «что именно нужно», история загрузок.
• Статусы задач: «нужно от клиента → в работе → на согласовании → готово». Важно, чтобы статусы были одинаковыми для всех услуг.
• Календарь запросов: список ближайших запросов и сроков (например, «до 20 числа — прислать выписку»). Это снижает риск просрочек из‑за молчания клиента.

Коммуникации: комментарии и уведомления вместо цепочек писем

Лучший формат — комментарии прямо в задаче или документе: клиент видит вопрос и отвечает в том же месте. Уведомления отправляйте на email, но без дублирования всего текста переписки — достаточно ссылки на конкретную задачу в портале.

Чтобы экономить время, добавьте шаблоны сообщений: «Не хватает счёта», «Нужна выписка за период», «Проверьте реквизиты». Клиент получает короткий текст и чёткое действие.

Согласование и прозрачность: что можно подтверждать

На этапе «на согласовании» дайте кнопки: «Подтверждаю» / «Нужны правки» с обязательным комментарием при отказе. Полезны отметки «получено» и дата подтверждения — это дисциплинирует обе стороны.

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

Интеграции и миграция: как подключать без срыва работы

Интеграции дают эффект, только если не ломают текущий ритм работы. Поэтому полезно разделить запуск на два этапа: сначала — стабильный MVP с ручными операциями, затем — подключение внешних сервисов там, где это реально экономит время.

Интеграции первого уровня (самые «безопасные»)

1. Email: привязка корпоративных ящиков, чтобы письма клиента автоматически попадали в карточку и не терялись.

2. Календарь: синхронизация дедлайнов и встреч (двусторонняя или хотя бы выгрузка событий). Так команда видит сроки в привычном инструменте.

3. Облачное хранилище: подключение папок клиента/компании для быстрого доступа к первичным документам и актам.

4. Электронная подпись (если нужно): подключайте, когда у вас уже выстроены шаблоны документов и маршрут согласования. Иначе вы автоматизируете хаос.

Импорт данных: как мигрировать без боли

Начните с минимального набора, который позволит работать «с понедельника»: клиенты и компании, договоры/тарифы, открытые задачи и ближайшие сроки.

Исторические документы лучше мигрировать выборочно: например, «текущий год + важные договоры», остальное — по запросу.

Практика: сначала делайте пробный импорт на 20–50 клиентов, фиксируйте правила сопоставления полей, затем запускайте основной.

События и webhooks: что отдавать наружу

Набор событий, который обычно покрывает 80% потребностей: создан документ, запрошен документ у клиента, изменён статус клиента/задачи, изменён дедлайн, добавлен комментарий, закрыт период. Это позволяет строить уведомления, BI-отчёты и интеграции без прямого доступа к базе.

Когда лучше стартовать без интеграций

Если команда ещё не согласовала статусы, шаблоны запросов и «кто за что отвечает», интеграции будут только мешать. На первом релизе допустимо ограничиться экспортом (CSV/Excel) и ручной загрузкой файлов — главное, чтобы core-функции работали быстро и предсказуемо.

MVP и приоритизация: что сделать в первой версии

MVP — это не «урезанная система», а минимальный набор функций, который за 4–8 недель позволяет проверить ценность: бухгалтеры реально ведут клиентов и сроки внутри продукта, а не возвращаются в таблицы и мессенджеры. Важно сразу выбрать один главный поток работы и довести его до конца.

Что включить в MVP за 4–8 недель

Фокусируйтесь на цепочке «клиент → документы → срок → напоминание → результат». Обычно достаточно:

• список клиентов и простая карточка (контакты, ответственный, статус);
• реестр документов с загрузкой/скачиванием и привязкой к клиенту;
• дедлайны по типовым задачам (отчётность, сверки) с календарём;
• уведомления (почта/внутренние) о приближении сроков;
• минимальные роли: админ и сотрудник.

Если важно быстро дойти до работающего пилота, стоит рассмотреть подход vibe‑coding. Например, в TakProsto.AI можно собрать такой MVP через чат: описать роли, статусы, сущности и ключевые экраны — и получить основу веб‑приложения на React с бэкендом на Go и PostgreSQL, с экспортом исходников, снапшотами и откатом. Это удобно, когда нужно проверить процесс на 3–5 клиентах до того, как вкладываться в долгий цикл разработки.

Приоритизация: MoSCoW и RICE простыми словами

MoSCoW: Must (без этого не работает), Should (сильно помогает), Could (приятно иметь), Won’t (точно не делаем сейчас). Для MVP большинство пунктов должны быть Must.

RICE помогает сравнить идеи цифрами: Reach (скольких затронет), Impact (насколько улучшит), Confidence (уверенность), Effort (затраты). Берите в спринт то, что даёт высокий эффект при низких усилиях.

Критерии готовности к пилоту

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

Риски, которые чаще всего «ломают» сроки

1. Права доступа (слишком сложная матрица ролей).

2. Документы (версии, большие файлы, хаос в названиях).

3. Уведомления (не приходят, приходят не вовремя, нет часовых поясов).

Эти зоны стоит проверить первыми на пилотной группе.

Прототипы, UX и ТЗ: как описать продукт без лишней сложности

Хороший продукт для бухфирмы начинается не с длинного документа, а с понятных прототипов и правил. Задача — быстро согласовать, «как это будет работать», чтобы команда разработки не додумывала за вас.

Какие экраны стоит прототипировать в первую очередь

Достаточно простых вайрфреймов (серых схем) с реальными полями и примерами:

• Список клиентов: поиск, фильтры по статусам, индикаторы «есть запрос/есть просрочка», быстрые действия.
• Карточка клиента/компании: контакты, ответственные, статусы, история взаимодействий, блок «что нужно от клиента».
• Документы: категории, версии, «запросить документ», отметка «получено/неполное», быстрый поиск.
• Календарь/сроки: сроки по клиенту и по команде, приоритет, напоминания.
• Задачи: кому назначено, дедлайн, чек‑лист, комментарии.
• Портал клиента: что клиент видит и делает сам (загрузить, ответить, подтвердить).

Требования к удобству (UX), которые лучше зафиксировать заранее

Опишите 5–7 принципов: минимум кликов до результата, единые статусы во всех разделах, подсказки рядом со сложными полями, понятные тексты ошибок («что произошло и что делать»), предсказуемая навигация и единый поиск.

Мобильный доступ: что обязательно

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

Как собрать ТЗ без перегруза

Структура, которой обычно достаточно:

1. Пользовательские истории (кто, что делает, зачем) + критерии готовности.

2. Макеты с подписью элементов и переходов.

3. Бизнес‑правила: статусы, сроки, кто может менять/видеть, что считается просрочкой.

4. Примеры данных: 2–3 клиента, набор документов, типовые ошибки и исключения.

Такое ТЗ легко уточнять итерациями и проверять на пилоте — без сотен страниц текста.

Запуск, пилот и развитие: как внедрить и не перегрузить команду

Запуск веб‑приложения для бухфирмы — это не «включили и работаем», а аккуратное внедрение, где важно сохранить текущий темп сдачи отчётности. Лучший подход — маленькими шагами, с понятными критериями успеха.

Перед запуском: минимальный набор тестов

Проведите короткое приемочное тестирование на реальных данных (без «идеальных» кейсов). В чек‑лист стоит включить:

• роли и права (кто видит клиентов/документы/финансы, кто может удалять);
• загрузку больших файлов и ограничения (время, обрыв соединения, повторная загрузка);
• поиск (по названию, ИНН, периоду, тегам, содержимому заметок);
• напоминания и эскалации (письма/уведомления, «просрочено», повторные напоминания);
• отчёты (хотя бы базовые: статус клиентов, просрочки, загрузка сотрудников).

Пилот на 3–5 клиентах

Выберите разных по типу клиентов (ИП/ООО, разные режимы, «много документов» и «мало документов»). Собирайте обратную связь по двум каналам: короткая форма после ключевых действий и еженедельный созвон на 20 минут.

Что измерять: время онбординга, долю задач «в срок», количество ручных напоминаний, число уточняющих сообщений от клиентов, скорость поиска документа.

Обучение команды без длинных инструкций

Сработают «микро‑материалы»: 3–5 регламентов на одну страницу, короткие видео на 2–3 минуты и шаблоны процессов (например, «квартальная отчётность», «восстановление учёта»).

Поддержка и развитие

Заведите единый бэклог запросов, план релизов раз в 2–4 недели и правило контроля качества данных (обязательные поля, единые статусы, регулярная сверка просрочек).

Следующие шаги (чек‑лист)

Определите владельца продукта, выберите пилотных клиентов, утвердите метрики, назначьте дату ретро через 2 недели, подготовьте материалы обучения и канал поддержки. Нужна помощь с планом внедрения или оценкой работ — напишите через /contact или посмотрите варианты на /pricing. "}