Создание собственного шага для записи условия в схеме калькуляции заказа на закупку
В статье изложен принцип настройки собственного шага записи условия для схемы калькуляции заказов на закупку. Рассмотрен вариант произвольного формирования начального условия цены PB00, на основе ссылочных заявок на закупку.
Аннотация
В статье изложен принцип настройки собственного шага записи условия для схемы калькуляции заказов на закупку. Рассмотрен вариант произвольного формирования начального условия цены PB00, на основе ссылочных заявок на закупку.
1. Описание проблемы
Стандартно, в заказах на закупку используется схема калькуляции: RM0000 - Документ закупок. Для формирования базовой цены существует код условия: PB00 - Цена брутто, сумма данного поля может формироваться исходя из множества условий. В стандартной схеме калькуляции обычно введен набор вариантов определения цены, при этом доступ к условиям задан монопольным, это значит, что как только одно из условий выполнилось, система считает, что базовая цена определена и дальше можно выполнять остальные условия из схемы, например, расчет НДС от базовой суммы и т.д. На рисунке 1-1, показана часть стандартной схемы калькуляции.
Рисунок 1‑1. Часть стандартной схемы калькуляции
Как видим, система сначала попытается определить цену в зависимости от цены тары, шаг 005, далее, будет попытка определения цены из позиции контракта ММ в зависимости от кода завода, шаг 010 и т.д. Как только цена будет найдена, система установит ее в качестве базовой цены позиции в заказе на поставку. Например, в рассматриваемом случае цена была найдена в условии PB00, шаг 011, на рисунке 1-1, это шаг без текста и именно о создании такого шага нахождения цены и поговорим далее. В заказе, рисунок 1-2, данная цена была установлена как 300 UAH.
Рисунок 1‑2. Цена была установлена как 300 UAH
В рассматриваемой системе заказы создавались со ссылкой на заявку на закупку и контракт ММ, т.е. выполнялась двойная ссылка, дело в том, что в контракте ММ, позиция контракта формировалась с типом позиции М - материал неизвестен. Далее в тексте позиции указывали, например, "Поставка системы кондиционирования" и ставили общую контрактную сумму, например, 100 000 UAH. С другой стороны, в заявках на закупку прописывались уже конкретные коды закупаемых ОЗМ с ценой закупки для каждой позиции. Заявки так же включали в себя как материалы, так и услуги по установке системы кондиционирования, т.е. с одной стороны общая сумма контролировалась по контракту, с другой стороны был ответственные за закупку, которые контролировали закупаемые позиции, путем формирования заявок, т.е. правильные закупочные цены на материалы находились в заявках. Как оказалось, при такой комбинации, система берет стоимость позиций из контракта, т.е. каждая ссылочная позиция брала базовой суммой 100 000 UAH, в общем-то, это и понятно, так как из схемы калькуляции система находила контракт на закупку и копировала цену из контракта, что оказалось совершенно не-приемлемым. Исправлять в заказах на закупку десятки и сотни позиций, перенося цену из заявок, было не очень удобным (так как суммы уже были внесены в заявках один раз), опять же проблема правильности внесения цифр требовала дополнительной проверки. Поэтому встала задача, а сделайте так, чтобы сумма в позиции заказа на закупку копировалась из заявки, ну типа там BADI же есть, вот и подставьте. Конечно, BADI есть, но копировать сумму в позицию в пользовательском расширении, оказалось абсолютно неправильным решением, и по ряду причин работало все при таком копировании некорректно, поэтому был выбран путь добавления собственного шага в схему калькуляции. Оказалось, что это можно сделать для заявок ММ, но для этого, как обычно, нужно немного настройки + немного ABAP. За основу был взят шаг 010 - копирование цены из контракта на закупку.
2. Методика решения.
Настройка схем условий находится в транзакции SPRO по следующему пути: Управление материальными потоками - Закупки - Условия, рисунок 1-3. Собственно сама схема условий в данном случае нас не интересует, нас интересует настройка условия PB00, которое находится схеме RM0000, поэтому сначала идем в ветку "Определение видов условий" для определения последовательности доступа, которая назначена этому условию. Собственно говоря, перечень шагов это и есть последовательность доступа для условия.
Рисунок 1‑3. Настройка схем условий в транзакции SPRO
После перехода к просмотру условия PB00, видно, что этому условию назначена последовательность доступа 0002, рисунок 1-4.
Рисунок 1‑4. Условию назначена последовательность доступа 0002
Переходим к ведению последовательностей, ветка меню: "Определение последовательностей доступа". Как видим, шаги представляют последовательность, где каждый шаг, кроме номера шага, имеет также код таблицы условий, в нашем случае, таблицы условий с полями заявки на закупку не существует, поэтому, сначала необходимо создать новую таблицу условий, рисунок 1-5.
Рисунок 1‑5. Новая таблица условий
Таблицы условий для пользователей должны начинаться с номера 9 и в общем виде, таблица условий представляет из себя перечень полей, по которым мы будем определять выбор цены. В данном случае, нам необходимы поля номера и позиции заявки. Стандартно, в системе эти поля не объявлены в специальном каталоге возможных для использования в таблицах условий полей, поэтому сначала мы должны добавить такие поля в каталог. Для этого необходимо в транзакции SE11 расширить структуру KOMPAZ - Расчет цен - позиция связи: модификация клиента, путем добавления двух необходимых полей: номер заявки и позиция заявки, рисунок 1-6, при добавлении полей имена полей должны начинаться с символов ZZ, типы полей берем из таблицы заявок EBAN.
Рисунок 1‑6. В транзакции SE11 расширяем структуру
После добавления структуры дополнения, активируем созданные объекты и возвращаемся в настройку. Если все сделано правильно, то в ветке "Расширение каталога полей для таблиц условий" добавленные поля можно будет добавить в список каталога, рисунок 1-7.
Рисунок 1‑7. Добавление полей в сеписок каталога
Каталог полей расширен, можно перейти к созданию таблицы условий, для этого выбираем пункт "Ведение таблицы условий", и далее в диалоговом окне необходимо выбрать пункт "Создание таблицы условий". Как говорилось выше, номера пользовательских таблиц должны начинаться с цифры 9, поэтому создаем таблицу 901. Далее, из полей в колонке справа находим наши поля: заявка и позиция заявки, и переносим их в колонку слева,
Если хотите прочитать статью полностью и оставить свои комментарии присоединяйтесь к sapland
ЗарегистрироватьсяУ вас уже есть учетная запись?
Войти
Обсуждения 5
Комментарий от
Дмитрий Порушкин
| 04 мая 2017, 15:19
Хотя конкретно данную задачу я решал бы добавлением в схему калькуляции своего вида условия (без последовательности) и написанием формулы для него. Новый вид условия имел бы приоритет над PB00. Такое решение более привычно (ожидаемо) для консультантов, особенно для сторонних, которым нужно разобраться с тем, что уже сделано. Видишь "левый" вид условия, смотришь формулу (или просишь абапера, если сам не разбираешься). В одном месте вся логика.
Впрочем, это мое мнение, за всех консультатов не отвечу.
Комментарий от
Олег Точенюк
| 05 мая 2017, 10:52
Дмитрий Порушкин 04 мая 2017, 15:19
Интересный вариант решения. Возьму в инструментарий.
Хотя конкретно данную задачу я решал бы добавлением в схему калькуляции своего вида условия (без последовательности) и написанием формулы для него. Новый вид условия имел бы приоритет над PB00. Такое решение более привычно (ожидаемо) для консультантов, особенно для сторонних, которым нужно разобраться с тем, что уже сделано. Видишь "левый" вид условия, смотришь формулу (или просишь абапера, если сам не разбираешься). В одном месте вся логика.
Впрочем, это мое мнение, за всех консультатов не отвечу.
С другой стороны (ну это чисто теоретически), калькуляция дергается при обработке заказа много и часто, а у того же SD, если в заказе позиций за 150, то производительность существенно падает. Если в формуле все время дергать таблицы заявок без буферизации можно и так усугубить и без того не быстрое обновление заказа. В общем будет время и система, попробую это же сделать через формулу.
Комментарий от
Вячеслав Гришин
| 24 мая 2017, 06:53
1. Как минимум, не учтено отражение записи стандартном журнале изменений.
2. Если продолжать - не учитывается возможное перекрытие записи по периодам, их удаление и корректировка, как это работает в MEK1.
В этой конкретной задаче пожалуй можно игнорировать эти допущения. Но в общем случае - так делать нельзя. Был печальный опыт. Единственное известное мне гарантированно рабочее решение - это использовать пакетный ввод к MEK1 для ввода записей условий.
Комментарий от
Олег Точенюк
| 24 мая 2017, 22:12
Вячеслав Гришин 24 мая 2017, 06:53
Прямой апдейт для добавления записи условия - плохой вариант.
1. Как минимум, не учтено отражение записи стандартном журнале изменений.
2. Если продолжать - не учитывается возможное перекрытие записи по периодам, их удаление и корректировка, как это работает в MEK1.
В этой конкретной задаче пожалуй можно игнорировать эти допущения. Но в общем случае - так делать нельзя. Был печальный опыт. Единственное известное мне гарантированно рабочее решение - это использовать пакетный ввод к MEK1 для ввода записей условий.
2. Пакетный ввод в контексте чужой транзакции, вещь не надежная, это надо уже параллельным потомком делать и т.д. Там есть ФМ-ки которыми можно сделать ведение записей условий, они конечно не сильно отличаются фактически ручной вставки, но пакетный ввод, в данном случае будет большей проблемой, чем заполнение записи условия. Кстати, код выдернут из аналогичного ведения условия для контрактов ММ.
Комментарий от
Дмитрий Тарасов
| 01 июня 2017, 11:04