Валидация ответа перед записью в CRM и ERP без сбоев

Где ломается запись в систему

Проблемы редко начинаются в CRM или ERP. Чаще сбой появляется раньше: модель отдает ответ, который выглядит правдоподобно, но не совпадает с форматом системы. Человек такой ответ еще поймет. Импорт - нет.

Одна из самых частых поломок проста: модель меняет имя поля. Вчера интеграция ждала client_id, а сегодня получила customer_id. Смысл похожий, но загрузчик не угадывает намерение. Он пропускает поле, ставит пустое значение или роняет весь запрос.

Не менее неприятны ошибки с числами. На экране строка "150000" выглядит почти так же, как число 150000. Но CRM считает их по-разному. Из-за этого ломаются лимиты, фильтры, сортировка и расчеты по сделке. Иногда ошибка тихая: запись проходит, а неверная сумма всплывает только в отчете через неделю.

Пустой ID опаснее, чем кажется. Если система обновляет карточку по идентификатору, пустое значение может создать дубль. В плохом сценарии интеграция подставит значение по умолчанию и затронет не ту запись. Тогда команда тратит время уже не на одну заявку, а на разбор всей цепочки изменений.

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

Обычно поломка выглядит так:

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

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

Что проверять до отправки

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

Проверка должна смотреть не на то, "похоже ли это на правду", а на строгие правила. Если поле не проходит валидацию, система не пишет его в CRM или ERP и отправляет ответ на повторную обработку или в ручной разбор.

Схема и форматы

Сначала зафиксируйте схему ответа. Для каждого поля задайте три вещи: обязательно оно или нет, какой у него тип и может ли оно быть пустым. Если CRM ждет customer_id как целое число, не принимайте "123" как нормальный вариант. Такая уступка почти всегда выходит боком.

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

Формат лучше выбрать один и не смешивать варианты. Если дата приходит то в 2025-04-27, то в 27.04.2025, ошибки быстро переходят в отчеты и обмены. С валютой так же: либо коды вроде KZT и USD, либо ваши внутренние обозначения, но не оба подхода сразу.

Числа, ссылки и внешние ID

Числа проверяйте не только на тип, но и на смысл. Сумма не может быть отрицательной. Скидка не должна быть больше 100%. Ставку стоит хранить в одном виде: либо 12.5, либо 0.125. Если не закрепить это правило, модель однажды вернет процент в другом масштабе, и ошибка уйдет дальше по цепочке.

Сразу задайте допустимые диапазоны. Например, сумма заявки от 1 000 до 50 000 000, срок договора от 1 до 60 месяцев, комиссия от 0 до 30. Так вы ловите не только мусор, но и правдоподобные ошибки, которые особенно неприятны.

Ссылки, коды и внешние ID тоже требуют жесткой проверки. У ссылки не должно быть пробелов, случайного текста и битого формата. Внешний ID должен существовать в исходной системе, а код подразделения - совпадать со справочником. Если модель вернула ALM-01, лучше проверить его сразу, чем потом искать причину сбоя в ERP.

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

Как собрать правила по шагам

Начните не с абстрактных требований, а с живых данных. Возьмите 10-20 реальных ответов для одной операции: например, создание лида, обновление заказа или запись обращения в ERP. На таком наборе быстро видно, где модель пишет лишний текст, путает формат даты или возвращает число строкой с пробелами.

Дальше опишите схему для каждого поля точно, без формулировок вроде "должно быть похоже". Поле обязательно или нет, какой у него тип, можно ли передавать пустое значение, есть ли список допустимых статусов. Если в CRM поле amount должно быть числом, правило должно говорить именно это. Если client_id обязан быть строкой из 24 символов, это тоже нужно зафиксировать.

Рабочий порядок обычно такой: сначала обязательные поля и типы данных, потом границы значений, затем даты и время, после этого ссылки, внешние идентификаторы и коды справочников. В конце разделите ошибки на критические и спорные.

С числами лучше быть строгим. Если система ждет целое число, не стоит молча округлять 12.7 до 13. Если сумма заказа отрицательная или скидка больше 100, запись надо остановить. Тихие исправления кажутся удобными только до первого сбоя в отчетах.

С датами правило такое же простое: один формат на весь поток. Если модель то пишет 2025-04-01, то 01.04.2025, то 1 апреля, ошибки начнут копиться. Выберите один формат и отклоняйте все остальное.

Ссылки и внешние идентификаторы требуют отдельной проверки. URL должен быть полным и без лишнего текста вокруг. Внешний ID должен совпадать с шаблоном и, если нужно, существовать в справочнике. Если модель вернула "ID клиента: 4571", это не ID, а фраза с ID внутри.

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

Как ловить ошибки в числах и датах

Перед записью в CRM или ERP проверка должна смотреть не только на наличие поля, но и на его тип и смысл. Больше всего тихих сбоев дают суммы, количества и даты: значение выглядит правдоподобно, но система либо отвергает его, либо принимает с ошибкой.

Числа

Первая проверка простая: отличайте число от текста. Если модель вернула "10", а поле ожидает 10, запись может пройти не везде одинаково. Где-то коннектор сам приведет тип, а где-то вы получите сбой на ровном месте. Лучше приводить типы явно и не полагаться на авось.

Дальше проверьте знак. Для поля "сумма к оплате" отрицательное значение обычно нельзя записывать. Если в процессе бывают возвраты или корректировки, задайте это отдельным правилом для конкретного типа документа, а не оставляйте отрицательные числа открытыми для всех случаев.

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

С валютой и дробной частью тоже нужен контроль. Поле amount без currency почти бесполезно. А если валюта есть, проверьте число знаков после запятой по правилам вашей учетной системы. Значение 1250.567 не должно попадать в документ, если поле допускает только два знака.

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

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

Даты

С датами проблема обычно не в формате, а в смысле. 2025-02-31 выглядит как дата, но такой даты нет. 03.04.2025 тоже опасна: один сервис прочтет это как 3 апреля, другой как 4 марта. Один формат на входе, лучше ISO, резко снижает число таких ошибок.

После этого проверьте срок. Дата счета не должна быть позже даты оплаты. Дата начала договора не должна идти после даты окончания. Если заявка должна попасть в CRM в течение 30 дней с момента обращения, все, что старше, лучше отправлять на ручную проверку.

Небольшой пример: модель вернула сумму -15000, валюту KZT, дату оплаты на месяц раньше даты счета и итог, который не сходится со строками на 200 тенге. По отдельности каждое поле похоже на правду. Вместе это уже явный стоп-сигнал.

Как проверять ссылки и внешние идентификаторы

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

Если команда получает ответ модели через AI Router и потом отправляет данные в CRM или ERP, такой фильтр лучше держать между ответом модели и API бизнес-системы. Так ошибки не уходят дальше по цепочке. Сам шлюз доставит ответ, а проверка рядом с бизнес-логикой решит, можно ли его записывать.

Проверка ссылок

Начните с разбора URL по частям, а не с поиска подстроки. Поле должно содержать только разрешенный протокол. В большинстве случаев это https. Иногда компании оставляют http для внутренних сервисов, но это редкий случай, и его лучше отдельно описать в правилах.

Дальше сверяйте домен со списком разрешенных. Проверяйте именно хост, а не просто наличие знакомого слова в строке. client-example.com и client-example.com.fake выглядят похоже, но это разные адреса. Если вы храните ссылки только на прод-системы партнера, сразу блокируйте test, staging, sandbox, dev, localhost и внутренние стенды.

Короткие и обрезанные ссылки тоже лучше не пропускать. Сокращатель скрывает реальный адрес, а строка с ... почти всегда означает, что кто-то скопировал ее не полностью. Для CRM это плохой компромисс: сотрудник видит ссылку, но открыть нужный объект не может.

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

Проверка внешнего ID

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

Например, если ID заказа должен иметь вид ORD- и 10 цифр, строка 12345, test_77 или значение длиной 40 символов не должны попасть в систему. Если ID приходит как число, храните его как строку. Иначе легко потерять ведущие нули, а потом не найти запись у внешнего провайдера.

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

Простой пример с заявкой в CRM

После звонка бот собирает карточку лида: имя, телефон, сумму кредита, сайт компании и короткий комментарий. На экране все выглядит правдоподобно. Но CRM ломается не на явных ошибках, а на мелочах, которые человек часто не замечает.

Менеджер говорит: "сто тысяч", а модель возвращает "1O0000". Визуально строка почти верная, но вместо нуля там буква O. Для поля суммы это уже не число. Если запись уйдет дальше без проверки, CRM может отклонить всю карточку или сохранить ее с пустой суммой.

С сайтом та же история. Клиент называет адрес компании, и в ответ попадает "company.kz" без https://. Для сотрудника это обычный сайт. Для системы, которая ждет ссылку в строгом формате, это ошибка.

Что делают правила

Здесь помогает проверка перед записью в CRM. Она смотрит не на общий смысл, а на каждое поле отдельно. Схема убеждается, что сумма хранится в числовом поле, а сайт - в строке нужного формата. Проверка чисел отсекает символы вроде O, пробелы в странных местах и лишние знаки. Проверка ссылок требует http:// или https://. Обязательные поля не дают сохранить пустую карточку.

Если сумма кредита не проходит правило, система не пишет лид в рабочую CRM. Она сохраняет черновик, помечает причину ошибки и создает задачу оператору. Оператор сразу видит, что нужно исправить: заменить "1O0000" на "100000" и подтвердить запись.

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

Такой фильтр кажется мелочью, пока заявок мало. Но даже 5 ошибок в день дают десятки карточек с пропусками или сбоями за месяц. Проще поймать их до записи, чем потом искать, почему лид не попал в воронку и кто должен его восстановить.

Частые ошибки в правилах проверки

Самая частая ошибка проста: команда проверяет только форму ответа, а не смысл. JSON может быть идеально собран, поля могут стоять на своих местах, но запись все равно сломает CRM или ERP. Например, модель вернула client_id, amount и status, схема прошла, а status не существует в вашем справочнике. Формально все верно, по бизнес-правилам - нет.

Это особенно заметно в проектах, где вся проверка сводится к одному вопросу: "Парсится ли JSON?" Этого мало. Если вы получаете ответ от модели через любой шлюз или API, в том числе OpenAI-совместимый, проверка должна идти в два слоя: сначала структура, потом смысл полей.

Вторая ошибка - считать null тем же самым, что пустая строка. Для бизнес-систем это разные состояния. Пустая строка в поле comment может быть допустимой, а null в поле customer_name часто означает, что значение вообще не определено. Если смешать эти случаи, система то примет битую запись, то отклонит нормальную.

Третья ошибка опаснее, чем кажется: молча исправлять суммы, даты или другие числа. Если модель вернула 99999.999, а правило округлило сумму до 100000 и отправило ее дальше без следа, вы уже не проверяете данные, а переписываете их. Для счета, заявки на кредит или закупки это плохая идея. Лучше явно отклонить запись и вернуть причину.

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

Если все это свалить в один статус invalid, разбор инцидентов станет долгим и нервным.

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

Быстрая проверка перед запуском

Перед тем как дать модели право писать в CRM или ERP, прогоните короткий тест на реальных примерах. Достаточно 20-30 ответов: часть нормальных, часть с пропусками, часть с ошибками в суммах, датах и ссылках. Такая проверка почти всегда находит сбои, которые потом обходятся дороже всего.

В центре проверки не модель, а контракт на запись. Если поле обязательно для сделки, счета или заявки, пустое значение не должно пройти дальше. Если поле хранит число, строка вроде "примерно 50000" должна получить отказ, даже если человеку смысл понятен.

Короткий чек-лист перед запуском выглядит так:

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

Последний пункт часто пропускают. В итоге команда видит, что запись не появилась в CRM, но не понимает почему. Нормальный журнал должен показывать поле, значение и правило, на котором ответ остановился. Очередь нужна затем, чтобы не потерять такие случаи: исправили правило или попросили модель пересобрать ответ, после чего запись можно отправить повторно.

Мини-тест перед доступом на запись

Возьмем простую заявку. Модель вернула имя клиента, телефон, сумму заказа и ссылку на источник. Перед записью система проверяет, что имя не пустое, телефон попадает в нужный формат, сумма не уходит ниже нуля и не выглядит как аномалия, а ссылка ведет только на разрешенный домен. Если вместо суммы пришло "около 2 миллионов", заявка не летит в CRM. Она попадает в очередь с пометкой "поле amount: ожидалось число".

Даже если ответы идут через единый OpenAI-совместимый шлюз вроде AI Router, валидация все равно должна жить рядом с бизнес-логикой. Шлюз доставит ответ модели, но только ваша система знает, какие поля обязательны, какие пределы допустимы и какие домены можно принимать.

Если этот тест проходит без сюрпризов, можно открывать запись сначала на небольшой доле трафика. Это спокойнее, чем чинить испорченные карточки клиентов уже внутри CRM или ERP.

Что сделать дальше

Не пытайтесь сразу закрыть проверками всю ERP или всю CRM. Такой план почти всегда вязнет в деталях. Лучше взять одну операцию, где ошибка стоит дорого: создание клиента, запись заказа или обновление счета.

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

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

Полезно вести простую статистику по типам ошибок. Не общую цифру "успех или отказ", а причину каждого сбоя: пустой email или телефон, сумма с лишним разделителем, дата в неверном формате, несуществующий внешний ID, ссылка, которую система не принимает.

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

Раз в неделю просматривайте последние отказы вручную. Обычно хватает 20-30 записей, чтобы понять, что менять. Если один и тот же сбой повторяется, добавьте точную проверку. Если правило ловит нормальные ответы, ослабьте его. Так правила растут из практики, а не из догадок.

Небольшой пример: команда пишет лиды в CRM и видит частую ошибку в бюджете. Модель присылает "12,000", а система ждет "12000". Один раз добавили нормализацию, посмотрели статистику через неделю, и целый класс сбоев исчез.

Если команда уже ведет LLM-запросы через AI Router на airouter.kz, не стоит строить отдельный путь перед записью в CRM или ERP. Единый поток запросов и аудит-логи упрощают разбор ошибок: видно, какой запрос дал сбой, что вернула модель и какое правило остановило запись. Это особенно полезно там, где важны маскирование PII, хранение данных внутри страны и контроль запросов на уровне ключа.

Когда одна операция работает спокойно 2-3 недели, берите следующую. Так система растет без рывков и без сюрпризов для бизнеса.