Почему график платежей развалился на полпути
Компания работает с поставщиком сырья, подписала договор на поставку материалов. В договоре указано: 30% авансом при заказе, 40% при отгрузке, 30% через 10 дней после поступления товара. Звучит логично, но проблема проявилась в реальной работе.
Менеджер по закупкам создаёт очередной заказ поставщику. Он вводит сумму, но никаких графиков платежей в самом заказе нет. Бухгалтер потом вручную переписывает условия из договора в платежные реестры. Финансист не знает, когда ждать оттока денег. Поставщик периодически требует уточнения по срокам. Процесс разворовывается.
Вот почему в 1С:ERP есть механизм переноса графика платежей из договора прямо в заказ поставщику. Но это работает только если всё настроено правильно. Разберём, где чаще всего ломается.
Договор без платежного календаря
Менеджер по закупкам открывает карточку договора поставщика. Видит реквизиты контрагента, условия доставки, но места для графика платежей нет. Он начинает искать в интерфейсе, где это заполнять, и либо пропускает этап полностью, либо пишет условия в примечание.
Результат: когда позже создаётся заказ поставщику, система не может подтянуть график платежей, потому что его просто нет в договоре.
Как это работает в реальности:
В договоре с поставщиком нужно предусмотреть табличную часть с графиком оплаты. Там заполняются:
- порядковый номер этапа платежа
- срок в днях (или конкретная дата)
- вариант отсчёта (от даты заказа, от даты отгрузки, от даты поступления)
- процент или сумма платежа
- форма оплаты (банковский перевод, чек, наличные)
Главный нюанс: вариант отсчёта нужно выбирать исходя из логики бизнеса. Если вы платите авансом, отсчёт идёт от даты самого заказа. Если платите при отгрузке, отсчёт должен быть от даты отгрузки товара. Если платите после поступления, отсчёт от даты поступления. Если смешать, система рассчитает даты платежей неправильно.
Часто менеджеры забывают, что договор это не просто юридический документ. Договор в 1С:ERP это ещё и источник данных для расчётов. Если в договоре неполная информация, остальные процессы сломаются.
Заказы с рассогласованными сроками оплаты
Договор готов, график платежей в нём заполнен. Менеджер по закупкам создаёт первый заказ поставщику и видит кнопку «Заполнить график оплаты по договору». Нажимает. График платежей подтягивается в заказ. Казалось бы, проблема решена.
Но потом приходит второй заказ у того же поставщика. Менеджер спешит, забывает нажать эту кнопку, и в заказе остаётся старый или вообще какой-то случайный график. Бухгалтер заметит это только при проведении. Или не заметит.
Параллельно возникает другая проблема: условия с поставщиком иногда меняются. Для одного заказа он согласен на 20% авансом, для другого требует 50%. Если менеджер переносит график из договора, получается рассогласование с реальными условиями конкретного заказа.
Как это работает в реальности:
Когда нажимаете кнопку «Заполнить график оплаты по договору», система проверяет, указан ли в документе реквизит «Договор». Если договор не указан, кнопка просто ничего не делает.
После нажатия система:
- очищает текущий график оплат в заказе (все старые строки удаляются)
- копирует свежие строки из договора
- копирует все параметры платежей: номер, срок, вариант отсчёта, контроль, процент, форму оплаты
Главный нюанс: кнопка копирует данные в момент, когда вы её нажимаете. Если договор обновился после создания заказа, вы это не видите. Нужно вручную нажать кнопку снова.
В практике это значит, что нельзя полностью положиться на автоматизм. Менеджер должен всегда проверить: совпадают ли условия в заказе с тем, что вы договорились с поставщиком на этот раз. Если поставщик попросил другие сроки платежей для этого конкретного заказа, график нужно отредактировать вручную после копирования.
Частая ошибка: менеджеры копируют график, но не проверяют расчётные суммы. Если сумма заказа отличается от типовой, проценты в графике будут считаться от неправильной базы.
Автоматический расчёт дат платежей, который считает неправильно
Графики платежей скопированы в заказы. Теперь нужно рассчитать конкретные даты, когда нужно внести каждый платёж. Вот здесь начинаются вычислительные ошибки.
Менеджер создал заказ 10 января. Договор говорит: первый платёж через 5 дней. Система должна рассчитать 15 января. Но дальше сложнее: второй платёж «при отгрузке». Дата отгрузки неизвестна на момент создания заказа. Третий платёж через 10 дней после поступления товара. А товар может прийти с задержкой.
Если система просто берёт и считает от даты заказа для всех платежей, получится:
- первый платёж: 15 января (5 дней от заказа) ✓
- второй платёж: 20 января (10 дней от заказа) ✗ (должен быть от отгрузки)
- третий платёж: 30 января (20 дней от заказа) ✗ (должен быть от поступления)
Финансист будет думать, что нужно заплатить 20 января, но товара ещё нет. Потом он поймёт ошибку и попытается пересчитать. Бухгалтер и поставщик будут в разных реальностях.
Как это работает в реальности:
Система автоматически рассчитывает даты платежей по каждой строке графика на основании варианта отсчёта, который вы указали в договоре.
Если вариант отсчёта «от даты заказа», дата платежа рассчитывается от даты документа заказа плюс количество дней.
Если вариант отсчёта «от даты отгрузки», система должна взять дату из документа отгрузки (когда товар уехал со склада поставщика). Эта дата проставляется позже, при поступлении информации об отгрузке.
Если вариант отсчёта «от даты поступления», система берёт дату поступления товара на ваш склад. Она фиксируется, когда вы приходуете товар.
Главный нюанс: даты отгрузки и поступления могут быть неизвестны на момент создания заказа. Система тогда показывает расчётную дату (которая пока неправильная), а потом пересчитывает её, когда появляются реальные факты.
Если вы не заполнили дату отгрузки в системе, платёж будет считаться от даты заказа. Товар приходит, а вы не отметили в системе дату, когда он уехал от поставщика. Платёж считается неправильно. Финансист ждёт платить в один день, а по договору это должно быть в другой.
На практике это означает: нужно убедиться, что дата отгрузки от поставщика попадает в систему. Это может быть либо УПД поставщика, либо отдельная накладная, либо информация от поставщика, которую менеджер вносит в заказ. Без этой даты графики платежей считаются с ошибками.
Отсутствие контроля над этапами платежей
Графики считаются, даты платежей известны. Но никто не следит, когда их выполнять. Финансист посмотрел на платёж на 25 января, заплатил в срок. Бухгалтер согласовал с поставщиком, что это ОК. Но для четырёх других заказов сроки прошли незаметно, расчёты начали пробуксовывать.
Почему? Потому что график платежей это просто таблица с суммами и датами. Если её никто не мониторит, она остаётся на бумаге (или в экране монитора). Никто не знает, какие платежи уже сделаны, какие ещё в очереди, какие просрочены.
Как это работает в реальности:
В графике платежей для каждой строки есть поле контроля. Это может быть флаг, статус или просто заметка о выполнении.
Когда вы проводите платёж по счёту поставщика, вы должны связать его с соответствующей строкой в графике. Система тогда отмечает, что этот этап платежа выполнен. На следующем этапе финансист видит, какие платежи уже сделаны, и концентрируется на оставшихся.
Главный нюанс: эта связь не создаётся автоматически. Нужно либо вручную указать в графике, что платёж проведён, либо система должна быть настроена так, чтобы автоматически искать проведённые платёжи по сумме и дате.
На практике много компаний пропускают этот шаг. Они создают график, копируют его в заказ, но потом никогда не возвращаются к этой таблице, чтобы отметить выполненные платежи. В результате финансист не знает, платил ли он уже авансом для заказа №5 или нет. Нужно искать в выписке банка. Теряется время.
Правильный процесс: менеджер по закупкам или финансист должен регулярно проверять неоплаченные графики платежей. Видеть, какие сроки приближаются. И отмечать, когда платёж сделан.
Что получилось в итоге
После того как все четыре настройки были реализованы правильно, в компании изменилось следующее:
- Финансовое планирование стало предсказуемым.
Вместо того чтобы гадать, когда нужны деньги поставщикам, финансист видит реестр платежей с точными датами. Он может спланировать кассу на месяц вперёд.
- Задолженность перед поставщиками снизилась.
Раньше платежи то и дело просрочивались, потому что в системе было неясно, когда их делать. Теперь каждый платёж привязан к конкретной дате и статусу. Графики платежей это не рекомендация, а план действий.
- Взаиморасчёты с поставщиками упростились.
Поставщик звонит и спрашивает: «Когда вы нам заплатите?» Менеджер открывает заказ, видит график платежей с датами и статусами, и дает точный ответ. Без гадания.
- Себестоимость заказа стала корректной.
Когда вы знаете, когда платите авансом, а когда после поступления, это влияет на учёт затрат. Авансовый платёж это не расход, это авансовое обслуживание. Платёж после поступления это уже себестоимость. Разница критична для управленческой отчётности.
- Бухгалтерия и финансы наконец говорят на одном языке.
Раньше бухгалтер проводил счета поставщика, а финансист готовил кассовый прогноз, и цифры не совпадали. Теперь граф платежей это единый источник истины для обоих.
Главное: это не магия автоматизации. Система помогает, но только если вы правильно заполнили договоры, правильно выбрали варианты отсчёта платежей, и потом регулярно отмечаете выполненные платежи. Если пропустить хотя бы одно, график развалится.
