Текущее время: Вт, май 17 2022, 17:19

Часовой пояс: UTC + 3 часа




Начать новую тему Ответить на тему  [ Сообщений: 19 ]  На страницу 1, 2  След.
Автор Сообщение
 Заголовок сообщения: Расширенные национальные сплиты
СообщениеДобавлено: Ср, дек 08 2021, 10:21 
Ассистент
Ассистент

Зарегистрирован:
Чт, янв 13 2011, 10:54
Сообщения: 43
Коллеги, доброго времени суток!

Проводим адаптацию правил после установки решения по расширенным национальным сплитам.
В презентации семинара по новому решению поставщик дает инструкцию по адаптации правил:
Вместо операций ELIMI, SETIN и RESET для национальных сплитов нужно использовать RUSP.
Вместо SPLIT – RUQSP.

Не получилось найти аналога операции SETIN, а также операции SPLIT с параметрами 1?, 2?, 3?.
Какие операции предлагается использовать для замены выше указанным?

И почему в поставке не адаптируется elimi *, reset *? Эти операции же точно также оперируют с cntr1/2/3.
В коде этих операций нет вызова подпрограмм pack/unpack.

Поделитесь, пожалуйста, кому удалось провести адаптацию успешно и перейти с CNTR3 на ID_3?


Принять этот ответ
Вернуться к началу
 Профиль Отправить email  
 
 Заголовок сообщения: Re: Расширенные национальные сплиты
СообщениеДобавлено: Ср, дек 08 2021, 12:02 
Гуру-эксперт
Гуру-эксперт

Зарегистрирован:
Пт, сен 07 2007, 07:53
Сообщения: 1385
Пока не стввил, готовлюсь только.

rass написал(а):
И почему в поставке не адаптируется elimi *, reset *? Эти операции же точно также оперируют с cntr1/2/3.
В коде этих операций нет вызова подпрограмм pack/unpack.

Эти операции и не будут адаптироваться, это же международная поставка. Именно поэтому и созданы RU-версии этих операций. Здесь правильнее ставить вопрос - почему в поставке не заменили вызовы RESET */ ELIMI * на RU-операции?
Обратил внимание на это еще на презентации. Пришел к выводу, что именно для RESET */ ELIMI * особого смысла в замене нет. ELIMI * очищает все сплиты, поэтому для RUCNX ничего нового не появляется. RESET * восстанавливает исходное значение сплитов, а значит восстаналиваемая комбинация CNTR3-CNTR2-CNTR1 в RUCNX уже была, новый код не появляется.
А вот если встречается любое одиночное действие со сплитами 1,2 или 3, то появляется новая комбинация CNTR3-CNTR2-CNTR1, который может и не быть в RUCNX. То есть, важно заменить именно все вызовы таких операций с прямыми указаниями сплитов 1, 2 или 3.


Принять этот ответ
Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Расширенные национальные сплиты
СообщениеДобавлено: Ср, дек 08 2021, 15:04 
Ассистент
Ассистент

Зарегистрирован:
Чт, янв 13 2011, 10:54
Сообщения: 43
RoustR написал(а):
Пока не стввил, готовлюсь только.

rass написал(а):
И почему в поставке не адаптируется elimi *, reset *? Эти операции же точно также оперируют с cntr1/2/3.
В коде этих операций нет вызова подпрограмм pack/unpack.

Эти операции и не будут адаптироваться, это же международная поставка. Именно поэтому и созданы RU-версии этих операций. Здесь правильнее ставить вопрос - почему в поставке не заменили вызовы RESET */ ELIMI * на RU-операции?
Обратил внимание на это еще на презентации. Пришел к выводу, что именно для RESET */ ELIMI * особого смысла в замене нет. ELIMI * очищает все сплиты, поэтому для RUCNX ничего нового не появляется. RESET * восстанавливает исходное значение сплитов, а значит восстаналиваемая комбинация CNTR3-CNTR2-CNTR1 в RUCNX уже была, новый код не появляется.
А вот если встречается любое одиночное действие со сплитами 1,2 или 3, то появляется новая комбинация CNTR3-CNTR2-CNTR1, который может и не быть в RUCNX. То есть, важно заменить именно все вызовы таких операций с прямыми указаниями сплитов 1, 2 или 3.


Ну да, вопрос как раз именно в том, что в поставке нет адаптаций правил elimi *, reset *.
Получается, что САП создали "задел" на будущее для использования новых сплитов ID4 - ID8. А когда один из этих сплитов понадобится использовать, то международные операции reset/elimi со * использовать будет нельзя, т.к. они оперируют только со сплитами 1,2,3.
Не понятно, почему бы сразу не адаптировать абсолютно все случаи, где устанавливаются или снимаются национальные сплиты.


Принять этот ответ
Вернуться к началу
 Профиль Отправить email  
 
 Заголовок сообщения: Re: Расширенные национальные сплиты
СообщениеДобавлено: Ср, дек 08 2021, 21:03 
Старший специалист
Старший специалист

Зарегистрирован:
Чт, окт 13 2011, 22:45
Сообщения: 490
rass, загляните на jam, там как раз эти же вопросы задают.... а может это вы и задаете))


Принять этот ответ
Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Расширенные национальные сплиты
СообщениеДобавлено: Чт, дек 09 2021, 10:19 
Ассистент
Ассистент

Зарегистрирован:
Чт, янв 13 2011, 10:54
Сообщения: 43
Добрый день!
Да, я и на Jam написала.

Если подвести итог, то:
1. В стандарте нет аналогов операций SETIN, Split? (кроме проверки на initial). Возможно, в будущем появятся, но пока нет.
2. Стандартные правила, которые содержат reset *, elimi * не были адаптированы, так как пока (используются только 1,2,3 сплиты) это не нужно. В дальнейшем, при активации использования новых сплитов, придется адаптировать и международные правила со *.


Принять этот ответ
Вернуться к началу
 Профиль Отправить email  
 
 Заголовок сообщения: Re: Расширенные национальные сплиты
СообщениеДобавлено: Ср, дек 29 2021, 08:43 
Гуру-эксперт
Гуру-эксперт

Зарегистрирован:
Пт, сен 07 2007, 07:53
Сообщения: 1385
Для информации.
Новая RU-операция манипулирования сплитами RUSP работает неправильно при использовании в отношении таблицы ORT (функции PORT/POGRT). Точнее, воспользоваться операций RUSP можно только один раз.

Представим такие действия. У нас есть ORT, загруженной функций IMPRT O, откуда нам нужно перенести в IT определенный ВО. Перенос нужно выполнить в контексте определенного сплита, например CNTR2. Правило обработки выглядело так
Code:
ELIMI *
RESET 2

Делаю замену на RUSP
Code:
RUSPEO*  E-elimi, O-мы работаем в контексте ORT
RUSPRO2  R-reset

Второй вызов RUSP работает ошибкой. В чем проблема? Если раньше мы просто работали со сплитами 1-3, то теперь требуется операция распаковки сплитов. Распаковка требует указания таблицы RUCNX, а если мы работаем с ORT, то нужно использовать таблицу ORUCNX. Таким образом, для распаковки появляется понятие контекста.

Операция RUSP начинается с распаковки текущей записи OT и заголовка IT, где в момент работа PORT находится состояние записи на момент начала работы правила (именно по ней происходит reset). Для распаковки OT и IT нужно указать контекст ORUCNX (за это отвечает буква O при вызове RUSP). Отмечу, что этот контекст получается единым и для OT, и для IT.
Далее, собственно выполняется работа над сплитами. Затем запись OT нужно упаковать. И это выполняется уже относительно RUCNX.

При следующем вызове RUSP нужно снова начинать с распаковки OT/IT. Повторю, контекст распаковки этих записей может быть только один общий, либо RUCNX, либо ORUCNX. Но мы помним, что в прошлом вызове RUSP упаковали OT относительно RUCNX, тогда как контекст для IT не изменился - ORUCNX. Это значит, что распаковка одной из записей будет происходить неверно, а значит определение сплитов ID_1/ID-8 будет происходить с ошибкой.

Ошибка может сопровождать появлением сообщения "Inconsistent content in RUCNX and payroll results table", но это происходит только при отсутствии подходящей записи в указанном контексте RUCNX/ORUCNX. Зачастую заполнение этих таблиц близкое, поэтому добиться появления сообщения сложно. Мне пришлось создать пример с выходом из состояния совместимости заполнения RUCNX (переполнил RUDAT), чтобы гарантировано получить такое сообщение. Тем не менее, если сообщения нет, это еще не значит, что операция работает без ошибок.

Таким образом, второй вызов RUSP в контексте ORT работает неправильно. Аналогичная ситуация возникает после использования операции RUOC1. Там также конечная упаковка записи OT происходит относительно RUCNX. Это значит следующий вызов RUSP будет произведен с ошибкой.


Принять этот ответ
Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Расширенные национальные сплиты
СообщениеДобавлено: Ср, дек 29 2021, 15:54 
Старший специалист
Старший специалист

Зарегистрирован:
Чт, окт 13 2011, 22:45
Сообщения: 490
RoustR, Тикет выставляли? Больше тикетов, быстрее починят...


Принять этот ответ
Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Расширенные национальные сплиты
СообщениеДобавлено: Ср, дек 29 2021, 20:59 
Гуру-эксперт
Гуру-эксперт

Зарегистрирован:
Пт, сен 07 2007, 07:53
Сообщения: 1385
Да, выставлял. Только пока не могу преодолеть первый уровень обороны в виде первого уровня поддержки. Требует воспроизведения проблемы на стандартной схеме. А это довольно сложно сделать.
Я взял картинку с презентации SAP, где приведет пример заполнения RUCNX при переполнении RUDAT, взял оттуда пример записи RUDAT c первичным ключом более 0x100, заполнил все это в в межрасчете. То есть, в RT есть запись ВО, который ссылается на такую запись в RUDAT, которая лежит за границей совместимости.А дальше в обычном рег.расчете обычной конструкций LPBEG RCOC и IMPRT O загружаю этот межрасчет, и в правиле по ORT просто снова и снова снимаю и устанавливаю сплит ID_2. Так сообщение об ошибки появляется гарантировано, так как в таком примере RUCNX и ORUCNX довольно сильно отличаются друг от друга.
Но это, видимо, слишком сложно.


Принять этот ответ
Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Расширенные национальные сплиты
СообщениеДобавлено: Пн, янв 10 2022, 18:07 
Ассистент
Ассистент

Зарегистрирован:
Чт, янв 13 2011, 10:54
Сообщения: 43
Коллеги, приветствую.
У нас аналогичная проблема с переносом из ORT.
Я тоже не смогла воспроизвести в стандарте кейс(

Пока сделала функцию, которая после переноса из ORT выравнивает данные в RUCNX. Но понятно, что при переполнении она работать не будет(

На Jam не пробовали писать?


Принять этот ответ
Вернуться к началу
 Профиль Отправить email  
 
 Заголовок сообщения: Re: Расширенные национальные сплиты
СообщениеДобавлено: Вт, янв 11 2022, 09:17 
Гуру-эксперт
Гуру-эксперт

Зарегистрирован:
Пт, сен 07 2007, 07:53
Сообщения: 1385
Службу поддержки SAP за 3 итерации не пробил. :( Требуют воспроизведение сообщения в стандартной поставке. А сообщение гарантировано появляется только при переполнении RUDAT. Вот как описать действия, приводящие к переполнению? :shock: Это первое.
Второе. В стандартной поставке нет правил с двумя вызовами RUSP. То есть, это настолько хорошо сделанные операции, что сам SAP избегает их использовать. :D
В презентации приведен пример правила RU35, где последовательность
Code:
ELIMI *
RESET 2
замена на
Code:
ELIMI *  <* замену на RUSPE * не выполнили.
RUSPR 2
Да, заменять ELIMI * на RUSPE * не обязательно, работать будет. Но я бы при выполнении аналогичной работы замену бы произвел только для того, чтобы бы показать, что адаптация правила выполнена полностью. А так сиди думаю, замены нет потому, что так было задумано, или потому, что пропустили.
Но RU35 работает с IT, и проблем с ним нет.

А примеров с ORT нет. Самое близкое, это правило RUO8, работает с RUCDT (контекст как и у PORT, ORUCNX). Там встречается последовательность:
Code:
RESET *
FILLF NRA
RUOC1
Здесь также удачно не заменили RESET на RUSP. Если бы замена была, то вызов RUSP изменил контекст OT с ORUCNX на RUCNX, а операция RUOC1 работает только относительно ORUCNX. Был бы промах.

То есть, пользоваться RUSP можно, но только один раз. Вызов RUOC1 также считается как вызов RUSP.

На SAPJAM сегодня написал. Надеюсь пройдет. ПРиложил там файл с описанием. Если кому интересно, то Контент -5. Отдельные специфичные темы и задачи - RUCNX Промах контекста в RUSP.


Принять этот ответ
Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Расширенные национальные сплиты
СообщениеДобавлено: Вт, янв 18 2022, 09:26 
Гуру-эксперт
Гуру-эксперт

Зарегистрирован:
Пт, сен 07 2007, 07:53
Сообщения: 1385
Может быть кому-то это будет интересно.

При установки нот по RUCNX стоит довольно большая задача адаптировать правила расчета - перейти от международных операции типа RESET/ELIMI к новым RU-версиям. Это может быть довольно трудоемкой задачей, особенно если ваша система сильно дорабатывалась.

Эту задачу можно значительно упростить, если сделать автоматическую переадресацию вызовов международных операций на RU-версии. Например, на входе процедуры, реализующей RESET, делаем расширение, в котором проверяем указание сплитов 1, 2 или 3. Если указаны, то производим вызов процедуры, реализующей RUSP. Для этого также производим замену переменной OP, в котором кодируем вызов операции. После исполнения выходим, не даем выполнится стандартному коду RESET.

Сложность там только при работе с ORT - нужно указать контекст на ORUCNX буквой O в коде операции (переменная OP). Стандарт это делает на основе проверки текущей функции (переменная AS-FUNC). ORUCNX выбирается при работе с PORT, POGRT и RUCDT.

Также следует учесть, что на данный момент в стандарте новые операции RUSP/RUQP не могут работать с ORT более одного раза, будет промах контекста, о чем я писал ранее. Чтобы решить эту проблему пришлось сделать механизм, который следит за контекстом текущей записи из ORT, что позволяет правильно его выбрать.

Таким образом можно выполнить работу по запуску ноту по RUCNX без срочной переработки всех правил. Эту работу можно выполнить позже.

Такой механизм можно также использовать для контроля того, что все правила были адаптированы, если же адаптация правил производится. В этом случае в расширении международных операций ставим проверку работы со сплитами 1, 2 или 3, и если это так, то выводим предупреждение в журнал расчета. Если работа выполнена, то в журнале не должно быть таких сообщений.


Принять этот ответ
Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Расширенные национальные сплиты
СообщениеДобавлено: Чт, фев 03 2022, 20:23 
Гуру-эксперт
Гуру-эксперт

Зарегистрирован:
Пт, сен 07 2007, 07:53
Сообщения: 1385
Нашел еще проблему в процессе PTIAB MEGRE/LOAD в отношении таблиц ORT. Эта процедура используется для адаптации старых расчетов в ORT под заполнение сплитов текущего расчета. В схеме это выглядит как
Цитата:
LPBEG RC
IMPRT O
PITAB M CORT
LPEND
...
PITAB L CORT
...
Если цикл LPBEG выполняет несколько итераций, то ORT каждой загрузки переносится в CORT с адаптаций сплитов, а после цикла содержимое CORT возвращается в ORT. Таким образом в ORT будет загрузка нескольких расчетов. А вот в отношении ORUCNX такая процедура не выполняется. ORUCNX останется по последнему загруженному расчету.
В последующей обработке, например, в функции RURTR, в ORT может встретиться такая комбинация, которая отсутствует в ORUCNX. Будет сообщение "Inconsistent content in RUCNX and payroll results table".

Проблема проявляется после изменения сплитования периодов (V_530_E) задним числом.

Сообщение в SAP выставил. Вроде приняли. Надеюсь, нота будет.


Принять этот ответ
Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Расширенные национальные сплиты
СообщениеДобавлено: Пт, фев 11 2022, 15:48 
Младший специалист
Младший специалист

Зарегистрирован:
Чт, дек 15 2011, 08:15
Сообщения: 60
Привет.

Это я что-то не понимаю в новой логике или это всё же ошибка. В RUCDT заложена следующая логика: ORT распаковывается в ls_ot_ext относительно контекста ORUCNX, далее срабатывает adjust_rudat_ext, где id2 выравнивается относительно RUDAT и заменяется. после этого запаковывается, но используя снова ORUCNX. В результате сплит ID2 отсутствует в RUCNX.
Запаковка должна же была быть относительно RUCNX? Или предполагается, что надо каким-то образом адаптировать RUO8 под это дело?


Принять этот ответ
Вернуться к началу
 Профиль Отправить email  
 
 Заголовок сообщения: Re: Расширенные национальные сплиты
СообщениеДобавлено: Пн, фев 14 2022, 07:47 
Гуру-эксперт
Гуру-эксперт

Зарегистрирован:
Пт, сен 07 2007, 07:53
Сообщения: 1385
Ну общая логика примерно такая. В функциях, где выполняется согласование сплитов старых расчетов под новые, например указанная adjust_rudat_ext, упаковка выполняется относительно ORUCNX. Поэтому, Если необходим перенос записи из ORT в текущие таблицы IT/RT, то обязательно нужно сменить контекст с ORUCNX на RUCNCX. Это сделает любой вызов RUSP.
Если такого вызова нет, то это придется добавить , например RUSPRO*.


Принять этот ответ
Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Расширенные национальные сплиты
СообщениеДобавлено: Вт, фев 15 2022, 10:53 
Ассистент
Ассистент

Зарегистрирован:
Чт, янв 13 2011, 10:54
Сообщения: 43
Коллеги, добрый день.
Мы тоже выставили сообщение по проблеме RUCDT и RUO8. Смоделировали на стандартной схеме.
САП пока не принимает сообщение, задали вопрос, на что влияет ворнинг по RUCNX)))) Предложили поставить последнюю версию 3147423.
Поделитесь, пожалуйста, если вам что-то ещё полезное ответят.
Свою схему допилили, чтобы ошибок не было, но хочется стандартного решения.


Принять этот ответ
Вернуться к началу
 Профиль Отправить email  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 19 ]  На страницу 1, 2  След.

Часовой пояс: UTC + 3 часа


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Перейти:  
cron
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group
Русская поддержка phpBB