Текущее время: Пт, мар 29 2024, 00:56

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




Начать новую тему Ответить на тему  [ Сообщений: 25 ]  На страницу Пред.  1, 2
Автор Сообщение
 Заголовок сообщения: Re: Расширенные национальные сплиты
СообщениеДобавлено: Вт, фев 15 2022, 18:54 
Старший специалист
Старший специалист

Зарегистрирован:
Пт, ноя 25 2011, 17:37
Сообщения: 291
никого не призывают так делать, но если вы уверены в том, что RUDAT у вас не переполнится, то вместо перелопачивания правил, можно сделать функцию, которую добавить перед RUCDT и EXPRT и которая пробежится по таблицам, сгенерировав отсутствующие сплиты в RUCNX.
За основу можно взять класс cl*ru*flex*split*refine*, метод get_by_result
Вроде именно он используется в отчетности для заполнения RUCNX в расчетах, в которых нет этой таблицы.

По поводу SETIN. Его скорее всего не адаптируют, т.к. SETIN просто устанавливает сплит. А предполагается, что сплит - это не самостоятельная вещь, а ссылка на какую-то таблицу расчета. Соответственно, логично управлять не только сплитом, но и записями связанной таблицы.
В целом идея здравая, но специфику клиентов не сказать, что учитывает.

Но на самом деле со всеми этими ID...8, которых может быть под миллион (гипотетически), есть один нюанс. Стандартные проводки выдерживают 99 999 записей в RT.

_________________
Зачем делать просто, когда можно сделать круто?!


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

Зарегистрирован:
Пт, сен 07 2007, 07:53
Сообщения: 1392
ZGilgelad написал(а):
сделать функцию, которую добавить перед RUCDT и EXPRT и которая пробежится по таблицам, сгенерировав отсутствующие сплиты в RUCNX.
За основу можно взять класс cl*ru*flex*split*refine*, метод get_by_result
Вроде именно он используется в отчетности для заполнения RUCNX в расчетах, в которых нет этой таблицы.


Проблема в том, что если пропуски в RUCNX возникли, то нельзя быть уверенным в том, что расчет был выполнен без ошибок. Пропуск в RUCNX это не просто косметический дефект. Он означает, что где-то работа со сплитами могла быть выполнена с ошибкой, и обработка могла быть выполнена не так, как должна была быть.


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

Зарегистрирован:
Пт, мар 29 2013, 17:06
Сообщения: 10
rass написал(а):
Коллеги, добрый день.
Мы тоже выставили сообщение по проблеме RUCDT и RUO8. Смоделировали на стандартной схеме.
САП пока не принимает сообщение, задали вопрос, на что влияет ворнинг по RUCNX)))) Предложили поставить последнюю версию 3147423.
Поделитесь, пожалуйста, если вам что-то ещё полезное ответят.
Свою схему допилили, чтобы ошибок не было, но хочется стандартного решения.
Аналогичная проблема, пока сделали расширение в RUOC1.


Принять этот ответ
Вернуться к началу
 Профиль Отправить email  
 
 Заголовок сообщения: Re: Расширенные национальные сплиты
СообщениеДобавлено: Пт, май 13 2022, 16:36 
Специалист
Специалист

Зарегистрирован:
Сб, апр 10 2010, 19:23
Сообщения: 190
Samex написал(а):
rass написал(а):
Коллеги, добрый день.
Мы тоже выставили сообщение по проблеме RUCDT и RUO8. Смоделировали на стандартной схеме.
САП пока не принимает сообщение, задали вопрос, на что влияет ворнинг по RUCNX)))) Предложили поставить последнюю версию 3147423.
Поделитесь, пожалуйста, если вам что-то ещё полезное ответят.
Свою схему допилили, чтобы ошибок не было, но хочется стандартного решения.
Аналогичная проблема, пока сделали расширение в RUOC1.

Добрый день!
В суть проблемы не вникал (поэтому не уверен что поможет), просто фиксирую, что исправления в ноте 3163724 - PIT: inconsistent content in RUCNX and payroll results table предназначены для озвученных вами объектов.


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

Зарегистрирован:
Чт, янв 13 2011, 10:54
Сообщения: 55
Коллеги, приветствую.
Ноту 3163724 выставили в частности и по нашему инциденту.
На текущий момент все проблемы, с которыми мы столкнулись, с неконсистентностью сплитов, решили в стандарте.


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

Зарегистрирован:
Сб, апр 10 2010, 19:23
Сообщения: 190
RoustR написал(а):
Нашел еще проблему в процессе 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 выставил. Вроде приняли. Надеюсь, нота будет.

RoustR, приветствую!
Было ли предоставлено решение озвученной проблемы? Столкнулись с такой ситуацией, которая усугубляется еще и тем, что в результате такого поведения у /322 не проставился сплит CNTR1 на TAX. И, как следствие, не сгенерировался /32E в RUTXD MDDE.


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

Зарегистрирован:
Чт, янв 13 2011, 10:54
Сообщения: 55
-DoKa- написал(а):
Было ли предоставлено решение озвученной проблемы? Столкнулись с такой ситуацией, которая усугубляется еще и тем, что в результате такого поведения у /322 не проставился сплит CNTR1 на TAX. И, как следствие, не сгенерировался /32E в RUTXD MDDE.


Приветствую! А вызов RUSPRO* не помогает?


Принять этот ответ
Вернуться к началу
 Профиль Отправить email  
 
 Заголовок сообщения: Re: Расширенные национальные сплиты
СообщениеДобавлено: Пн, май 30 2022, 10:05 
Специалист
Специалист

Зарегистрирован:
Сб, апр 10 2010, 19:23
Сообщения: 190
rass написал(а):
-DoKa- написал(а):
Было ли предоставлено решение озвученной проблемы? Столкнулись с такой ситуацией, которая усугубляется еще и тем, что в результате такого поведения у /322 не проставился сплит CNTR1 на TAX. И, как следствие, не сгенерировался /32E в RUTXD MDDE.


Приветствую! А вызов RUSPRO* не помогает?

rass, а как обозначенная Вами операция могла помочь (действий над сплитами не производилось, поэтому - нет, такой вариант не рассматривался)? Проблема наблюдается в момент работы функции RURTR, как и описывает RoustR. Изначально у сотрудника сплитованный на периоды кластер, вторая часть которого не содержит налогооблагаемых выплат (RUDAT, TAX и RUCNX практически пустые). Данный период пересчитывается без сплитования (это стандартное поведение, по сути), последствия и поведение в момент обработки RURTR в соответствии с описанием RoustR.


Последний раз редактировалось -DoKa- Пн, май 30 2022, 15:56, всего редактировалось 2 раз(а).

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

Зарегистрирован:
Чт, янв 13 2011, 10:54
Сообщения: 55
Ясно, я неправильно поняла суть бага.
Мы пока с таким не столкнулись.
Спасибо за раъяснения.


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

Зарегистрирован:
Пт, сен 07 2007, 07:53
Сообщения: 1392
Обнаружил еще одну ошибку в введении механизма RUCNX. Нас от поддержки SAP отключили, поэтому не знаю исправлена ли она на данный момент, но на всякий случай напишу сюда. Вдруг кому-то полезно будет.

В работе функции RURTR с параметром OC есть шаг переноса сумм удержанного НДФЛ из межрасчета в рег.расчет по схеме /322 -> /P22. За это отвечает процедура process_values_74_123. Так вот, эта процедура не адаптирована под RUCNX - записи из ORT, которые упакованы относительно ORUCNX, переносятся в IT/RT без перепаковки относительно RUCNX. Значит для перенесенных записей в RUCNX может не оказаться необходимого ключа.

Это не вызывает проблем пока RUDAT не переполнен - сплиты в ORT на TAX / RUDAT в такой момент адаптированы под таблицы текущего расчета. Может лишь появиться сообщение, что нет подходящего ключа в RUCNX, но при этом ключ будет самостоятельно правильно восстановлен. Но если RUDAT был переполнен, то это приведет к уже ошибки.

Проблема должна появляться в случае выполнения межрасчета 0105 с глубоким перерасчетом, когда RUDAT переполнен.

Исправление очень простое - при переносе записи из ORT нужно ее распаковать относительно ORUCNX и упаковать относительно RUCNX.


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

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


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

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


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

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