Почему заявка из калькулятора не доходит до учётной системы и как это исправить

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

Где именно теряется заявка на пути от расчёта до заказа?

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

Проблема в том, что эти шаги живут в разных системах и каждая считает успехом своё. Сайт считает успехом отправленный запрос. Учётная система — созданную запись. Между ними остаётся зазор, в котором заявка либо пропадает, либо приходит неполной.

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

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

Почему «заявка отправлена» не значит «заявка принята»?

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

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

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

Третья ловушка — молчаливые отказы. Если учётная система отклоняет заявку, но никуда об этом не сообщает, сайт продолжает считать её переданной. Отказ обязан быть событием, у которого есть адресат: очередь разбора, уведомление менеджеру, запись в журнале.

Что должно уехать в заявке, кроме итоговой суммы?

Итоговая сумма без состава — это не заявка, а вопрос «сколько стоит что-то». Приёмке нужны данные, по которым можно создать строки заказа и объяснить цену. Набор шире, чем кажется на этапе прототипа.

Состав конфигурации и выбранные параметры

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

Для конфигуратора это особенно важно: готовая конфигурация превращается в заявку и спецификацию, и спецификация собирается из состава, а не из итоговой цифры. Как это устроено на стороне продукта, видно в обзоре конфигуратора оборудования.

Коды номенклатуры, единицы измерения и количество

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

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

Версия прайса и идентификатор расчёта

Идентификатор расчёта позволяет поднять конкретный результат, когда клиент звонит и говорит «у меня на сайте была другая цена». Версия прайса объясняет, по каким данным считалась сумма и почему она отличается от сегодняшней.

Без этих двух полей любой спор о цене решается по памяти. С ними разговор занимает минуту и не требует пересчёта «на глаз».

Контакт, согласие и источник заявки

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

Как сопоставить конфигурацию с номенклатурой учётной системы?

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

Есть два рабочих подхода. Первый — отдельный код на каждую комбинацию. Он прост в приёмке, но быстро разрастается: число комбинаций растёт быстрее, чем кажется, и поддерживать справочник становится тяжело.

Второй — базовые позиции плюс опции отдельными строками. Заказ собирается из нескольких строк, и приёмка видит, из чего он состоит. Этот подход гибче, но требует, чтобы учётная система умела собирать изделие из компонентов, а не только продавать готовый артикул.

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

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

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

Почему сумма на сайте и сумма в учётной системе расходятся?

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

Налог и база расчёта

Цена с налогом и цена без налога — разные числа, и смешивать их в одной сумме нельзя. Если сайт считает по одной базе, а учётная система по другой, итог разойдётся ровно на величину налога. База должна быть зафиксирована в данных и одинаково пониматься обеими сторонами.

Округление

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

Доставка, монтаж и пусконаладка

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

Скидки и наценки

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

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

Какие ошибки приёмки должен видеть менеджер?

Ошибка без адресата — это потерянная заявка. Поэтому ошибки приёмки стоит разделить на три группы, и для каждой определить, кто действует.

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

Вторая — то, что требует действия менеджера: позиция есть, но цена не задана; клиент просит объём ниже минимальной партии; товар в стоп-листе. Здесь нужен список задач с контекстом, а не просто запись в логе.

Третья — отказ клиенту: позиция снята с производства, доставка в регион невозможна. Такой отказ лучше формулировать на сайте сразу, чем выяснять его через день после «заказ оформлен».

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

Что видит клиент и что ему обещать?

Клиент не должен видеть формулировку, которая обещает больше, чем произошло. «Заказ оформлен» уместно, когда учётная система создала заказ. Пока заявка только сохранена, честнее сказать: «Расчёт сохранён, менеджер подтвердит цену и сроки».

Номер заявки и её статус стоит показывать и на странице после отправки, и в письме. Это снимает половину звонков «я отправил, а мне никто не ответил»: клиент видит, что заявка жива, и понимает, на каком она этапе.

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

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

Что делать, если учётная система недоступна в момент отправки?

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

У очереди должны быть видны размер и возраст: сколько заявок висит, за какой период, есть ли среди них старые. Очередь без наблюдения — это тихая потеря данных, которую обнаруживают по звонку клиента через неделю.

Как проверить связку до запуска?

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

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

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

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

С чего начать, если у учётной системы нет API?

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

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

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

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

Частые вопросы