Счёт на оплату в интернет-магазине на Битрикс: реквизиты и сверка платежа

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

Счёт на оплату в интернет-магазине на Битрикс: задача и границы

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

Речь идёт о магазине на «1С-Битрикс: Управление сайтом», а не о CRM Битрикс24. Это разные продукты с разной логикой, и смешивать их при постановке задачи не стоит: то, что делается в карточке сделки CRM, не равно настройке платёжной системы в магазине. Если команда привыкла работать в CRM, это не значит, что те же приёмы сработают в витрине.

В документации 1С-Битрикс описан отдельный способ оплаты «Счёт»: у него есть настройки обработчика, раздел ограничений и возможность получить счёт в публичной части сайта. Отдельно описан механизм частичных оплат заказа — когда сумма закрывается не одним платежом, а несколькими. Эти два блока и образуют техническую основу задачи.

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

Какие исходные данные и правила согласовать до настройки

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

Что нужно зафиксировать:

• Реквизиты получателя. Полное наименование, ИНН, КПП, расчётный счёт, банк, БИК, корреспондентский счёт. Если получателей несколько, отдельно решается, по какому правилу выбирается нужный.
• Назначение платежа. Формулировка, по которой бухгалтерия покупателя и магазин смогут однозначно опознать заказ. Обычно это номер заказа и, при необходимости, дата.
• Шаблон счёта. Какие поля выводятся, есть ли логотип, подпись, печать, кто указан исполнителем.
• Нумерация. Сквозная или по периодам, с привязкой к номеру заказа или отдельная.
• Статусы заказа. В какой статус попадает заказ после выставления счёта и в какой — после подтверждения оплаты.
• Полная или частичная оплата. Может ли покупатель закрыть счёт частями и как это отражается в заказе.
• Срок действия счёта. Через какое время счёт считается неактуальным и что тогда происходит с заказом.
• Кто сверяет поступление. Конкретный сотрудник или роль, которая сопоставляет банковскую выписку с заказами.

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

Что входит в счёт и как он выглядит для покупателя

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

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

Отдельно проверяется, как покупатель получает счёт: скачивает файл, видит его на странице заказа или получает уведомление (сценарий настраивается). В документации отмечена возможность получить счёт в публичной части (требует настройки), и это стоит проверить на тестовом заказе, а не предполагать.

Как выбрать подходящий сценарий

Сценариев немного, и они отличаются тем, кто и когда формирует счёт, а также тем, насколько автоматизирована сверка.

Счёт формируется автоматически после оформления заказа

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

Счёт выставляет менеджер вручную

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

Счёт как один из способов оплаты наряду с онлайн-оплатой

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

Частичная оплата по счёту

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

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

Порядок настройки и распределение ответственности

Работы удобно вести по шагам, и первый шаг — не настройка, а защита рабочего магазина.

1. Сделать резервную копию и зафиксировать текущее состояние. Любые изменения сначала проверяются на копии или тестовом магазине, а не на рабочем сайте. 2. Согласовать вводные из предыдущих разделов и записать их. 3. Настроить способ оплаты «Счёт»: заполнить реквизиты, параметры обработчика, учесть ограничения, описанные в документации. 4. Подготовить шаблон счёта и проверить, как он выглядит для покупателя. 5. Настроить статусы заказа и уведомления: что видит покупатель после выставления счёта и после подтверждения оплаты. 6. Описать порядок сверки: кто и как сопоставляет поступление с заказом, что делает при расхождении суммы или назначения. 7. Провести приёмочную проверку по чек-листу и только после этого переносить изменения на рабочий магазин.

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

Как организовать сверку поступившего платежа

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

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

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

Таблица сценариев и ожидаемых результатов

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

Учебный пример: счёт и сверка платежа

Учебный пример. Данные условные, они показывают ход работы, а не реальную статистику.

Входные условия. Небольшой магазин на «1С-Битрикс: Управление сайтом» продаёт оборудование. Покупатели — в основном юрлица. Реквизиты получателя согласованы с бухгалтером, назначение платежа содержит номер заказа. Сотрудник, который сверяет поступление, — менеджер. Автоматической выгрузки из банка нет, сверка ручная.

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

Наблюдаемый результат. Покупатель получает корректный счёт, магазин видит заказ в понятном статусе, а сверка укладывается в описанный регламент. Если на каком-то шаге сумма или реквизиты не совпадают, это фиксируется как ошибка настройки, а не как «особенность».

Проверка. Результат считается принятым, когда тестовый заказ проходит весь путь без ручных правок в документе, а сверка выполняется по заранее описанному правилу. Только после этого изменения переносятся на рабочий магазин.

Как проверить результат на тестовом магазине

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

• Резервная копия сделана, есть план возврата к прежнему состоянию.
• Реквизиты получателя в счёте совпадают с согласованными.
• Назначение платежа позволяет однозначно опознать заказ.
• Шаблон счёта корректно отображается и печатается.
• Способ оплаты «Счёт» доступен покупателю в нужных случаях.
• Статусы заказа меняются так, как описано в регламенте.
• Полная оплата переводит заказ в правильный статус.
• Частичная оплата отражается корректно и итог сходится с суммой заказа. Механизм частичных оплат требует настройки и проверки.
• Уведомления покупателю приходят в нужные моменты.
• Порядок сверки поступления описан и понятен ответственному.
• Расхождение суммы или назначения платежа имеет понятный сценарий обработки.
• Изменения переносятся на рабочий магазин только после успешной проверки.

Ошибки, ограничения и дальнейшие действия

Типичные ошибки повторяются из проекта в проект.

• Настройка без согласованных реквизитов и формулировок. Потом счёт приходится переделывать, а покупатель получает документ с неверными данными.
• Отсутствие ответственного за сверку. Платёж приходит, но заказ остаётся в старом статусе.
• Игнорирование ограничений способа оплаты. В документации у «Счёта» есть раздел ограничений. Их нужно учитывать до запуска, проверяя актуальность в текущей версии.
• Смешивание магазина и CRM. Логика Битрикс24 и «Управления сайтом» различается, и переносить приёмы из одного продукта в другой без проверки нельзя.
• Изменения сразу на рабочем сайте. Без копии и плана возврата любая ошибка бьёт по живым заказам.

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

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

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