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

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

О том, как отслеживается исполнение условий оплаты контрактов с поставщиками в «Северстали», расскажет Валерия Перова, консультант по SAP Material Management (SAP MM) центра информационных и коммуникационных технологий «Северсталь-инфоком».

У «Северстали» разнообразные условия оплаты, о которых компания договаривается с поставщиками и подрядчиками. Часто это не одна выплата. Нередко поставщики работают по предоплате, которая тоже может разделяться на несколько платежей. А ещё мы или нам могут оказывать услуги доставки, которые не входят в стоимость поставки товарно-материальных ценностей (ТМЦ), и оплачивается доставка иначе. В общем, отслеживать исполнение всевозможных вариантов оплат по договорам закупки не так-то просто — надо продумать логику.

Мы внедрили первую ERP на базе SAP ещё в 2011 году. Именно тогда и зародилась идея решения, которое сможет отслеживать исполнение условий оплаты закупочных контрактов. После разработки оно десять лет развивалось, обрастало дополнительными функциями, да не само по себе, а вместе с изменениями бизнес-процессов компании. В 2021 году мы перешли на SAP S/4HANA, но концептуальное решение переехало в новую систему в неизменном виде. Конечно, имел место рефакторинг технической реализации, но история не про это, а про то, как можно доработать настройку условий оплаты в SAP MM под характер платежей компании.

Стандартная настройка условий оплаты в SAP MM и чем она нам не нравилась

SAP, основываясь на лучших практиках, предоставляет стандартное решение для процесса закупок. Без особых подробностей оно выглядит так:

1. В системе можно создать такой элемент справочника, как условие платежа. Настройки позволяют задать ему скидки при оплате до указанного числа месяца, а также определить дату, с которой нужно отсчитывать указанные дни для расчёта даты оплаты. Это может быть, например, дата проводки, документа, ввода или просто конкретная дата какого-то месяца.

2. Созданное условие платежа будет указано в настройке справочника контрагентов для конкретного поставщика. Это можно указать на этапе создания контракта или заказа на поставку.

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

Что здесь не так? Концептуально сама идея ведения справочника условий платежа с настраиваемыми параметрами расчёта прекрасна. Но для решения задач контроля стандартная реализация справочника в закупочной части выглядела довольно ограниченно по следующим причинам:

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

• Невозможно организовать расчёт даты оплаты в зависимости от разных дат. Например, от даты перехода права собственности, акта выполненных работ и т. п. Весь отсчёт идёт от дат во входящем счёте.

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

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

Анализ стандартного справочника и наших требований показал, что дорабатывать однозначно придётся, вопрос — как?

Варианты сводились к двум концепциям:

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

2. Видоизменять справочник.

А дальше в обоих случаях надо разрабатывать наследования и контроли.

Как мы доработали условия платежей в SAP

Динамический конструктор — решение не самое плохое. В одной из вариаций у нас на нём живут пользователи 1C. Но всё-таки это SAP. Во-первых, при выборе решения не стоит забывать про особенности платформы, в которой оно будет реализовано (SAP). Во-вторых, условия платежа — это справочник, который предназначен не только для модуля закупок, но и для сбыта и финансов, поэтому надо сделать унифицированное решение для всех модулей, а не плодить разные реализации. Так мы склонились в пользу развития стандартного саповского справочника и внесения в него нужных нам условий платежа.

Структура элементов у стандартного справочника условий платежа и как мы её оптимизировали

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

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

• процент взноса в общей сумме документа;

• дни отсрочки платежа;

• форма оплаты (предоплата, постоплата);

• контрольное событие (определение, от даты какого системного документа отсчитывать дни отсрочки).

Получился справочник, который условно можно разделить на две группы: 

1. Простые или элементарные условия платежа — имеют один взнос со 100 %.

2. Составные — имеют более одного взноса. Сумма процентов всех взносов не может превышать 100 %.

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

Наш вариант использования условий оплаты на всех этапах закупки

Последующее использование справочника условий платежа в документах закупки в системе SAP MM выглядит следующим образом:

Контракт. В цифровой карточке контракта с поставщиком или подрядчиком указываются элементы справочника условий оплаты и сроки их действия. При этом они должны соответствовать прописанным в контракте условиям оплаты. Этот документ — основа, на которой зиждутся все последующие контроли.

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

Требование авансового платежа (ТАП). Если в спецификации предусмотрена предоплата, то можно заявить аванс для оплаты через документ ТАП. От стандартной транзакции ME2DP по вводу этого документа мы отказались, поскольку нам важно было реализовать контроль сумм авансов по взносам, соответствующим условиям платежа из спецификации. Для этого был разработан отдельный монитор, не позволяющий заявлять в оплату большую сумму, чем положено по её условиям.

Входящий счёт. При вводе входящего счёта от поставщика условие платежа наследуется из спецификации (и его нельзя изменить). Затем происходит автоматический расчёт базовой даты оплаты на основе атрибутов взносов условий платежа. Таким образом, если по договору необходимо выплатить сумму счёта двумя платежами, скажем, через 30 и 60 дней с даты счёта-фактуры, то у нас будет две позиции задолженности — каждая со своей датой оплаты.

Пример расчёта платежа в SAP «по-северстальному»

Допустим, мы договорились с поставщиком на покупку неких ТМЦ на сумму 10 000 р. без НДС. Платить за поставку мы будем по такому принципу: 

• авансовый платёж 10 % от стоимости ТМЦ в течение 15 дней с даты спецификации;

• авансовый платёж 30 % стоимости в течение 20 дней с даты спецификации;

• итоговый платёж в размере 60 % от стоимости ТМЦ в течение 30 дней с даты перехода права собственности.

В системе для регламентации такой оплаты должно быть создано соответствующее составное условие платежа с индикатором рассрочки (стандартный реквизит для сплиттинга) и тремя взносами (на схеме ниже это блок НСИ «Составное УП S002»), состоящее из трёх простых условий платежа (на схеме это блок НСИ «Простые условия» A001, A002 и К001).

Закупщик при создании договора в системе обязательно указывает код условия платежа S002 (на схеме — блок ММ «Договор на закупку ТМЦ»).

Далее в системе вводится заказ на поставку или спецификация (на схеме — блок MM «Заказ на поставку») на 10 000 р. без НДС от 01.10.2022. Условие платежа S002 унаследовано из договора, рассчиталась общая сумма аванса, по условиям 40 % от стоимости спецификации — это 4000 р. Плановая дата полностью выплачиваемого аванса — 19.10.2022. Второй аванс будет через 20 дней от даты спецификации, её отсчёт производим, включая саму начальную дату.

По указанному условию S002 заявляем в оплату с помощью ТАП (на схеме — блок FI, «Документы ТАП 1 и ТАП 2») отдельно 1000 р. + НДС c датой оплаты 14.10.2022 (первый взнос условия — 10 % от стоимости ТМЦ в течение 15 дней с даты спецификации). И отдельно заявляем 3000 р. + НДС с датой оплаты 19.02.2022 (второй взнос 30 % стоимости в течение 20 дней с даты спецификации). Заявить в оплату больше, чем положено по условиям контракта, возможности нет.

При отражении в системе факта поставки заполняется дата перехода права собственности. В рассматриваемом примере это 01.11.2022 (на схеме — блок MM «Документ поступления материала»). В стандартном варианте SAP такой даты нет, но у «Северстали» есть своё решение по автоматическому расчёту этой даты (о котором мы расскажем в другой статье).

После получения счёта-фактуры от поставщика на 12 000 р. с НДС в системе вводится документ входящего счёта (на схеме — блок MM «Входящий счёт») со ссылкой на заказ на поставку. В него копируется условие платежа из заказа S002 (сменить его нельзя). Базовая дата оплаты считается автоматически по постоплатному взносу 29.11.2022 — 60 % в течение 30 дней с даты перехода права собственности.

При проводке счёта создаётся бухгалтерский документ (на схеме — блок FI «Финансовый документ счёта»). В нём сумма счёта разделяется на три строчки по количеству взносов в условии платежа пропорционально процентам во взносах. У каждого взноса своя базовая дата оплаты, и предполагается, что первые две строки должны быть выровнены с авансами, а третья строка на 7200 р. — оплачивается.

В заключение: не обошлось без ложки дёгтя, но мы не расстроились

Надо сказать, что при первоначальной проработке решения в далёком 2011 году не было уделено должного внимания нормализации справочника условий платежа. Из-за этого через 10 лет мы получили непомерно разросшийся справочник и недовольство пользователей. При переходе в S/4HANA повторять ошибок предыдущего внедрения мы не стали. 

Для миграции справочника в новую систему наши команды НСИ, сбыта и закупок (как ИТ, так и бизнес) провели работу по удалению дубликатов. В расчёт брались только атрибуты элементов справочника. Если были условия с одинаковыми атрибутами и разным текстом, то мы оставляли только одно из них, а остальные блокировали. Помимо этого, ведение самого справочника было реализовано в системе SAP Master Data Governance с соблюдением принципов нормализации и передачей проверенных условий платежа в SAP ERP.

В ваших компаниях наверняка существуют свои решения по контролю платежей. Расскажите о них в комментариях, пожалуйста.