SAP SD: что он делает и где ломаются внедрения

SAP SD (Sales and Distribution, «Продажи и дистрибуция») обеспечивает в SAP цикл от заказа до оплаты: коммерческое предложение, заказ на продажу, поставка, выставление счёта и передача в финансы. В S/4HANA он меняется так, что это важно для объёма проекта. Клиенты становятся бизнес-партнёрами, управление кредитами переходит в SAP Credit Management, бонусы переходят в договоры условий, а выставление счетов проводится прямо в Universal Journal. Это руководство для руководителей по операциям продаж, финансовых контролёров и руководителей проектов, которым нужно знать, что делает SD и где он ломается. Короткий ответ на второй вопрос: основные данные клиентов, условия ценообразования, проверка доступности и определение счетов. Проверьте эти четыре вещи на реальных данных до go-live.

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

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

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

SD стоит в начале логистической цепочки. Он превращает интерес клиента в счёт через цепочку документов:

1. Запрос: клиент спрашивает цену или доступность
2. Коммерческое предложение: официальное предложение цены и поставки со сроком действия
3. Заказ на продажу: клиент берёт на себя обязательство, выполняется проверка доступности и подтверждается дата поставки
4. Поставка: склад комплектует и упаковывает; отпуск товара (goods issue) уменьшает запасы
5. Выставление счёта: создаётся счёт вместе с бухгалтерским документом
6. Оплата: финансы зачитывают входящий платёж против открытой позиции

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

1. 01ЗапросЗапрошены цена или доступность
2. 02Коммерческое предложениеОфициальное предложение со сроком действия
3. 03Заказ на продажуПроверка доступности подтверждает дату
4. 04ПоставкаКомплектация, упаковка, отпуск товара
5. 05Выставление счётаСчёт и бухгалтерский документ
6. 06ОплатаФинансы зачитывают открытую позицию

Каждый счёт прослеживается до исходного запроса

Когда цепочка выстроена хорошо, ручные передачи исчезают. Один производственный клиент сократил цикл от заказа до оплаты на 40 % после запуска SD, в основном за счёт устранения передач между продажами, складом и финансами.

Заказы на продажу и проверка доступности

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

Наиболее критична для бизнеса проверка available-to-promise (ATP). Она определяет, можно ли выполнить запрошенную дату за счёт запасов, запланированных поступлений и уже принятых обязательств. При правильной настройке продажи сообщают клиентам то, что система действительно может гарантировать. При неправильной сообщают то, на что надеются.

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

Ценообразование и условия

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

Технология условий SD (condition technique) обрабатывает базовые цены, скидки клиентам, скидки за объём, надбавки, фрахт и налог. Каждый элемент представляет собой вид условия с последовательностью доступа, а значение хранится в записи условия.

Самая частая проблема с ценообразованием, которую я вижу: старые условия цен со времён go-live, которые так и не обновили. Бизнес пересматривает скидку, никто не обновляет запись условия в SD, счёт получается неверным, и спор попадает в дебиторскую задолженность.

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

Отгрузка

Обработка поставок охватывает комплектацию, упаковку и отпуск товара. Ключевое событие: отпуск товара. Оно проводит уменьшение запасов, ставит поставку в список к выставлению счетов и фиксирует фактическую дату поставки. Определение пункта отгрузки и маршрута управляет тем, как создаются поставки. Компании со сложными сетями дистрибуции расширяют это с помощью SAP Transportation Management (TM).

Выставление счетов, определение счетов и налог

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

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

Управление кредитами

Кредитные проверки блокируют заказы, которые вывели бы клиента за кредитный лимит, или отмечают их. Это работает, только если лимиты поддерживаются. Статические лимиты, заданные при go-live, перестают что-либо значить по мере изменения платёжного поведения и объёмов.

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

Это не управление кредитами. Это обходной путь.

Вот элементы структуры SD и то, с чем каждый из них связан.

Элемент структуры	Назначение в SAP SD	Ключевая связь
Организация сбыта	Верхнеуровневая торговая единица, отвечающая за условия продаж и ответственность	Назначается балансовой единице (company code) в FI
Канал сбыта	Как продукция попадает к клиенту (опт, розница, прямые продажи)	Управляет ценообразованием, основными данными и определением партнёров
Сектор	Группа продуктов внутри организации сбыта	Группировка материалов для отчётности и вывода документов
Область сбыта	Организация сбыта, канал сбыта и сектор вместе	Обязательна для каждого документа сбыта и каждой записи клиента
Служба сбыта	Географическая единица сбыта	Региональная отчётность и определение партнёров
Группа сбыта	Команда внутри службы сбыта	Ответственный по заказам
Пункт отгрузки	Место, откуда отгружаются товары	Связывает SD со складским управлением и транспортом
Завод	Производящая или поставляющая единица	Источник запасов, связан с пунктом отгрузки

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

Если вы переходите с ECC, вот изменения в SD, которые нужно заложить в объём. В документации по S/4HANA SAP относит эту область к «Продажам» (Sales), хотя большинство команд по-прежнему называют её SD.

ECCS/4HANA

КлиентыECCЗапись основных данных клиентаS/4HANAБизнес-партнёр с ролью клиента

Управление кредитамиECCFI-AR-CRS/4HANASAP Credit Management (FIN-FSCM-CR), не опционально

БонусыECCОбработка бонусов SD, перестраиваемая из индексаS/4HANAДоговоры условий в Settlement Management

Проверка доступностиECCБазовая проверка доступности продуктаS/4HANAAdvanced ATP: распределение, невыполненные заказы, альтернативные заводы

Выставление счетовECCFI и CO сверяются отдельноS/4HANAОдна позиция в Universal Journal (ACDOCA)

Признание выручкиECCСобственная логика отсрочки во многих программахS/4HANASAP Revenue Accounting and Reporting, лицензируется отдельно

1. Клиенты становятся бизнес-партнёрами. Основные данные клиента ведутся через бизнес-партнёра с ролью клиента. При конверсии интеграцию клиентов и поставщиков (customer-vendor integration) нужно настроить до запуска конверсии.
2. Управление кредитами переходит в SAP Credit Management. Управление кредитами ECC (FI-AR-CR) в S/4HANA недоступно. Его заменой служит SAP Credit Management (FIN-FSCM-CR), поэтому при конверсии нужно мигрировать кредитные данные и настройки. Это не опция.
3. Бонусы переходят в договоры условий. Классическая обработка бонусов SD заменяется Settlement Management (управление договорами условий). Условия бонусов применяются сразу, а не перестраиваются из индекса.
4. Advanced ATP. Advanced ATP в S/4HANA добавляет распределение продукта, обработку невыполненных заказов, подтверждение на основе альтернатив по разным заводам, освобождение к поставке и назначение поставок. В S/4HANA Cloud эти функции входят в стандартную лицензию. В on-premise после активации для них нужна отдельная лицензия.
5. Выставление счетов проводится в Universal Journal. FI, CO и анализ маржи используют одну позицию в ACDOCA, что снимает работу по сверке FI и CO, знакомую по ECC. Обратная сторона: ошибка в определении счетов превращается в немедленную проводку не на тот счёт, видимую на уровне позиции.
6. Признание выручки. Для договоров с несколькими элементами, подписок или долгосрочных услуг по IFRS 15 SAP Revenue Accounting and Reporting заменяет собственную логику отсрочки, которую построили многие программы на ECC. Он лицензируется отдельно, и его нужно проектировать до go-live, а не обнаруживать при годовом закрытии.

Clean Core меняет подход к доработкам SD. В public cloud собственный код в ядре невозможен. В private cloud и on-premise он возможен, но каждое обновление от этого становится сложнее. Большинство старых Z-процедур ценообразования можно заменить стандартными видами условий, формулами и BAdI. То, что действительно остаётся, относится к расширению side-by-side на SAP BTP. Мой гайд по Clean Core описывает это решение.

SD и MM

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

SD и PP

В сценариях make-to-order заказ на продажу может напрямую запускать производство, поэтому подтверждённая дата становится обязательством, подкреплённым производственным заказом. Группа стратегий в основных данных материала определяет, как взаимодействуют заказы на продажу и прогнозы. Если задать её неверно, они суммируются вместо того, чтобы взаимно зачитываться, плановый прогон завышает спрос, и следует перепроизводство. Мой гайд по SAP PP охватывает сторону планирования.

SD и FI

Интерфейсом служит документ выставления счёта. Каждый счёт создаёт бухгалтерский документ, который проводит выручку, налог и открытую позицию клиента в Universal Journal. Условия оплаты в основных данных клиента определяют срок платежа. Когда продажи договариваются об условиях, не сообщив финансам, система применяет условия, которые финансы никогда не согласовывали.

Если дизайн SD исходит из того, что вся выручка признаётся при выставлении счёта, а договоры говорят иное, переделка обходится дорого. Согласуйте признание выручки с финансами до того, как дизайн будет подписан. О финансовой стороне интеграции см. мой гайд по SAP FICO.

Четыре точки отказа вызывают большую часть проблем после go-live.

Основные данные клиентов не готовы. Каждое поле важно на следующих шагах. Отсутствие налоговой классификации означает неверный налог. Отсутствие условий оплаты означает, что FI не может рассчитать сроки платежей. Отсутствие условий отгрузки ломает планирование поставок. Объёмы больше, а исходные данные хуже, чем предполагает план, и очистка требует бизнес-решений. Начинайте рано и относитесь к этому как к бизнес-потоку, а не к технической загрузке. Мой материал о том, почему миграция данных SAP не удаётся, описывает метод.

Условия ценообразования не поддерживаются. Условия, заданные при go-live, которые никто не пересматривает, в течение первого года превращаются в споры по счетам.

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

Пробелы в определении счетов находят после go-live. Тестируйте на фактическом плане счетов, налоговых кодах и группах материалов. Несоответствующие налоговые коды могут блокировать заказы или вызывать споры по счетам до того, как кто-либо поймёт, что не так.

Эту таблицу я бы проходил как чек-лист перед подписанием UAT.

Риск	Влияние	Меры снижения
Неполные основные данные клиентов	Ошибки в счетах, сбои поставок, пробелы в проводках FI	Рано начать работу с данными; до миграции определить обязательные поля для каждой области сбыта
Устаревшие условия ценообразования	Споры по счетам, неверная выручка	Назначить владельца записей условий и цикл пересмотра при go-live
ATP не связан с PP или MM	Ненадёжные обещания по срокам поставки	Протестировать ATP на живых сценариях планирования до подписания UAT
Пробелы в определении счетов	Выручка проводится не на те счета	Тестировать на реальном плане счетов и полном наборе налоговых кодов
Снятие кредитных блокировок как рутина	Неконтролируемый риск, споры по дебиторской задолженности	Обеспечить пересмотр лимитов; отслеживать ручные снятия в первые 90 дней
Вывод документов не протестирован	Счета и накладные не отправляются автоматически	Протестировать каждый вид вывода с реальной маршрутизацией печати и электронной почты до go-live
Несогласованные условия оплаты	Неверные сроки платежей, ошибки прогноза денежных средств	Согласовать условия между продажами и финансами до загрузки данных клиентов

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

Что такое SAP SD и что он делает?

SAP SD (Sales and Distribution) управляет циклом от заказа до оплаты: запросами, коммерческими предложениями, заказами на продажу, поставками, выставлением счетов и передачей в финансовый учёт. Поток документов связывает каждый шаг с предыдущим, поэтому любой счёт можно проследить до исходного заказа. Он интегрируется с MM для запасов и отпуска товара, с PP для make-to-order и доступности и с FI для выручки, налога и дебиторской задолженности.

Какова организационная структура в SAP SD?

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

Как работает ценообразование в SAP SD?

Ценообразование использует технологию условий. Каждый элемент цены представляет собой вид условия, последовательность доступа решает, какая запись условия применяется, а схема ценообразования объединяет виды условий по порядку. Большинство споров о ценах происходит из записей условий, которые не обновили при изменении коммерческих условий, а не из ошибок настройки.

Что такое advanced ATP в SAP S/4HANA?

Advanced available-to-promise (aATP) это проверка доступности в S/4HANA. Помимо базовой проверки доступности продукта, она добавляет распределение продукта, обработку невыполненных заказов, подтверждение на основе альтернатив по разным заводам, освобождение к поставке и назначение поставок. Эти функции включены в S/4HANA Cloud, а в on-premise после активации для них нужна отдельная лицензия. Используйте их там, где предложение ограничено или важны правила распределения. Для стабильных цепочек поставок хорошо настроенной базовой проверки часто достаточно.

Как SAP SD интегрируется с финансовым учётом?

Через документ выставления счёта. Передача документа выставления счёта в бухгалтерию создаёт проводку по выручке, налогу и открытой позиции клиента. Определение счетов выбирает счета главной книги по организации сбыта, группам назначения счетов и виду условия. Налог зависит от налоговых классификаций клиента и материала. Условия оплаты в основных данных клиента задают срок платежа. Для случаев IFRS 15 SAP Revenue Accounting and Reporting откладывает и признаёт выручку с течением времени.

Что меняется в SAP SD при переходе с ECC на S/4HANA?

Клиенты становятся бизнес-партнёрами. Управление кредитами переходит из FI-AR-CR в SAP Credit Management, и это обязательно. Обработка бонусов заменяется договорами условий в Settlement Management. Появляется advanced ATP, а выставление счетов проводится в Universal Journal. Заложите всё это в объём заранее, потому что каждое изменение требует настройки, миграции данных и тестирования.

Каковы самые частые ошибки внедрения SAP SD?

Пять повторяются снова и снова. Недооценка основных данных клиентов. Отсутствие владельца у условий ценообразования после go-live. Тестирование ATP только на чистых данных. Тестирование определения счетов на упрощённых данных. Отсутствие сквозного тестирования вывода документов. Последнее легко упустить. Когда счета не уходят автоматически, кто-то начинает распечатывать их вручную, и обходной путь становится постоянным.