Веб-приложение для учёта корпоративных подарков: план

Какая проблема у учёта корпоративных подарков

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

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

Excel ломается по предсказуемым причинам. Файлы начинают жить в копиях, правки не видны всем сразу, формулы случайно стирают. Ручной ввод даёт разные форматы адресов и сумм. Даже если настроить доступы, остаются человеческие ошибки: кто-то забывает обновить статус, кто-то меняет стоимость «на глаз», кто-то удаляет строку вместо того, чтобы отменить отправку.

Обычно в процессе участвуют разные роли, и у каждой своя зона ответственности:

• HR: список получателей, поводы, комментарии и коммуникация.
• Офис-менеджер/логистика: закупка, упаковка, отправка, контроль статусов.
• Бухгалтерия/финансы: лимиты, счета, чеки, закрывающие документы.
• Подрядчик: доставка, трек-номера, подтверждение вручения.

Важно контролировать не только «отправили или нет». Нужны дедлайны (успеть к дате), бюджетные лимиты (по человеку, по отделу, по кампании) и подтверждение получения. Типичная ситуация: к празднику отправили 120 подарков, 15 адресов поменялись, по 8 доставкам нет статуса, а бюджет внезапно «перелетел» из-за срочной замены позиций. В этот момент становится понятно, зачем нужно веб-приложение для учёта корпоративных подарков: всё хранится в одном месте и обновляется по правилам, а не по настроению автора таблицы.

Какие сущности нужны: получатели, кампании, отправки, бюджет

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

1) Справочник получателей

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

Минимальный набор:

• Получатель: ФИО, подразделение, роль (сотрудник, партнёр), телефон, примечания.
• Адрес: город, улица, индекс, комментарий для курьера (например, домофон).
• Кампания: повод (8 марта, онбординг), сроки, ответственный, правила участия.
• Отправка: способ (курьер, почта, самовывоз), трек-номер, статус, даты (создана, отправлена, доставлена), комментарий.
• Финансы: план (лимит), факт (затраты), документы (счёт, чек), возвраты и пересылка.

2) Как эти сущности связать

Связи лучше продумать сразу, иначе статусы и деньги начнут расходиться.

Обычно работает такая логика:

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

Пример: к Новому году вы создали кампанию на 200 000 руб., добавили 120 получателей и запланировали доставку курьером. По мере отправок статусы меняются, трек-номера фиксируются, а фактические траты растут: стоимость подарка, доставка, иногда пересылка. Если посылка вернулась, запись не «перетирают». Добавляют событие возврата и создают новую отправку - тогда бюджет посчитается правильно.

Статусы и история: как не запутаться

Главный источник путаницы - когда статус меняют «на словах», а потом никто не помнит, что именно произошло и почему. Для каждой отправки нужен простой статус, понятный всем, и история изменений: кто поменял, когда и с каким комментарием.

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

Кто меняет статус и что записывать

Задайте правило: статус меняет только тот, кто получил подтверждение. Например, «Отправлено» ставит сотрудник, который оформил заказ, а «Доставлено» - тот, кто увидел подтверждение от курьера или получателя. При нестандартных ситуациях (задержка, отказ, неверный адрес) нужен комментарий.

Полезный минимум для истории:

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

Временные метки и доказательства

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

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

Бюджет и лимиты: что считать и как проверять

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

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

Что включать в стоимость, чтобы контроль был честным:

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

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

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

Пример: на 8 марта вы поставили лимит кампании 300 000 ₽ и по 3 000 ₽ на человека. Для одного получателя доставка в удалённый город добавила 1 200 ₽, и итог превысил лимит. Система блокирует отправку, вы добавляете комментарий «срочная доставка, адрес подтверждён», руководитель отмечает «согласовано», и перерасход попадает в отчёт.

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

Как должен выглядеть интерфейс для ежедневной работы

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

Основные списки и навигация

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

Полезны сохранённые представления: «К отправке сегодня», «Ожидаем трек-номер», «Вернулось на склад», «Нужна проверка адреса». Тогда меньше ручной сортировки.

Поиск, фильтры и быстрые карточки

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

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

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

Уведомления и напоминания

Уведомления должны приходить не всем подряд, а тем, кто реально может решить проблему. Например: ответственному - если статус не менялся 3 дня; руководителю - если просрочено больше N отправок; финансовому контролёру - если кампания приближается к лимиту бюджета.

Пример: менеджер запускает кампанию «8 Марта», импортирует 120 адресов, фильтрует «без квартиры», массово ставит статус «нужна уточняющая информация» и назначает ответственную HR. Через день HR закрывает карточки, а система напоминает логисту, что 15 отправок всё ещё без трек-номера.

Пошагово: собираем трекер через AI-кодинг

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

1) Начните с простого описания данных и правил

Запишите, как будто объясняете коллеге: кто получатели, что такое кампания, что считается отправкой, какие суммы можно вводить. Пример формулировок:

• «Получатель: ФИО, компания/подразделение, адрес, телефон, комментарий, признак “важный клиент”»
• «Кампания: название, дата старта, бюджет, ответственный, статус (черновик/в работе/закрыта)»
• «Отправка: получатель + кампания, тип подарка, сумма, статус доставки, трек-номер, дата отправки»

Дальше уточните связи и ограничения: один получатель участвует в нескольких кампаниях, у кампании много отправок. Отдельно проговорите уникальность (например, один и тот же получатель не должен появляться в кампании дважды).

2) Соберите минимальные экраны для ежедневной работы

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

3) Добавьте проверки, чтобы данные не «плыли»

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

• обязательные поля (ФИО, адрес, кампания);
• запрет отрицательных сумм;
• контроль лимита бюджета кампании;
• запрет переводить кампанию в «закрыта», если есть отправки без финального статуса.

4) Прогоните сценарии на маленьком наборе

Перед запуском заведите 10-20 получателей и проверьте реальные действия:

• создать кампанию, добавить отправки, поменять статусы;
• попытаться превысить бюджет и увидеть понятную ошибку;
• исправить адрес и убедиться, что история сохранилась;
• сделать снапшот перед правками и откатиться при ошибке.

После этого уже имеет смысл добавлять роли доступа и более сложные отчёты.

Безопасность и доступы: персональные данные без лишнего риска

В таком приложении почти всегда хранятся персональные данные: ФИО, адрес доставки, телефон, иногда комментарии курьера. Это чувствительная часть проекта. Проще сразу заложить понятные правила, чем потом разбирать последствия.

Права доступа: адреса и финансы не для всех

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

Практичный минимум:

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

Минимизация данных: храните только то, что реально нужно

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

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

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

Частые ошибки и ловушки в учёте подарков

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

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

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

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

Набор правил, который ловит большинство ошибок:

• разделяйте кампании (у каждой отправки есть кампанийный ID и период);
• держите единый справочник получателей и не разрешайте «свободный ввод» адреса без проверки;
• ведите историю статусов и требуйте комментарий при правках задним числом;
• считайте полную себестоимость: подарок + доставка + упаковка + прочие расходы;
• включите проверку лимита: предупреждение до подтверждения заказа и блокировку при превышении.

На практике это выглядит так: менеджер добавляет ещё 20 отправок, а система сразу показывает, что с доставкой бюджет уже превышен на 12%. Это лучше, чем узнавать об этом после выставленного счёта.

Быстрый чеклист перед запуском

Перед тем как отдавать приложение в работу, пройдитесь по короткой проверке. Это занимает 15-20 минут, но экономит дни на исправлениях после первой же рассылки.

Сначала убедитесь, что данные можно однозначно сопоставлять и нельзя «потерять» человека из-за дубля. Для получателей важны постоянный идентификатор (например, табельный номер или внутренний ID) и актуальный адрес доставки. Если поле критично для отправки, оно должно быть обязательным и проходить простую проверку формата.

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

Короткий контроль перед стартом:

• Получатели: нет дублей, есть уникальные ID, адреса и контакты заполнены по минимуму.
• Кампании: задан ответственный, даты начала и окончания, валюта и лимит, понятны статьи расходов.
• Отправки: есть статусы и «дата последнего изменения», видно кто и когда менял.
• Отчёты: доступен план-факт по бюджету и отдельный список проблемных отправок.
• Доступы: настроены роли, а изменения ключевых полей пишутся в журнал.

Реалистичный пример: кампания к празднику от начала до конца

Представим новогоднюю кампанию на 120 сотрудников в 15 городах. Цель простая: всем отправить подарки вовремя, не потерять адреса и не выйти за бюджет, даже если доставка в регионы окажется дороже.

Сначала заводите справочник получателей. Обычно список приходит от HR в таблице: ФИО, город, адрес, телефон, подразделение, комментарии (например, «только курьер после 18:00»). Загружаете список в систему и сразу делите людей на группы по смыслу: «Москва и область», «Регионы», «Удалёнка» и отдельная группа «Адрес уточняется». Так проще находить проблемные записи.

Дальше создаёте кампанию «Новый год 2026» и добавляете в неё получателей. На этом шаге удобно зафиксировать план: тип подарка, плановую стоимость, плановую доставку и общий лимит. Например, 3 000 руб на подарок и 700 руб на доставку, лимит кампании 444 000 руб.

Потом начинается операционная часть. Подарки уходят партиями. После первой недели в трекере видно картину: отправили 40, в пути 60, возврат 5, ещё 15 не готовы из-за неверных адресов. Важно вести не только текущий статус, но и причину, если что-то пошло не так: «не дозвонились», «адрес неполный», «отказ получателя». Это экономит часы переписок.

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

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

Следующие шаги: запуск пилота и развитие приложения

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

Обычно хватает такого плана:

• Соберите требования от 2-3 ролей: HR, офис-менеджер, бухгалтерия.
• Зафиксируйте минимум функций: справочник получателей, кампания, отправка со статусом, лимит бюджета, простые отчёты.
• Подготовьте данные: единый формат ФИО, адреса, контакты, идентификаторы сотрудников.
• Выберите кампанию для пилота (50-100 получателей) и назначьте владельца процесса.
• Договоритесь о метриках: время на подготовку, ошибки в адресах, число «застрявших» отправок.

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

Если хотите собрать такой трекер через vibe-coding без классической разработки, это можно сделать в TakProsto (takprosto.ai): сначала описать сущности и правила в planning-режиме, затем быстро получить рабочие формы и проверки, а изменения фиксировать снапшотами с возможностью отката.

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