СтатьиQlikИнструментыUI Kit Поиск RSS →
← Все статьи
скилыClaude CodeCursorAI skillsсчётЮKassaТ-БанкAPI банкаавтоматизацияИИЧернов пишет

От сделки до отправленного счёта: связка данные-документ-отправка через API банка

От сделки до отправленного счёта: связка данные-документ-отправка через API банка

Закрыл сделку - и начинается муторное. Открыть шаблон счёта, вписать реквизиты клиента, перенести сумму, не перепутать назначение платежа, посчитать НДС, сохранить, прикрепить к письму, отправить. На одной сделке это пять минут. На потоке - это узкое горло, в котором ты теряешь время и иногда саму отправку: счёт сверстал, а клиенту так и не ушёл.

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

И ведь всё это - типовая повторяемая операция. Ровно то, что хочется один раз описать и больше не трогать руками. Разберём, как собрать скил, который по данным сделки сам выставляет счёт и присылает клиенту ссылку на оплату - а если каких-то реквизитов не хватает, переспрашивает, а не выдумывает. Заодно это отличный повод познакомиться с приёмом, который дальше пригодится постоянно.

В чём идея

Выставление счёта - это не одно действие, а три разных дела подряд. Первое: собрать данные сделки - сумму, за что платим, кому отправить. Второе: превратить эти данные в документ - перевести рубли в копейки, посчитать НДС, собрать корректное тело счёта. Третье: отправить - создать счёт в банке и отдать клиенту ссылку на оплату.

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

Почему цепочка лучше монолита? Потому что её можно чинить по частям. Поменялся банк - правишь только звено отправки, сбор реквизитов не трогаешь. Добавился НДС - это звено документа, остальное стоит на месте. Сломалось что-то - сразу видно, на каком звене: данные не собрались, документ не посчитался или API не ответил. Монолит так не умеет: в нём всё переплетено, и любая правка грозит уронить всю сборку.

Второй важный момент - где живёт логика. Перевод рублей в копейки, расчёт НДС, заголовки запроса к банку, обработка ошибки API - это код, и держать его в тексте инструкции вредно: текст пухнет и ломается при правках. Поэтому логику цепочки выносим в отдельный скрипт, а сам скил остаётся тонкой инструкцией: когда срабатывать и что запустить. Это тот самый приём “вынеси логику в tools/”, только теперь внутри - не одно действие, а цепочка.

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

По-честному про ограничения. Платёжный API российских банков (ЮKassa, Т-Банк) реально отдаёт ссылку на оплату по токену - это рабочий путь, не фантазия. Но включается он только у подключённого мерчанта: нужен расчётный счёт и договор. А юридически значимый акт с подписью - это уже не просто ссылка, а ЭДО или электронная подпись, и это тема соседнего урока. Наш скил делает то, что делается через API: счёт на оплату и ссылку клиенту.

Как себе сделать

Не собирай эту цепочку руками - отдай задачу своему ассистенту. Claude Code, Codex, Cursor, Gemini - любой. Он сам разберётся, куда положить файлы, как звать платёжный API и как развести логику по звеньям. Просто скопируй промпт:

Создай мне скил, который по данным сделки выставляет счёт и присылает клиенту ссылку на оплату.
Срабатывай на просьбы вроде "выстави счёт по сделке", "сформируй счёт клиенту", "создай счёт на оплату".
Собери это цепочкой из трёх звеньев и вынеси логику в отдельный скрипт:
  1) данные - собрать и проверить реквизиты сделки (сумма, назначение, email клиента); чего не хватает - спроси, не выдумывай;
  2) документ - перевести рубли в копейки целыми числами, при НДС посчитать и показать его в назначении;
  3) отправка - создать счёт в платёжном API российского банка (ЮKassa или Т-Банк) и вернуть ссылку на оплату и номер счёта.
Токен и идентификатор магазина бери только из окружения, не из текста скила; на повторный запрос ставь ключ идемпотентности, чтобы не задвоить счёт.

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

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

Смотреть полностью

Коротко