Вступление

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

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

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

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

• Оптовая реализация строительных материалов;
• Оказание работ/услуг по строительству объектов «под ключ»;
• Оказание услуг по ремонту помещений (косметический и капитальный ремонт);
• Прочее (продажа неликвидов, оказание работ/услуг, не подпадающих под п.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 «Ошибка»). Почему так может быть сделано? Причин сколь