Меню

Сектор vs Вид торгового документа

|

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

Вступление

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

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

Направления деятельности «модельного» Клиента

Для начала, давайте придумаем пример виртуального клиента, под которого мы будем настраивать систему. В качестве «подопытного» беру компанию, которая осуществляет свою деятельность по следующим основным направлениям:

  • Оптовая реализация строительных материалов;
  • Оказание работ/услуг по строительству объектов «под ключ»;
  • Оказание услуг по ремонту помещений (косметический и капитальный ремонт);
  • Прочее (продажа неликвидов, оказание работ/услуг, не подпадающих под п.2 и 3).

Регион сбыта исключительно местный (экспорта нет).

Сразу оговорюсь, что все данные – модельные (беру из своей головы), и совпадение моего демонстрационного примера с реально существующим бизнесом будет являться чистой случайностью.

Методика настройки модели

Шаг первый. Идентификация рынков сбыта и определение Видов ТД.

Мысленно потирая ручонки (не знаю, как Вы, но я, начиная настройку любого проекта с нуля, всегда очень воодушевлен и оптимистичен), беремся за дело.

Выделяем следующие сектора:

  • Сектор 01 – Реализация стройматериалов;
  • Сектор 02 – Строительство;
  • Сектор 03 – Ремонты;
  • Сектор 04 – Прочее.

Формируем 4 рынка сбыта 1000-01-01, 1000-01-02, 1000-01-03 и 1000-01-04.

По видам торговых документов (пусть речь идет о договорах) предлагаю такую структуру:

  • Z01 – количественный контракт на реализацию основной продукции (за базу берем количественный контракт (КМ для языка RU, или CQдля EN));
  • Z02 – контракт на услуги (копия вида ТД WV – «Сервис и ТО»);
  • Z03 – контракт (прочее).

Через Z01 будет проходить реализация материалов/товаров, относящихся к сектору 01. Через Z02 – мы продаем услуги строительства (сектор 02) и ремонтов (сектор (03)). Может быть задан вопрос, почему не продавать услуги также через Z01? Можно, конечно. Но учитывая, что в первом случае мы продаем товар, а во втором и третьем - работы/услуги, может потребоваться принципиально иная реакция системы при создании торгового документа. Например, по Z01 может происходить передача потребности, тогда как по Z02 этого быть не должно. Как описано выше (виды торговых документов), за базу для Z02 берем вид ТД WV. В сбытовом потоке будет всего 2 документа: контракт и фактура (ежемесячно). В документе логичнее использовать частичный план фактурирования. Как вариант, услуги строительства и ремонтов можно реализовать через динамические позиции (фактурирование на основании затрат). Не принципиально, мы делаем упор на том, что для реализации стройматериалов (основной вид деятельности №1) и выполнения услуг (виды деятельности 2 и 3) в системе будут использоваться разные виды документов (договоров).

К прочим продуктам (работам/услугам), которые «идут» под сектором 04 будет применяться вид договора Z03. Опять же, может быть вопрос, чем Z01 для этого плох? Предпосылок для выделения отдельного вида ТД Z03 может быть море, к примеру, необходимость более простой схемы неполноты данных.

Шаг второй. Присвоение Видов ТД рынкам сбыта.

Суть операции – определить какие виды торговых документов по каким рынкам сбыта будут работать. Эта настройка относится к разряду необязательных. Т.е. ее можно и не делать. В таком случае любой вид ТД можно будет создать по любому рынку сбыта. С одной стороны, чем проще, тем лучше. С другой, - эта настройкапоможет избежать глупых пользовательских ошибок. Когда для конкретного вида документа определен конкретный рынок сбыта, завести документ по другому рынку сбыта, система не даст. Своего рода «защита от дурака».

Перед тем как сделать присвоение видов ТД рынкам сбыта, система предлагает объединить организационные элементы: сбытовые организации, каналы сбыта и сектора. Вспоминая свой первый опыт в качестве консультанта, я не особо заморачивался по поводу этой настройки. Т.е., не мудрствуя лукаво, я делал соответствие реального и ссылочного орг.элементакак 1 : 1. В нашем случае, когда сбытовая организация одна и канал сбыта также один, возможность определить ссылочный орг.элемент имеется только для сектора. Если исповедовать мой «раннеконсультантский» подход, то на выходе получаем очень простую таблицу (Табл. 1):

Табл.1. Определение ссылочного орг. элемента

Хотел бы отметить, что объединение сбытовых организаций, каналов и секторов для «привязки» их к видам торговых документов – это данные таблицы TVTA. Причем, эти данные – далеко не вся таблица. Учитывая, что TVTA также имеет отношение к нашей теме, было бы неплохо остановиться на ней подробнее. Однако, давайте вернемся к этому вопросу чуть позже.

Продолжаем тему «присвоения» видов ТД рынкам сбыта. Можно немного заморочиться и сделать для сектора 03 ссылочный сектор 02. Что это нам даст? Это немного упростит нам жизнь, и уменьшит нашу таблицу присвоения, на одну строку (Табл. 2):

Табл.2. Оптимизация таблицы присвоения видов ТД рынкам сбыта

Не ахти какая оптимизация? Однако, если абстрагироваться от нашего виртуального клиента, и предположить, что у вас 15 рынков сбыта и 25 видов торговых документов (запросы, предложения, договора, заказы и т.д.). Количество строк в таблице TVTA будет равно 15 * 25. Если же грамотно подойти к определению ссылочных орг. элементов, то последующая операция по присвоению ТД рынкам сбыта будет не столь трудозатратна, а количество строк таблицы будет меньше в несколько раз.

Шаг третий. Дополнительная конфигурация.

Для определения будущей схемы взаимодействия «сектор – вид ТД» необходимо решить еще пару моментов.

1. Будет ли использоваться поле «Сектор» в Основной записи материала, и будет ли оно обязательным для заполнения? (Рис. 1 и 2):

Рис.1. Ведение поля «Сектор» в основной записи материала

Рис.2. Ведение поля «Сектор» в основной записи материала

2. Каким будет значение поля Проверка сектора для вида торгового документа, и откуда будет тянуться код сектора в момент обработки ТД (поле Сектор/позиция) (рис. 3).

Рис.3. Проверки, касающиеся Сектора в настройке вида торгового документа.

Допустим, мы решаем, что сектор в ОЗМ будет полем, обязательным для заполнения. Это может быть связано с получением отчетности в разрезе данной аналитики. Будет логичным предположить, что, в таком случае, необходимо копировать значение сектора из ОЗМ в позицию торгового документа. Т.е. для поля Сектор/позиция в настройке вида ТД галка будет стоять. По полю Проверка сектора, мы решаем, что для всех используемых видов торговых документов, при проверке, система не допускает ситуацию, когда сектор заголовка и сектора позиций имеют различные значения (опция 2 «Ошибка»). Почему так может быть сделано? Причин сколь

Если хотите прочитать статью полностью и оставить свои комментарии присоединяйтесь к sapland

У вас уже есть учетная запись?

Войти

Обсуждения Количество комментариев6

Комментарий от  

Марат Дандыбаев

  |  01 марта 2017, 06:33

Здарова! Тимур. Не ожидал тебя тут увидеть :)

Комментарий от  

Константин Локшин

  |  01 марта 2017, 09:50

Отличная статья.
 
Первая часть показывает наглядно ошибки мышления начинающего консультанта, вторая знакомит с правильными вопросами, пусть и не дает на них ответа.
 
Что важно, на мой взгляд:
1. Предложенный вариант настроек (отдельные виды контрактов по секторам) несет существенные ограничения - нельзя в одном сбытовом документе продать материалы и услуги (а что может быть естественнее для строительной организации?
 
2. Присвоение сектора карточкам материала - плохое решение. Тут надо задуматься о соответствии сектора группе материалов. Могут ли материалы одной группы принадлежать разным секторам?
Ответ да - плохой, так как получается две аналитики, группирующие код материала и более крупная (сектор) не определяется однозначно по более мелкой (группе материалов).
Ответ нет - тоже плохой, потому что тогда нет смысла хранить сектор в карточке материала, достаточно сделать таблицу меппинга группа материалов - сектор и использовать ее в аналитике.
 
Вообще, сектор во многих случаях - вырожденная аналитика.
Например, в отраслевом решении SAP Retail в документации прямо рекомендовано использовать всегда один сектор, и вместо этого использовать иерархию групп материалов.

Комментарий от  

Мурат Бажанов

  |  01 марта 2017, 19:10

Молодец Тимур!
Ждем следующих публикаций! Удачи!

Комментарий от  

Тимур Баймульдин

  |  14 марта 2017, 06:39

Отличная статья.
 
Первая часть показывает наглядно ошибки мышления начинающего консультанта, вторая знакомит с правильными вопросами, пусть и не дает на них ответа.
 
Что важно, на мой взгляд:
1. Предложенный вариант настроек (отдельные виды контрактов по секторам) несет существенные ограничения - нельзя в одном сбытовом документе продать материалы и услуги (а что может быть естественнее для строительной организации?
 
2. Присвоение сектора карточкам материала - плохое решение. Тут надо задуматься о соответствии сектора группе материалов. Могут ли материалы одной группы принадлежать разным секторам?
Ответ да - плохой, так как получается две аналитики, группирующие код материала и более крупная (сектор) не определяется однозначно по более мелкой (группе материалов).
Ответ нет - тоже плохой, потому что тогда нет смысла хранить сектор в карточке материала, достаточно сделать таблицу меппинга группа материалов - сектор и использовать ее в аналитике.
 
Вообще, сектор во многих случаях - вырожденная аналитика.
Например, в отраслевом решении SAP Retail в документации прямо рекомендовано использовать всегда один сектор, и вместо этого использовать иерархию групп материалов.

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

Комментарий от  

Тимур Баймульдин

  |  14 марта 2017, 06:43

Здарова! Тимур. Не ожидал тебя тут увидеть :)

Привет!
А я тут :)

Комментарий от  

Тимур Баймульдин

  |  14 марта 2017, 06:43

Молодец Тимур!
Ждем следующих публикаций! Удачи!

Спасибо, Мурат!