Автоматизація KeepinCRM для інтернет-магазину
Автоматизація KeepinCRM для інтернет-магазину
Посилання:
Go-демон, що повністю автоматизує CRM-процеси українського інтернет-магазину: інтеграції з Новою Поштою, Checkbox (ПРРО) і TurboSMS.

Контекст
Клієнт вів інтернет-магазин на Prom.ua з десятками замовлень щодня. Замовлення автоматично потрапляли до KeepinCRM, але все інше — переміщення угод по воронці, формування фіскальних чеків, сповіщення покупців — виконувалося вручну і супроводжувалося помилками.
Мета: повна автоматизація від надходження замовлення до видачі фіскального чека.
Що зроблено
Легкий Go-демон (keepincrm-auto), що кожні 5 хвилин опитує KeepinCRM і керує трьома інтеграціями в одному циклі.
1. Автоматизація воронки продажів (Нова Пошта → KeepinCRM)
Статуси доставки НП автоматично відображаються в етапи CRM:
| Статус НП | Етап CRM |
|---|---|
| Відправлено (4/5/6) | Відправлено |
| Прибув на відділення (7/101) | Очікує отримання |
| Отримано + оплачено (9) | Отримано — очікуємо післяплату |
| Кошти зараховано (10/11) | Завершено |
| Скасовано (102–106) | Скасовано |
Кожен перехід записується коментарем до угоди в CRM і дедублікується через SQLite — жодного подвійного переміщення, скільки б разів не опитувався той самий статус.
2. Формування фіскальних чеків (Checkbox ПРРО)
Чеки видаються з правильним типом оплати для кожного способу розрахунку:
| Спосіб оплати | Тригер | Тип у Checkbox |
|---|---|---|
| Накладений платіж / NovaPay | НП статус 9 (посилку отримано) | CASHLESS · “Платіж через інтегратора NovaPay” |
| WayForPay | Одразу при появі замовлення в CRM | CASHLESS · “Платіж через інтегратора WayForPay” |
| Готівка / рахунок | — | Обробляється вручну |
Ключова задача для WayForPay: початкова архітектура відстежувала тільки доставки (ТТН). Замовлення WayForPay оплачуються онлайн до створення ТТН — тому сервіс їх не бачив. Рішення: паралельне сканування всіх угод CRM через GET /agreements, фільтрація за prom_payment_type, фіскалізація одразу. Ключ дедублікації: agreement:<id>.
Після кожного чека демон опитує Checkbox поки ДПС асинхронно не присвоїть fiscal_code (до 60 с), потім додає посилання на чек коментарем до угоди.
3. SMS-сповіщення (TurboSMS)
- SMS №1 — при створенні ТТН: номер + посилання для відстеження
- SMS №2 — при прибутті на відділення: нагадування забрати посилку
- SMS №3 — після фіскалізації: посилання на публічний фіскальний чек
Всі SMS-події дедублікуються; скасовані ТТН пропускаються; формат номерів +380.
Архітектура
Prom.ua ──────────────────► KeepinCRM
Nova Poshta API ──────────► │
│ GET /deliveries
│ GET /agreements
▼
┌─────────────────────────┐
│ keepincrm-auto │
│ Go daemon · systemd │
│ │
│ Delivery Processor │
│ Agreement Scanner WFP │
│ SQLite dedup │
└──────┬──────────┬───────┘
│ │
Checkbox ПРРО TurboSMS
│ │
└────┬─────┘
▼
Клієнт
(посилання на чек + SMS)
Технічні деталі
- Мова: Go 1.24+
- Стан: SQLite з
UNIQUE (ttn, event_type)— ідемпотентна логіка за дизайном - Асинхронний ДПС: після
POST /receipts/sellопитуєGET /receipts/{id}до 12 × 5 с, поки не з’явитьсяfiscal_code - Тип оплати Checkbox:
CASHLESS+label(підтверджено на реальному чеку Prom.ua від mono — той самий патерн) - Деплой: systemd-юніт на VPS клієнта (Ubuntu 20.04, CyberPanel); скрипт деплою через
rsync+go buildна сервері - Спостережуваність: структурований логінг (
log/slog), щоденний бекап SQLite через cron, watchdog cron для авто-перезапуску при падінні
Результати
- 14 накопичених WayForPay-замовлень отримали чеки в першому ж циклі після деплою
- 97% доставленість SMS (72 надіслано, 2 недоступні номери)
- Кожне нове замовлення обробляється протягом 5 хвилин, повністю автоматично
- Жодного дубля чеків чи SMS за тижні продакшн-роботи
#golang #systemd #sqlite #rest_api #keepincrm #nova_poshta #checkbox #turbosms #wayforpay #електронна_комерція #автоматизація_crm #фіскалізація #прро