Ретробиллинг. Практическое руководство. Часть 2
Тема, как и функционал, с помощью которого она реализуется в системе, с моей точки зрения, достаточно специфична. Однако, все же надеюсь, что мой материал кому-то пригодится.
Часть 1 >>
Содержание
Шаг 1. Определение видов соглашения о бонусе (рис.32 и 33)
Шаг 2. Определение групп видов условий (рис.34.)
Шаг 3. Присвоение видов/таблиц условий группам видов условий (рис.36)
Шаг 4. Присвоение групп видов условий видам соглашений о бонусе
Шаг 5. Определение видов условий
Шаг 6. Ведение схемы калькуляции (рис.40)
Шаг 7. Переходим к следующему разделу – выбор счета для бонуса (рис.43)
Шаг 8. Выбор видов фактур, для которых возможна обработка бонуса (рис.46)
Шаг 9. Определение сбытовых организаций, для которых возможна обработка бонуса
Шаг 10. Определение групп бонуса
Шаг 11. Определение видов заказов (запросов кредитования) для бонуса
Шаг 12. Определение видов фактур для расчета бонуса (рис.50)
Шаг 13. Проверка корректности параметров обновления инфо-структур ИСЛ
Ошибка «Оборот к соглашению *** не актуален»
Справка
На рисунке 30. - Краткая справка по разделу обработки бонуса.
Рисунок 30. Краткая справка по разделу обработки бонуса.
Адаптивный перевод:
Бонус – это уменьшение цены продажи, которое предоставляется клиенту в форме кредитового авизо в зависимости от периода. База для бонуса может быть определена с помощью различных ключей (клиент, клиент/материал, группа материалов и т.д.). Для настройки бонуса в системе необходимо:
- Определить (использовать имеющиеся) и настроить виды соглашений о бонусе;
- Определить схему резервных начислений в фактуре;
- Выполнить расчет и закрытие соглашения;
- Удалить сделанные ранее резервные начисления.
Помимо этого, работа с соглашениями о бонусах требует соответствующей настройки счетов выручки. Необходимо помнить, что если работа с бонусом ведется лишь для какой-то определенной сбытовой организации, то для остальных СбОрг обработка бонуса должна быть отключена (причина – забота о производительности системы). Также, для конфигурирования бонуса, следует держать в уме следующие разделы настройки:
- Техника условий;
- Основные требования для работы с бонусом;
- Расширение кодов счетов;
- Ведение таблиц;
- Создание индекса для счетов-фактур.
Ну и далее перечисляются системные таблицы, которые задействованы в работе функционала. Перевод не дословный, а локализованный, чтобы лучше отразить смысл необходимых операций в SPRO. Теперь предлагаю пробежаться непосредственно по настройке, а затем рассмотрим небольшой пример.
В этом разделе настройки выполняется конфигурация основных параметров работы соглашения о бонусе (рис.31).
Рисунок 31. Раздел настройки соглашений о бонусе.
Шаг 1. Определение видов соглашения о бонусе (рис.32 и 33).
Рисунок 32. Определение вида соглашения о бонусе.
Рисунок 33. Настройка вида соглашения о бонусе (подробный экран)
Для примера, создаем новое соглашение на основании стандартного (0003 – Бонус клиента). «Пробежимся» по полям:
Поля окна Значения по умолчанию определяют период действия соглашения, способ платежа (можем не указывать) и начальный статус документа.
Окно Управление. Группа типов условий – этот параметр определяет, какие виды условий и таблицы будут работать для данного вида соглашения о бонусе (рассмотрим чуть ниже). Объем подтверждения определяет структуру полей, которые будут доступны для проверки, расчета и закрытия соглашения о бонусе. Поле Альтернативная дата касается даты записи условия для данного соглашения о бонусе. Если галка на поле стоит, то запись условия, создаваемая в рамках соглашения о бонусе, может иметь другой период действия.
Виды заказов ZB1-ZB4 используются для проведения в сбыте операций по расчету, частичному расчету, ручному расчету и корректировкам бонуса по соглашению. К ним идут дополнительные поля, которые определяют условия расчета, статусы, что будет происходить с резервными отчислениями и т.д. Детали ниже, по ходу рассмотрения примера.
Последнее окно - тексты соглашения.
Шаг 2. Определение групп видов условий (рис.34.)
Рисунок 34. Настройка групп видов условий.
Это параметр, который был виден в настройке вида соглашения о бонусе, но был серый. По идее, для шага 1, это поле должно быть пустым (если настройка идет с нуля). Но, учитывая, что в нашей системе настройки уже были сделаны, работаем с тем, что имеем. Итак, тут просто определяем код группы условий и его тип. Тип оставляем пустым (рис.35).
Рисунок 35. Группы условий для расчета бонуса
Шаг 3. Присвоение видов/таблиц условий группам видов условий (рис.36).
В этом пункте меню мы определяем, какие виды и таблицы условий будут работать для созданной выше группы видов условий. Выполняем присвоение.
Рисунок 36. Присвоение видов и таблиц условий группе видов условий.
Ключом в таблице является сочетание Группы видов условий и Счетчика. Для двух этих параметров выполняется присвоение пары «вид условия – таблица условия». Я думаю, тут понятно, что для указанного в настройке вида условия в дальнейшем в схеме калькуляции будет производиться расчет суммы бонуса с использованием указанной тут же таблицы. Как уже отмечалось выше, используется стандартная техника условий по различным ключам.
Шаг 4. Присвоение групп видов условий видам соглашений о бонусе
Собственно, название пункта меню говорит само за себя: группа видов условий из шага 2 присваивается виду соглашения о бонусе из шага 1 (рис.37).
Рисунок 37. Присвоение группы видов условий виду соглашения о бонусе.
Следующим разделом настройки идет «Техника условий для расчета бонуса». Данный пункт состоит из знакомых разделов настройки элементов ценообразования (рис.38).
Рисунок 38. Раздел настройки элементов ценообразования, применимых к расчету бонуса.
Шаг 5. Определение видов условий
Тут имеется некоторая несогласованность. Дело в том, что вид условия, который мы уже присвоили для группы видов условий (шаг 3), создается только сейчас. Опять же, это связано с тем, что я иду по уже настроенной системе, т.е. делаю настройки не с нуля. Но надеюсь, искушенный читатель нить рассуждения не потеряет.
Вот так выглядит вид условия YO02, который мы будем использовать для расчета бонуса (рис.39). Обратите внимание, что правило расчета бонуса – в %. Т.е. мы говорим о том, что бонус с продаж будет определяться в процентах от объема.
Рисунок 39. Настройка вида условия для калькуляции бонуса.
Шаг 6. Ведение схемы калькуляции (рис.40).
Рисунок 40. Ведение схемы калькуляции.
В схемы калькуляции, которые будут использоваться для работы с бонусом, вставляем созданный вид условия. Предпосылка – 24 (расчет в фактуре). Обращаем внимание на коды счетов: ERB – для бонуса, ERU – для резервных отчислений в отношении бонуса. Кстати, про резервные отчисления уже упоминалось, но я не рассказал, что это такое. Резервные начисления – это условные начисления бонуса, которые накапливаются со временем и ведутся на особом балансовом счете. В момент, когда будет происходить выставление бонуса клиенту (формирование кредитового авизо), то счет выручки бонуса по кредиту (бонус, как и скидки, ведется на счетах раздела выручки) будет корреспондировать со счетом резервного отчисления по дебету.
Следующие три пункта настройки опциональны (рис.41).
Рисунок 41. Опциональные пункты настройки.
Как видно из скриншотов выше, используется стандартная таблица условий (001) и стандартная последовательность доступа (BO02) для вида условия YO02. Таким образом, выполнять эти три пункта настройки для нашего примера смысла нет. Хотел отметить один момент относительно таблиц доступа. Это не те же таблицы, которые используются для расчета цены. Физическое имя таблиц начинается на KOTE*** (не путать с «котэ») (рис.42).
Рисунок 42. Таблица расчета бонуса Клиент/Материал.
Шаг 7. Переходим к следующему разделу – выбор счета для бонуса (рис.43).
Рисунок 43. Радел настройки по выбору счета для бонуса.
Тут ничего нового, стандартные разделы настройки для выполнения присвоения счетов с использованием все той же техники условий. Выбор счетов происходит с использованием кодов ERB и ERU. Используются те же виды условий (KOFI & KOFK) и схемы (KOFI00) выбора счета. Таблицы присвоения счетов те же, что и для определения счетов выручки (C***). Ниже представлен пример присвоения счетов для бонуса и резервных отчислений бонуса с использованием стандартной таблицы C001 (рис.44).
Рисунок 44. Присвоение счетов для учета бонуса.
Далее, настройка активации обработки бонуса (рис.45).
Рисунок 45. Раздел настройки по активации обработки бонуса.
Шаг 8. Выбор видов фактур, для которых возможна обработка бонуса (рис.46).
Рисунок 46. Виды фактур, для которых активна обработка бонуса.
Кстати, фактуры для обработки бонуса ZB1-ZB4 также должны быть помечены, как релевантные для бонуса.
Шаг 9. Определение сбытовых организаций, для которых возможна обработка бонуса.
Тут все понятно без комментариев (рис.47).
Рисунок 47. Сбытовые организации для которых активна обработка бонуса.
Шаг 10. Определение групп бонуса
Это опция, которая позволяет применять бонус кумулятивно, для нескольких материалов. Например, мы продаем не только шлак, но и еще какой-то неликвид: отсев, породу. При этом сумма бонуса будет считаться не для одного материала, а суммой для всех. Тогда мы определяем группу бонуса в настройке. Присваиваем эту группу для всех ОЗМ, для которых будет затем считаться бонус. В качестве таблицы условия (одной из таблиц) необходимо будет использовать таблицу КОТЕ002 «Клиент/Группа бонуса».
Шаг 11. Определение видов заказов (запросов кредитования) для бонуса
Для работы с бонусами в стандарте системы определены виды заказа В1-В4. Для нашего примера используем Z-копии этих видов заказов (рис.48).
Рисунок 48. Виды заказов для обработки бонуса.
Внутренняя структура вида документа практически не менялась (рис.49).
Рисунок 49. Настройка вида заказа ZB1, подробный экран.
Шаг 12. Определение видов фактур для расчета бонуса (рис.50).
Рисунок 50. Настройка видов фактур для обработки бонуса.
Про отдельные виды фактур уже упоминалось. Копируем фактуры со стандартных В1-В4. Особенность настройки заключается в следующем:
- Стоит галка релевантности для расчета бонуса;
- Расчет бонуса – выбор параметра зависит от типа расчета (рис.51).
Рисунок 51. Настройка фактуры для бонуса, подробный экран.
4 вида фактуры, 4 схемы расчета. Пример – таблица TVFK (рис.52).
Рисунок 52. Таблица TVFK, виды фактур для бонуса.
Шаг 13. Проверка корректности параметров обновления инфо-структур ИСЛ
Стоит также проверить схему обновления инфо-структур S060 и S136, которые отвечают за сбор данных, релевантных для обработки бонуса (транзакция ОМО1).
Инфо-структура S060 отвечает за сбор информации по стоимости фактур, релевантных для бонуса. Схема обновления инфо-структуры должна выглядеть следующим образом (рис.53):
Рисунок 53. Схема обновления инфо-структуры S060.
S136 – структура индекса, которая обновляется номерами фактур, содержащих в схеме калькуляции вид условия для обработки бонуса. Параметры обновления данной инфо-структуры должны выглядеть так (рис.54):
Рисунок 54. Схема обновления инфо-структуры S136.
Если никто специально (хотя в это трудно поверить) параметры обновления для этих инфо-структур не менял, то ничего делать и не надо. Но глянуть одним глазком можно.
По настройке все! Переходим к созданию примера. Однако, сначала еще пару слов о мастер-данных, которые оказывают влияние на функциональность расчета бонуса. Про ОЗМ я уже упоминал, когда говорил о группе бонуса (шаг 10). Если мы используем группу бонуса, то для всех материалов, релевантных для группы, соответствующая группа должна быть указана в основной записи (рис.55).
Рисунок 55. Поле «Группа бонуса» в ОЗМ.
Для клиента, который будет получать бонус, в ОЗД (записи ДП) обязательно должна стоять соответствующая отметка на вкладке Фактура (рис.56):
Рисунок 56. Управляющий индикатор обработки бонуса для основной записи делового партнера.
Демонстрационный пример
Создаем соглашения о бонусе (тр. VBO1) (рис.57).
Рисунок 57. Создание соглашения о бонусе.
Вводимой информации минимум. Как видно на рисунке, часть информации скопировалась из настройки вида соглашения о бонусе. При желании, ее можно изменить. Переходим к условиям (соответствующая кнопка на панели инструментов) (рис.58).
Вводим данные в соответствии с ключом
Если хотите прочитать статью полностью и оставить свои комментарии присоединяйтесь к sapland
ЗарегистрироватьсяУ вас уже есть учетная запись?
Войти
Обсуждения 2
Комментарий от
Мурат Бажанов
| 21 июня 2017, 06:03
с уважением Мурат
Комментарий от
Константин Локшин
| 24 октября 2017, 14:47
Так что пора вместо этой устаревшей функциональности изучать Settlement Management (он есть и в обычной ERP).