Оплата поставщикам и авансы в ERPNext: как провести платёж и не потерять аванс

Оплату поставщику в ERPNext проводят документом Payment Entry типа Pay: он гасит счёт Purchase Invoice или фиксирует аванс по заказу. Остаток платежа остаётся в Unallocated Amount и зачитывается в следующий счёт. Ниже шаги, ошибки и разбор примера.

Как оплатить счёт поставщика в ERPNext: Purchase Invoice и Payment Entry по шагам

Цепочка оплаты в ERPNext короткая, и путаются в ней не из-за сложности, а из-за привычки к другим системам. Заказ поставщику оформляется как Purchase Order, приход на склад — как Purchase Receipt, счёт и долг — как Purchase Invoice, а деньги — как Payment Entry. Каждый документ делает одну работу. Purchase Invoice фиксирует, что вы должны поставщику, но денег не двигает. Деньги двигает только Payment Entry. Если вы внедряете систему и хотите понять картину целиком, помощь с настройкой мы описали на странице ERPNext под ключ.

Порядок действий при обычной оплате счёта, как я его настраиваю бухгалтеру. Открываете проведённый Purchase Invoice со статусом Unpaid и создаёте из него платёж через меню Create, пункт Payment: форма Payment Entry заполняется сама. Проверяете поля: Payment Type — Pay, Party Type — Supplier, счёт списания (Account Paid From) — банк, счёт зачисления (Account Paid To) — кредиторская задолженность. Указываете номер и дату платёжки в Reference No и Reference Date, проводите документ. Статус счёта меняется на Paid, а при частичной оплате — на Partly Paid.

Статусы счёта поставщика, которые нужно знать: Draft (сохранён, но в учёт не проведён), Unpaid (проведён, долг есть), Partly Paid (покрыт частично), Paid (долга нет), Overdue (просрочен после срока оплаты), Return и Debit Note Issued (возвраты) и Cancelled. По статусу Overdue удобно собирать недельный список платежей: система сама отделяет просроченную кредиторку от текущей. Без согласованного регламента статусы остаются просто цветными ярлыками, поэтому я прошу бухгалтера каждый понедельник открывать список с фильтром Overdue.

Есть короткий путь для компаний без складской приёмки. Если параметр обязательной приёмки (Purchase Receipt Required) в настройках выключен, цепочка сокращается до заявки, заказа, счёта и платежа: Material Request, Purchase Order, Purchase Invoice, Payment Entry. Для услуг, подряда и закупок «под клиента» это нормально, для складских материалов лучше оставить приёмку: без неё вы не видите, что оплатили товар, которого на складе нет.

Что делать с авансом: платёж по заказу до счёта и зачёт потом

Поставщики плитки, бордюра и щебня чаще всего требуют предоплату, а счёт и накладная приходят потом. В ERPNext это нормальный сценарий: Payment Entry можно создать напрямую из Purchase Order, не дожидаясь счёта. Деньги уходят, и в кредиторке по поставщику появляется аванс. На проведённом заказе нужно использовать то же меню Create, а в форме платежа вы увидите заказ в таблице References.

Когда приходит счёт, аванс нужно связать с ним. В документации ERPNext для этого описан механизм зачёта авансов: на черновике счёта подтягиваются доступные авансы того же контрагента, той же компании и той же валюты, либо позднее авансы применяются через Payment Reconciliation на уже проведённых счетах. В форме Purchase Invoice v15 это кнопка Get Advances Paid над таблицей Advances; в другой версии подпись может отличаться. Правило строгое: кредит применяется, только если совпадают контрагент, компания и счёт кредиторской задолженности.

Частый вопрос: что с остатком. Если вы заплатили больше, чем сумма счёта, переплата остаётся в поле Unallocated Amount платежа и висит в кредиторке как аванс. Ничего перепроводить не надо: при следующем счёте тот же механизм зачёта подтянет остаток. Если аванс нужно вернуть деньгами, делается отдельный платёж в обратную сторону через утверждённый документ, но это уже работа бухгалтера.

Чтобы не потерять аванс, я прошу бухгалтера раз в неделю делать три проверки: 1. Открыть платежи со ссылкой на заказ и убедиться, что по каждому есть счёт или понятная причина, почему его ещё нет. 2. Просмотреть платежи с ненулевым Unallocated Amount и решить: зачесть в ближайший счёт, оставить как аванс под следующую поставку или запросить возврат. 3. Сверить итог кредиторки по поставщику с актом сверки, который прислал сам поставщик.

Про налог на аванс. В Payment Entry есть таблица налогов и поля распределённой и нераспределённой суммы, но авансовый НДС по российским правилам на этом механизме из коробки не настроен, и под конкретного клиента я проверяю его на стенде. Я бы не обещал заказчику, что ERPNext «сам делает авансовый НДС по российским правилам». Налоговый учёт остаётся в бухгалтерии.

Один платёж на несколько счетов: комиссии, переплата и Unallocated Amount

В реальной жизни бухгалтер платит поставщику одной платёжкой за три счёта, и в банке стоит одна строка. В ERPNext это один Payment Entry: в таблице References распределяется сумма по нескольким счетам одного контрагента. Кнопка Get Outstanding Invoices подтягивает неоплаченные счета поставщика, и остаётся поправить суммы вручную. Сумма в Allocated Amount по каждой строке должна дать сумму платежа за вычетом нераспределённого остатка.

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

Разбор типовых ситуаций: | Ситуация | Что делаем в Payment Entry | Что получим | |---|---|---| | Платёж равен счёту | выбираем счёт в References | счёт Paid | | Платёж больше счёта | гасим счёт, остаток не распределяем | аванс в Unallocated Amount | | Один платёж за три счёта | распределяем сумму по строкам References | три счёта закрыты | | Платёж меньше счёта | указываем частичную сумму | счёт Partly Paid | | Банк списал комиссию | вносим в Deductions or Loss | нет «хвоста» | | Аванс до счёта | создаём платёж по Purchase Order | аванс виден в кредиторке |

Как согласовать платёж до списания денег: Payment Request и Workflow

Платёж — документ, после которого деньги уходят. Поэтому в компании на 12 человек я обычно вставляю согласование ещё до создания Payment Entry. В ERPNext для этого есть Payment Request: из проведённого Purchase Order или Purchase Invoice создаётся запрос типа Outward (исходящий). Важно понимать, что это именно запрос: по документации, Payment Request не двигает деньги и не создаёт проводки в главной книге. Платёж оформляется отдельно.

Согласование строится на стандартном механизме Workflow: статусы запроса и роли, которым разрешён переход. Типовая схема на малую компанию: снабженец создаёт запрос, руководитель утверждает, бухгалтер создаёт платёж. Для сумм до порога утверждение не нужно, для сумм выше — нужно. Порог и роли задаёт администратор; в коробке готовой пороговой схемы под ваш регламент нет, она настраивается. Утверждённые запросы могут собираться в Payment Order для централизованной обработки, это отдельный документ.

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

Что не делает Payment Request. Он не отправляет платёж в банк-клиент и не привозит выписку обратно. Выгрузка платёжных поручений в банк и загрузка выписок — отдельные интеграции, и обычно банк остаётся в 1С. Если вы ожидаете, что кнопка в ERPNext оплатит счёт в банке, этого не будет: в коробке нет российского банк-клиента.

Разбор: как «Брусчатка Мастер» перестала терять авансы поставщикам

Условный пример. Компания по благоустройству территорий «Брусчатка Мастер», 12 рабочих мест: укладка плитки и бордюра на объектах, закупки у семи поставщиков. Цифры ниже — иллюстрация. До внедрения авансы фиксировались в Excel, бухгалтер раз в месяц сверял список с банковской выпиской. Три аванса на тот момент не были соотнесены со счетами: деньги ушли, а счета поставщиков числились неоплаченными, и один поставщик выставил претензию о просрочке.

Мы настроили цепочку в ERPNext. Каждый аванс стал Payment Entry по Purchase Order. Счета вносились как Purchase Invoice со подтягиванием авансов. Просроченные счета видны по статусу Overdue, сверка по списку проходила раз в неделю вместо раза в месяц. Перед загрузкой остатков мы сверили три нераспределённых аванса вручную и закрыли их Payment Entry с привязкой к нужным счетам. Согласование платежей выше условного порога ввели через Payment Request и Workflow: руководитель утверждает запрос, бухгалтер проводит платёж.

Что показал первый месяц работы. Список Unallocated Amount по поставщикам показал, что у двух из семи есть неиспользованный остаток аванса, о котором бухгалтер помнил только по Excel. Остатки были зачтены в ближайшие счета. Одна ошибка при этом случилась и у нас: оператор включил Update Stock в счёте после ручной приёмки на склад, и по одной позиции остаток задвоился. Исправили отменой счёта и повторным проведением без этого флага. Показать такие документы можно на демостенде erp-demo.itfresh.ru по запросу.

Что уходит в 1С, а что ERPNext по НДС не берёт на себя

Главное, о чём предупреждаю бухгалтеров: Purchase Invoice в ERPNext — это не «счёт-фактура полученный» из 1С. Он фиксирует счёт и долг перед поставщиком, а приход на склад идёт отдельно через Purchase Receipt. Налоговый документ по НДС, книга покупок и вычеты остаются в бухгалтерии. Если вы вводите оба документа вручную в обеих системах, вы получаете двойную работу, и поэтому обмен нужно строить заранее.

Рабочая схема для компании, где бухгалтерия в 1С: односторонняя выгрузка утверждённых счетов поставщиков и контрагентов из ERPNext в 1С, а в обратную сторону подгружаются статусы оплат. Двусторонний коннектор реального времени мы не пишем: он дороже, а ошибки в нём стоят больше, чем выгрузка раз в день. Выгрузка делается через HTTP-сервисы или OData, без записи в SQL-базу 1С. Если вы выбираете систему под российский учёт, прочитайте и про Odoo и российскую локализацию, там тот же вопрос решён иначе.

Ограничения этого сценария. В коробке нет российского банк-клиента и форм платёжных поручений по формату банков. Нет автоматической проверки подлинности счёта: подделку счёта поставщика ERPNext не распознает, это вопрос процесса, и о нём полезно прочитать про мошенничество с подменой счёта поставщика. Если у поставщиков электронный документооборот, см. материал про обмен накладными по ЭДО. Сверка выписок с платежами — задача отдельного процесса, часть которого можно автоматизировать, как в разборе сверки выписок с помощью ИИ-агента.

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