Большое спасибо за ответы!

Добрый день!

В таблице T7RURS для каждой причины увольнения указан подробный текст увольнения.
Например., в поле "Уточнение причины" указано "соглашение сторон (пункт 1 части первой статьи 77 ТК РФ)".
В новой таблице V_T77PADRU_RSLD выделены отдельные поля для ввода статьи, раздела, пункта , подпункта документа.

В отделе кадров утверждают, что в отчете СЗВ-ТД в поле "Обосн. приказа об увольнении" должно быть "соглашение сторон", и соответственно в отдельных полях номер статьи, пункт и т.д.
Но в то же время в приказе (ит0298) в причине увольнения должны быть указаны номер статьи, пункт и т.д.

Если в таблице T7RURS оставить причину "соглашение сторон " и в таблице V_T77PADRU_RSLD заполнить поля статья, раздел, пункт, подпункт документа, то в отчете СЗВ-ТД все будет корректно.
Но тогда в приказе в причине увольнения выйдет "соглашение сторон " без указания статьи и.т.д.

Подскажите, пожалуйста, может кто-нибудь сталкивался с таким вопросом, как должно быть?

С уважением,
Анастасия

что за поле "Обосн. приказа об увольнении"? В законодательной форме СЗВ-ТД (ни в печатной, ни в XML) такого поля (тега) нет...
Печатная форма в поставке не предлагается - получается, о ней и говорить нет смысла.
В XML есть тег "Причина", содержимое которого для события "увольнение" идентично формулировке, используемой в качестве причины-обоснования для приказов (форма Т8) - т.е. "длинный текст из T7RURS", а кроме того, атрибуты соответствующего нормативного акта формируются в отдельных тегах в соответствии со структурой XML файла и правилами заполнения (проверок) отчета. Каких-либо несоответствий правилам формирования отчета в таком результате, как представляется, нет. Если же должно быть как-то иначе, то необходимо уточнить: где, что и почему. А также чему несоответствует (противоречит) текущий вариант формирования результата в XML файле.
ALV же, присутствующее в отчете в качестве способа отображения результата - это, грубо говоря, некое техническое представление результатов для упрощения (хотя это кому как) их осознания пользователем. В целом, в некотором роде содержание данных в ALV соответсвует "сырым" данным и более-менее коррелирует с результатами в XML. И воспринимать его как точный аналог законодательной формы (в которой та или иная информация должна быть отображена в каком-то определенном законодательно обоснованном виде) - неправильно.

Подскажите, каким настроить, чтобы в транзакции HRPADRU_SVTD использовался не стандартный формуляр SVTD, а другой формуляр, скопированный из этого стандартного в Z ?

IMG: Payroll -> Payroll: Russia -> Reporting -> General Tools -> Form Output Table Framework
Define Customer Form Type for Form Group и Define Customer System Form Names and Variants for Logical Forms

@ZHmot
Здесь задается переопределение используемой трансформации.
А мне надо именно изменить, чтобы по умолчанию транзакцией HRPADRU_SVTD использовался Z-формуляр, который я создал копированием из стандартного SVTD в sm34 - VC_T7RU_99F0.

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

Вы про раздел формуляра "Клиентские переопределения полей" ?
Дело в том, что я не переопределяю существующее типовое поле, а добавил новое поле в раздел "Поля формуляра" и в "Определение раздела - Поля раздела" и потом уже их использую в переопределенной Z-трансформации.

Сначала пошёл по пути правки стандартного формуляра SVTD, но я думаю, что это неправильно.
А правильно -- скопировать формуляр в Z, в нём внести правки и переопределить, чтобы по умолчанию использовался именно Z-формуляр.
Но не получается настройками это сделать.

С таблицей T7799RU_CLASS тоже пробовал, но там надо создавать класс ZCL_HRPADRU_SVTD_PO наследованием от стандартного класса CL_HRPADRU_SVTD_PO, но проблема в том, что при наследовании нельзя переопределить константный атрибут предка GC_APPLICATION = 'SVTD' на своё значение.

В итоге куча всяких-разных настроек, но такой простой как изменение дефолтного формуляра нет.

Пока что выкрутился энхансментом в конструкторе класса CL_HRPAYRU_REPORT_CONTROL_CS, подменяя входное значение i_appl на нужное мне.

Неправильно - "обычно" или неправильно в данной задаче?
Допущу, что подобная реализация в отчетах как бы так косвенно "намекала", что переопределение стандартной формы нежелательно
Именно в данной задаче, как кажется, как раз-таки расширение стандартной формы недостающими Z полями и переопределение обработки стандартных полей - более удобный и предсказуемый подход: это, по крайней мере, позволит сохранить стандартный "каркас" решения и сократить затраты на поддержку переопределенной формы при изменениях в стандартной части.
Если очень же хочется все же уйти в Z-форму, то лучше, наверное, ее создавать не копированием со стандартной, а наследованием от нее.

Вопрос только в том, что когда приползёт очередное обновление формуляра SVTD от SAP, добавленные Z-поля пропадут и их придётся восстанавливать каждый раз или нет?
На этот вопрос я ответа так и не нашёл.
Поэтому было принято решение скопировать формуляр в Z, но столкнулись с такими вот сложностями переопределения его использования по умолчанию.

Насчет наследования -- да, согласен, можно попробовать так сделать, чтобы в Z-формуляре были только добавленные Z-поля, а все стандартные брались бы автоматически от формуляра-предка.

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

Добрый день.
Скажите, кому-то удалось реализовать расширение полей подразделение и должность с выводом в СТД-р и СЗВ-ТД полных наименований?
(подразделение DEPRT, должность POSIT)
Помогите, чем можете, пожалуйста. Столкнулись с необходимостью это сделать и набрели на трамплин в ПО, который не дает вывести полное название.
1. сделали в ИТ 294 доп. поля, куда предполагалось вводить "хвост" наименования.

СТД-Р:
вывести доп. поля не можем: размерность поля СТД-Р, в которое изначально записывается должность из 294ит - 1000 символов. Но в результате полное наименование обрезается до 200 символов.
Анализ ПО показал, что при дальнейшей обработке используются структуры, в которых поле только 200 символов. Например, HRPADRU_S_SVTD_LABOR_EVENT-POSITION.

СЗВ-ТД (тр. HRPADRU_SVTD):
Пришли к выводу, что это сделать невозможно т.к. необходимое поле в отчете имеет размерность 200 символов.

А вы как решили данный вопрос?

Именно этим я и занимался чуть выше в теме, чтобы не добавлять Z-поля в типовой формуляр.

Решение по расширению поля "подразделение" состоит из нескольких пунктов:
1) транзакция pm01
добавить поле ZZ_DEPRT в 0294 инфотип
2) транзакция sm34, кластер ракурсов VC_T7RU_99F0, формуляр SVTD
добавить поле ZDEPR в разделе Поля формуляра по аналогии с типовым полем DEPR, только со ссылкой на добавленное в инфотип поле ZZ_DEPRT
добавить поле ZDEPR в разделе Определение раздела - EVTE - Поля раздела XML-тэг ZZDEPARTMENT
3) транзакция strans
копировать трансформацию HRPADRU_SZVTD в ZHRPADRU_SZVTD
4) прописать, чтобы именно Z-трансформация использовалась через ведение таблиц T799BCFG и T799BCFT или проще через
spro - Расчет зарплаты - Расчет зарплаты: Россия - Система отчетов - Общие инструменты
5) в трансформации склеивать 2 поля: типовое и добавленное Z-поле
<xsl:element name="#StryktyrnoePodrazdelenie">
<xsl:value-of select="concat(string(./DEPARTMENT), string(./ZZDEPARTMENT))"/>
</xsl:element>
6) ну, и чтобы автоматом это дополнительное поле заполнялось при приеме/переводе в pa40, надо пилить энхансмент, в котором записывать в поле ZZ_DEPRT всё, что длиннее 200 символов
я расширял инклуд MP029440, FORM read_0297

Если читали тему выше, я вообще заморочился и скопировал типовой формуляр SVTD в Z- и нашёл куда в коде вставить энхансмент, чтобы переопределялось использование типового формуляра.
Но это уже совсем не тривиально. Достаточно добавить Z-поля в типовой формуляр и при обновлениях следить, чтобы не затёрлось.

jk3, огромное спасибо за развернутый ответ! Отправила программисту на "попробовать" ваш путь.
Спасибо вам большое! Бизнес пишет, что не примет в работу данные транзакции именно из-за этих наименований ((

Добрый день!

Подскажите пожалуйста. Установили все необходимы ноты для сзв-тд (2930129,2930226,2874131,2939624,2930126,2930226,2938675,2938814,2919183,2909510,2919187).

Настроили таблицы по мануалу, указаны какие мероприятия должны попадать в отчёт, + настроена область отчёта. (V_T591A,V_T7RU9PAR,V_T588M,V_T588D,V_T582G,V_T582A,V_T588M,V_77PADRU_LBACDF,T7RURPTCST00.)


Но когда запускаем отчёт, то он пустой программа не видит тн и мероприятия.

Возможно пропустили кукую-то таблицу, подскажите плиз.