Синхронизация Prom.ua, Rozetka, прайс-листов + фискализация (ПРРО)

У нас есть чат-бот на SendPulse и требуется настройка, чтобы через него была возможность оформления подписки на закрытый клуб с помощью Stripe и она продлевалась автоматически каждый месяц, и вот давал возможность управления подписки, а также автоматически открывал и закрывал доступ в случае начала либо её окончания Что уже готово В Stripe создан продукт с ежемесячным списанием и платежная ссылка на него. Бот в SendPulse существует, ведет пользователя к оплате и умеет ставить теги и работать с полями контакта. Не хватает связки между двумя системами: сейчас, если человек оплачивает через Stripe, SendPulse об этом не узнает Что нужно сделать Настроить в Stripe вебхук на события checkout.session.completed, invoice.paid и customer.subscription.deleted Написать обработчик (serverless-функция или готовый no-code инструмент вроде Albato, n8n) который принимает вебхук, достает email клиента и тип события Через API SendPulse обновлять поле или тег контакта (например, club_active = да/нет) в зависимости от события Настроить в SendPulse автоматизацию, которая по этому полю открывает доступ к закрытому каналу при успешной оплате и закрывает при отмене или неудачном списании Подключить Stripe Customer Portal, чтобы участник мог сам отменить подписку или сменить карту, и это тоже долетало до SendPulse через тот же вебхук если у вас есть способ связки легче без сторонних веб-хуков, тоже такое рассмотрим! Что должно получиться на выходе Рабочая цепочка: человек оплачивает в Stripe, в течение пары минут получает доступ к каналу, при отмене или провале списания доступ закрывается автоматически, без участия администратора. Плюс короткая документация: где что настроено, как перезапустить обработчик, если он упадет, и куда смотреть при жалобе участника на закрытый доступ Кого ищем Опыт работы с Stripe API и вебхуками, опыт с SendPulse API (или готовность быстро в нем разобраться, документация открытая), умение поднять простой serverless-обработчик или настроить связку в Albato/n8n. Готовность показать похожий кейс из портфеля будет плюсом

О компании и текущей работе Компания продает товары через: несколько магазинов Rozetka; 5–8 магазинов Prom.ua; несколько магазинов Epicentr. Объем: ориентировочно 50–100 заказов в день. Планируется подключение хорошоп в ближайшее времяИспользуемые системы и способы оплаты Rozetka; Prom.ua; Epicentr; Новая почта; NovaPay; PrivatBank; monobank; RozetkaPay; Checkbox. Способы оплаты: наложенный платеж через Новую почту / NovaPay; RozetkaPay; прямой перевод на IBAN; планируется оплата по ссылке через эквайринг monobank. NovaPay и RozetkaPay перечисляют деньги общей суммой по реестрам: в реестре NovaPay указаны ТТН; в реестре RozetkaPay указаны заказы. Основные цели Настроить KeyCRM так, чтобы владелец мог в одном месте: -Видеть все заказы из всех магазинов. -Не терять заказы и ТТН. -Видеть текущее состояние каждой отправки. -Видеть фактическое движение денег по заказам. -Автоматически связывать поступившие оплаты с соответствующими заказами. -Видеть непривязанные оплаты, недоплаты, переплаты и другие расхождения. -Контролировать действия сотрудников. -Минимизировать ручную работу.-Автоматическую фискализацию - Выстроить автоматизацию правильную по движению заказа Провести аудит действующего KeyCRM Проверить: -текущие статусы, поля и автоматизации; -банковские и платежные подключения; -роли и права сотрудников; -историю действий; -текущую настройку Checkbox; -возможность реализации требований штатными средствами KeyCRM. По результатам аудита предоставить: -список найденных проблем; -перечень необходимых настроек; -перечень задач, для которых нужна API-интеграция или внешний сервис; -рекомендации для лучшей работы сервиса -оценку сроков и стоимости. Настроить поступление и обработку заказов Необходимо: настроить единую последовательность обработки заказов; настроить обязательные поля, без которых заказ нельзя передать на следующий этап; создать контроль заказов, которые не загрузились, загрузились с ошибкой или остались без ответственного. Настроить движение и сверку оплат Подключить к KeyCRM все используемые счета и платежные сервисы: PrivatBank; monobank; NovaPay; RozetkaPay; эквайринг monobank после его подключения. Необходимо реализовать: -Автоматическое получение доступных выписок и транзакций. -Отображение фактических поступлений по каждому ФОП и счету. -Автоматическую привязку прямого платежа на IBAN к заказу по номеру заказа в комментарии. -Сверку общей выплаты NovaPay с реестром и дальнейшую привязку строк реестра к заказам по ТТН. -Сверку общей выплаты RozetkaPay с реестром и дальнейшую привязку строк реестра к заказам по номеру заказа. -Автоматическую обработку оплат по ссылке после подключения эквайринга. -Отдельный список оплат, которые невозможно связать автоматически. Выявление: -недоплаты; -переплаты; -частичной оплаты; -дублированной оплаты; -оплаты без найденного заказа; -заказа, отмеченного оплаченным без подтвержденного поступления. -Ежедневную сверку сумм по ФОП, счетам и способам оплаты. -Статус «Оплачено» должен устанавливаться автоматически после подтвержденного зачисления денег на соответствующий IBAN. Сотрудники не должны иметь права устанавливать его вручную. Если штатных возможностей KeyCRM недостаточно, интегратор должен: предложить API-интеграцию или внешний модуль; описать его логику; отдельно оценить разработку; обеспечить журнал ошибок и повторную обработку; не привязывать оплату автоматически при неоднозначном совпадении. Настроить контроль потерянных заказов Нужен отдельный рабочий список или отчет: заказ поступил, но не взят в работу; заказ подтвержден, но не передан на склад или дроп; заказ готов, но ТТН не создана; ТТН создана, но посылка не передана перевозчику; посылка долго не движется; клиент не забирает посылку; была переадресация; начался возврат; возвратная посылка не получена компанией; заказ доставлен, но оплата не зачислена; оплата получена, но не связана с заказом; заказ остался в промежуточном статусе дольше допустимого срока. По каждому исключению должны быть: ответственный; срок реакции; задача или уведомление; понятная причина; ссылка на заказ.4.7. Настроить права и контроль сотрудников Обязательные ограничения: -сотрудники не могут удалять заказы; -сотрудники не могут вручную ставить статус «Оплачено»; -сотрудники не имеют доступа к банковским подключениям, API-ключам и административным настройкам.Настроить Checkbox Сейчас чеки из KeyCRM не создаются. Интегратору необходимо: -проверить существующие кабинеты, кассы и кассиров Checkbox; -подключить кассы соответствующих ФОП; -настроить способы оплаты; -настроить автоматическую фискализацию для согласованных сценариев; -настроить обработку ошибок; -настроить чеки возврата; -провести тестирование.Настроить отчеты для владельца Владелец должен видеть: -количество новых и необработанных заказов; -проблемные отправления; -посылки в отделении; -возвраты; -доставленные заказы без поступившей оплаты; -поступившие, но непривязанные оплаты; -недоплаты и переплаты; -ручные изменения сотрудников.Формат может быть реализован штатными списками, фильтрами, аналитикой, задачами или внешним отчетом — способ предлагает интегратор. Обучить сотрудников После настройки провести обучение: владельца — контроль, отчеты, ошибки и права; менеджеров — обработка заказов; сотрудника дропа — передача заказа и контроль ТТН; сотрудника склада — создание ТТН и отправка; ответственного за финансы — обработка непривязанных платежей и расхождений. Предоставить короткие инструкции или видеозаписи основных операций. Ожидаемый результат После выполнения работ: -все заказы обрабатываются в KeyCRM; -пропущенные и зависшие заказы автоматически выявляются; -каждая ТТН связана с заказом и отслеживается; -проблемные посылки попадают ответственным сотрудникам; -банковские и платежные поступления видны в CRM; -однозначные оплаты автоматически связываются с заказами; -реестры NovaPay и RozetkaPay сверяются с поступлениями и заказами; -неоднозначные оплаты попадают на ручную проверку; -сотрудники не могут удалить заказ или вручную отметить его оплаченным; -владелец видит движение денег и список отклонений; -Checkbox работает по согласованным сценариям; -команда обучена работе. Формат предложения от интегратора До начала внедрения исполнитель должен предоставить: -Результат аудита. -Предлагаемую схему настройки. -Что будет реализовано штатными средствами KeyCRM. -Что потребует API или внешнего сервиса. -Стоимость штатной настройки. -Отдельную стоимость разработки. -Сроки по этапам. -Перечень необходимых доступов. -План тестирования и запуска.

Разработка международного мобильного приложения под ключ (Дизайн + Код) Для удешевления, возможно не делать, а купить готовый дизайн 1. Общие требования к проекту Платформа: Кроссплатформенная разработка на фреймворке Flutter (один код под iOS и Android). Тип платформы: Социальный беттинг / Игровые споры на дисциплину (Peer-to-Peer 도전戰). Задача Исполнителя: Полный цикл разработки (UI/UX Дизайн в Figma, фронтенд, бекенд-сервер, база данных, интеграция IoT-датчика контроля и платежного шлюза). Мультиязычность: Полная поддержка локализации (i18n) и работа с несколькими валютами. 2. Требования к UI/UX Дизайну Необходима разработка современного, неоново-технологического интерфейса в темных тонах (Dark Mode). Акцентные цвета: Глубокий графитовый (фон), яркий зеленый (финансы, баланс), яркий красный (режим охраны включен, штрафные события). Функционал: Отображение 4 главных экранов нижней навигации (Дашборд, Игровые комнаты, Кошелек, Настройки устройства). Нужны динамические анимации изменения баланса и всплывающих алертов. 3. Финансовая архитектура (Escrow/Holding/Split) Приложение обязательств на удержание депозитов за соблюдение правил дисциплины. Критически важна интеграция платежного шлюза, поддерживающего Split Payments (Разделение платежей) и Холдинг средств (Stripe Connect для глобального рынка/аналоги для локального). Логика транзакций (API-команды бекенда): Пополнение: Средства пользователей привязываются к их аккаунту и замораживаются на транзитном (эскроу) счете платежной системы. Они не поступают непосредственно на счет компании. Режим SOLO: При наступлении триггерного события от IoT-датчика в запрещенные часы бекенд дает команду платежной системе перевести фиксированную сумму (штраф) с транзитного счета пользователя на расчетный счет компании. Режим GROUP (Комнате): Пользователи формируют общий пул (например, 10 человек по $10). Деньги замораживаются в пределах конкретной Игровой Комнаты. При наступлении триггерного события у одного из участников сумма его штрафа автоматически разделяется: 15% (комиссия платформы) идут на расчетный счет компании, а 85% остаются внутри призового фонда комнаты. После окончания срока челленджа бекенд автоматически распределяет накопленный призовой фонд между победителями, а платежная система делает автоматический перевод (Payout) им на карты. 4. Структура кабинетов Кабинет 1: "Персональный Трекер" (Режим SOLO) Индикатор статуса мониторинга (Активный/Доступный/Заблокированный). Конфигуратор временных интервалов охраны (Time Picker) и настройки стоимости штрафного триггера. Панель состояния внешнего устройства IoT (заряд батареи датчика в %, уровень сигнала, статус синхронизации). Кабинет 2: «Игровые Комнаты» (Режим GROUP) Инструментарий создания приватных комнат (генерация инвайт-ссылок/код для друзей) и список публичных глобальных лиг. Турнирная таблица (Лидерборд) участников с отображением их текущего статуса в реальном времени, таймер до конца челленджа и встроенный групповой чат. Общий раздел: Мультивалютный кошелек Отображение баланса с автоматическим конвертированием локальных валют в реальном времени. История транзакций с прозрачным логом списаний, комиссий и выигрышей. 5. Требования к Бекенду и Интеграции IoT Стек: Node.js/Python/Go (на выбор исполнителя, аргументированно). Связь с IoT: Прием пакетов данных от внешнего Wi-Fi модуля. Скорость отправки Push-уведомления (через FCM) на смартфон при наступлении события от датчика – менее 1 секунды. Антифрод-логика: Сервер должен анализировать переданные датчиком телеметрические данные встроенного акселерометра (accel_x/y/z). Если событие происходит при нулевой изменении осей ускорения, транзакция помечается системой как подозрительная (защита от статического удержания датчика), пользователю отправляется предупреждение.