Настоящий текст (статьей его назвать сложно) не откроет страшных тайн и не перевернет вселенную САП-ёра с ног на голову. Пишу это, дабы по прочтению, коллеги не стали ругать автора за никчемность выбранной для освещения темы и тривиальность описанных подходов. Короче говоря, соломки себе подстелю, чтобы падать удобно было.
Итак, сектор и вид торгового документа, как их использовать, чтобы всем было хорошо, и чтобы, в случае появления каких-то нюансов в бизнесе клиента (выпадающих из общего потока уже настроенных бизнес-операций) возникшие из-за этих нюансов проблемы можно было бы относительно безболезненно для системы разрулить.
Для начала, давайте придумаем пример виртуального клиента, под которого мы будем настраивать систему. В качестве «подопытного» беру компанию, которая осуществляет свою деятельность по следующим основным направлениям:
Регион сбыта исключительно местный (экспорта нет).
Сразу оговорюсь, что все данные – модельные (беру из своей головы), и совпадение моего демонстрационного примера с реально существующим бизнесом будет являться чистой случайностью.
Мысленно потирая ручонки (не знаю, как Вы, но я, начиная настройку любого проекта с нуля, всегда очень воодушевлен и оптимистичен), беремся за дело.
Выделяем следующие сектора:
Формируем 4 рынка сбыта 1000-01-01, 1000-01-02, 1000-01-03 и 1000-01-04.
По видам торговых документов (пусть речь идет о договорах) предлагаю такую структуру:
Через 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 «Ошибка»). Почему так может быть сделано? Причин сколь
Для прочтения полной версии статьи необходимо зайти как зарегистрированный пользователь.
Марат Дандыбаев (Рейтинг: 45) 06:33, 01 марта 2017
Пока никому не понравилось
Тимур Баймульдин (Рейтинг: 531)
А я тут :)
Пока никому не понравилось
Константин Локшин (Рейтинг: 128) 09:50, 01 марта 2017
Первая часть показывает наглядно ошибки мышления начинающего консультанта, вторая знакомит с правильными вопросами, пусть и не дает на них ответа.
Что важно, на мой взгляд:
1. Предложенный вариант настроек (отдельные виды контрактов по секторам) несет существенные ограничения - нельзя в одном сбытовом документе продать материалы и услуги (а что может быть естественнее для строительной организации?
2. Присвоение сектора карточкам материала - плохое решение. Тут надо задуматься о соответствии сектора группе материалов. Могут ли материалы одной группы принадлежать разным секторам?
Ответ да - плохой, так как получается две аналитики, группирующие код материала и более крупная (сектор) не определяется однозначно по более мелкой (группе материалов).
Ответ нет - тоже плохой, потому что тогда нет смысла хранить сектор в карточке материала, достаточно сделать таблицу меппинга группа материалов - сектор и использовать ее в аналитике.
Вообще, сектор во многих случаях - вырожденная аналитика.
Например, в отраслевом решении SAP Retail в документации прямо рекомендовано использовать всегда один сектор, и вместо этого использовать иерархию групп материалов.
Понравилось 1 человеку
Тимур Баймульдин (Рейтинг: 531)
По мне, вариант решения, когда сектор один, а в качестве аналитики используется группа или иерархия материалов - тоже несет в себе определенные ограничения. Но, если рассматривать именно тот пример, что я описал, то да, вероятно, это было бы оптимальным вариантом. Все зависит от нюансов бизнеса. А охватить и описать все такие нюансы, а тем более продумать схему реализации - задача непосильная... :)
Пока никому не понравилось
Мурат Бажанов (Рейтинг: 210) 19:10, 01 марта 2017
Ждем следующих публикаций! Удачи!
Пока никому не понравилось
Тимур Баймульдин (Рейтинг: 531)
Пока никому не понравилось