DSN: FAQ

Symptom

This SAP Note lists the frequently asked questions and provides answers to them.

Solution

1:How to avoid conflicts between the SAP Notes related to the DSN during their implementation?

SAP Notes related to the DSN have to be implemented in their order of publication in SAP Note 2086721 – DSN: Summary of correction notes followed by their order of publication in SAP note 2178175 – DSN: Summary of correction notes (2) followed by their order of publication in SAP note 2243572 – DSN: Summary of correction notes (3) followed by their order of publication in SAP note 2306648 – DSN: Summary of correction notes (4) followed by their order of publication in SAP note 2386851 – DSN: Summary of correction SAP Notes (5).

2:How to avoid some inconsistencies during the creation of contract numbers in infotypes 0016 by the program RPCI16F0?

If you were using infotype 0016 before for France, you first need to make sure that the infotype view 3316 of this infotype were created. Execute report RPUPAV00 for country grouping 06 for that.
You might get the following message after executing report RPCI16F0: Data of infotype 0016 is inconsistent on database. Indeed there shall be exactly the same number of entries with the same database keys between databases tables PA0016 and PA3316, which is probably not the case. In that case, we recommend you to fix your entries by creating a database repair program.
In case infotype 0016 is used by your company already, it is necessary to ensure, before launching program RPCI16F0, that the employee’s history of infotypes 0016 have no gaps, that is to say periods for which no infotypes 0016 exist.
For example, the following situation will lead to inconsistencies:
• 01/01/2010 – 31/03/2010: Infotype 0016
• 01/04/2010 – 30/06/2010: No infotype 0016
• 01/07/2010 – 31/08/2010: Infotype 0016
Once you have executed program RPCI16F0 and check that the infotypes 0016/3316 are coherent, you have to activate the switch DSN16 for infotype 0016 in view V_T511K by setting its value to 1.00.

3:How to transport the content of tables filled by reports RPCDSNF1 and RPUDSNF2?

The tables filled by the report RPCDSNF1 (T5FDSNDDEF, T5FDSNFTYPE, T5FDSNENUM) are of type ‘S’ and their initial contents are attached to the SAP Note 2107535 – DSN PV1: Introduction of P02V05 version. For filling them in several systems, you may have 2 possibilities, either launch the report on each system, or create a transport order via transaction SE16 or SE16N. Note that, as it is mentioned in the second point of the part ‘Symptom’ of the SAP Note 2110854 – DSN PV3: MD, Payroll & DSN codes mapping, if you use the files attached to SAP Note 2107535, you have to specify the version ‘P02V05’ in the selection screen.
The table filled by the report RPUDSNF2 (T5FDSNCODCO) is a table of type ‘C’, and this report is not asking for a transport. But note that:

• an option in the selection screen of the report allows you to fill the tables T5FDSNCODCO in all the clients of the system you’re working on;
• in transaction SM31, a button “Transport” is available to include the entries to a transport request;
• in case of use of several systems you can launch the report on each system.

4:How to fill S21.G00.71.002 – Code régime Retraite Complémentaire?

Complementary Pension Institutions are defined in table T5F1R – via one or more entry(ies) corresponding to one or more CRC Modifier(s) – with an attribute “Agency number” equal to Axxx or Cxxx or Gxxx or RETA or RETC. Feature FDSC7 returns one or more CRC Modifier(s) per employee. Then the field S21.G00.71.002 if filled depending of the value(s) of the attribute(s) of the CRC Modifier(s) returned by the feature FDSC7:

• If = RETA –> RETA
• If = RETC –> RETC
• If = Axxx –> RETA
• If = Cxxx –> RETC
• If = Gxxx

o If the employee is “cadre” ou “extension cadre”:
–> RETC
o Else –> RETA.
And in the end, eliminate duplicates. For a “cadre” ou “extension cadre”, only a block 71 with RETC has to be generated (his assignement to rETA being implicit according to GIP-MDS guidance).

Note that S21.G00.71.002 is filled only if the feature FDSC7 returns one or more CRC Modifier(s) corresponding to one or more Complementary Pension Institution(s) and therefore one or more entriy(ies) in table T5F1R. Otherwise, it is filled with value 90000.

5:Do I need to respect a convention name when creating wage groups for the DSN?

For the DSN, the customer is free to define his own ‘Wage type groups’ using table V_T5F99FV sub-application “PAIE” in field ‘Wage type source group’, of course using the naming range dedicated to customers. Then, in table T5FWG, you assign attributes to the ‘Wage type groups’: the attribute ‘Wage type group type code’ (TYPCD) is used to qualify the ‘Wage type groups’ that you have created. For example, how to customize both tables to fill S21.G00.40.012-Quotité de travail de référence de l’entreprise pour la catégorie de salarié, if in my company I decided to fill it using a wage type:

• Create in table view in V_T5F99FV sub-application “PAIE” the ‘Wage type source group’ ZQRC, that will be used to determine the number of hours of the contract.
• Then, in table view V_T5FWG sub-application “PAIE”, assign attribute ‘Wage type group type code’ (TYPCD) CTQRN to the ‘Wage type group’ ZQRC.

6:How to understand, in SAP Note 2132551 – DSN: How to start with the DSN in the March 2015 payroll?, in scenarii 2 and 3 the sentence “Execute the March payroll without forcing the retroaccounting” (points 3.2 and 3.3)?

In these 2 scenarii, the March payroll is launched with the former schema that does not contain modification made for DSN.
The payroll process has to be run like you usually do it: in others terms, if during the normal run of March payroll you need to force a retroaccounting, do it.

7:In the selection screen of RPLDSNF0, the displayed version is P02V05, why does field S10.G00.00.006 include value P02V01 in the final file?

This is normal although a bit confusing. P02V01 is the official version name for the DSN start. But the GIP-MDS has a different versioning for the specifications file that the development team has to follow. The current one is 2014.P2.5. Therefore on the selection screen P02V05 is displayed but in the final file P02V01 is generated. In the specifications file 2014P2.5, it is clearly stated that field S10.G00.00.006 can only include value P02V01.

8:I am receiving an error message when executing the payroll with my new DSN schema. What could be the reason?

The order in the call of the new DSN payroll functions is critical, please see the documentation for more details. Basically, FCT and FPERS should be called before the other DSN payroll functions, and very important, FCHEC should be called after all the other DSN payroll functions, just before the export to the cluster.

9:When implementing a SAP Note with SAP Note Assistant (snote) I am receiving the error message “Note incomplete”. How should I proceed?

Follow the process described in SAP Note 1939285.

10:What payroll schema shall I use with program RPCDSNF0?

You have to use your DSN-ready payroll schema. The DSN customizing has also to be complete before the execution of program RPCDSNF0.

11:I have launched the RPLDSNF0 report for multiple SIRET and:
– the contributions blocks 22/23 are generated only for one SIRET; launching the report SIRET by SIRET, the blocks 22/23 are well generated.
– no files are generated for those SIRET; launching the report SIRET by SIRET, a file is created as expected.
What is causing these behaviors?

The issue described above may occur because of a FTDS2 feature wrong customizing: indeed, when several SIRET share the same SIREN, then every area/subarea behind those SIRET must return through the FTDS2 feature the same “master” area/subarea.

12:What can I do if the execution of program RPCDSNF0 ends with a short dump (due to memory consumption or time-out) or lasts for a too long time?

You can use program RPCS0000 to generate job executions of program RPCDSNF0 for groups of employees. See the attached document RPCS0000_for_RPCDSNF0.pdf. Note that program RPCDSNF0 calls program RPCALCF0 in simulation (as mentioned in program documentation, not marking the “Display log” checkbox in the selection screen of RPCDSNF0 reduces the execution time). The execution time mainly originates from RPCALCF0 and is dependent of how many employees and payroll periods are processed. This execution time cannot be reduced.

13:What can I do if I do not succeed to generate DSN aggregated contributions blocks with the right amounts?

It is allowed to generate a DUCS in parallel to the DSN to substitute the DSN contributions declaration. Please refer to http://www.dsn-info.fr/documentation/dsn-mep-p2.pdf for the detailed process. Please also notice that once you have declared the contributions solely in the DSN, you cannot generate anymore a DUCS to “override” the contributions amounts declared in the DSN. Therefore it is wise to continue generating your DUCS declaration during the first months of the DSN. This allows you to test the DSN contributions blocks in parallel with your DUCS declaration. This is the SAP recommended process. See also question 27 below.

14:How to declare the CICE for employees having left the company before the month of declaration?

The SDDS (the association of French payroll software editors to which SAP belongs to) has sent a mail to the DSS (Direction de la Sécurité Sociale) to state that declaring the CICE accumulated over the year violates the monthly declaration principle of the DSN. The DSN has to be the last step in the monthly payroll process. Since no answer has yet been received, you have to include “manually” the CICE amounts in the DSN aggregated contributions blocks using the view V_T5FDSNCOTIC. Additionally, it is recommended to remove the contribution code 400 from view V_T5FDSNCOTIS2.

15:What could be the reason for having retroaccounted amounts being not generated in the remuneration blocks?

Check that customizing table T5FDSNPAVAL includes the following entries:

TABLE INCOMPLETE

16:Why is a block 23 generated for a contribution code that is not relevant for the processed employee according to the second contribution grouping (GRCO2) in table T5FDSNCOTIS2?

Feature FDSG2 that returns the value for the second contribution grouping (GRCO2) in T5FDSNCOTIS is wrongly customized. The return value shall have 4 digits, e.g. 0001.

17:What should I do to avoid a short dump in the DSN programs after having installed a note delivering a structure change for a feature?

Actually when the structure of a feature is changed you have to activate this feature first in the client 000 of your system.

18:After having executed RPCDSNF0 or RPCALCF0 with the DSN payroll schema for the March payroll and having forced the retroaccounting down to the maximum allowed retroaccounting date, is it normal that RPLDSNF0 based on the March payroll results is not generating any recalculated period?

Yes, it is. The first productive DSN will be the one based on the April payroll results and will generate recalculated periods (if any). The DSN based on the March payroll results is not functionally relevant because of the special DSN start process.

19:How to manage in the DSN, a payment for a short-term contract that has started and ended before the start of the LSE (“Loi sur la Sécurisation de l’Emploi”) law?

In case you have a payment (for example profit sharing) for a short-term contract that started and ended before the law LSE, it is not possible to maintain the code ‘Motif de recours-S21.G00.40.021’ in the infotype 0016/3316 since it was introduced only after July 1, 2013, but it is mandatory in DSN format. In such a case, you should assign in view V_T5F42 for a contract type the code ‘Motif de recours’ (V_T5F42-MRCDD): if you have an employee having this contract type with no ‘Motif de recours’ maintained in the infotype 0016/3316, the code ‘Motif de recours-S21.G00.40.021’ in DSN will be filled using the code ‘Motif de recours’ maintained in V_T5F42.

20:How to understand both sentences “Execute program RPLDSNF0 in test mode selecting the same population and execute the control tool DSN-VAL” and “Check that there is no error in the assignment of payroll results (stored – in scenario 2 and 3 only – in the transparent tables) to the DSN codification and in the DSN control tool DSN-VAL in SAP Note 2132551“DSN: How to start with the DSN in the March 2015 payroll?”

What is to be checked after the March DSN payroll (or after the DSN payroll preceding the payroll used for the 1st DSN) is the DSN customizing that generates the values of the fields in the DSN payroll cluster tables. Those values have to be functionally right and compliant with the DSN specifications. You do not have to check the functional correctness of the DSN generated from the March payroll results because several blocks might be wrong due to the absence of the DSN payroll cluster tables in the previous payroll results. Only the DSN based on the April payroll results will be functionally right. Because The DSN cluster tables have been generated during the March payroll for all payroll periods down to the maximum allowed retroaccounting date.

21:How to activate the user’s authorization profile when displaying a DSN KPro file?

The user’s authorization profile put in place for displaying a DSN KPro file is activated only when using the DSN B2A dashboard (RPUDSNF1). This means that you have to execute RPLDSNF0 with the checkbox “Activer B2A”marked. The user’s authorization profile includes dedicated transactions that are assigned to specific user role tasks. In addition, it is possible to implement additional authorization checks for displaying specific parts of the DSN KPro file in method CHECK_DECL_AUTH of BAdI HRPAYFR_DSN. For more information, please refer to the DSN documentation available in the SAP Service Marketplace, chapter “Personnalisation” (page 180) in the French version or chapter “Customization” (page 184) in the English version. Please note that the use of the DSN B2A dashboard is mandatory for the management of the types “Cancel and replace” and “Cancel” of the DSN.
If the checkbox “Activer B2A” is not marked when executing the DSN program RPLDSNF0, then the DSN KPro file is not available in the DSN B2A dashboard. The user’s authorization profile is not activated, and the file can be displayed by any user having authorization to execute the DSN KPro file viewer (RPUFLE9S). Therefore the authorization to execute RPUFLE9S has to be restricted to a limited number of administrator users.

22:How to set a WPBP split on my gross up wage type? (M200 in standard)

Please refer to note 2155916.

23:May I use the same contract reference for two or more payroll cluster splits?

No. A payroll cluster split means a new contract with a new pay slip. Therefore the contract reference has to be different between different payroll cluster splits.

24:Some fields are not generated (ex: block 60 or 62)

All fields in the DSN have an admissibility that depends on the nature of the declaration. This admissibility is defined in the technical specification of the DSN (cahier technique DSN). For instance field S21.G00.62.003 shall not be filled in the DSN of nature 01 (monthly DSN) and only be filled in the DSN of nature 02 (end of contract).

25:Why does the codes of the dropdown list for field “Motif de recours” (MRCDD) in infotype 0016/3316 does not match DSN specification codes?

This field is used by the N4DS and DSN programs but the codes are different for each declarations. There are more codes available for the DSN than for the N4DS. Several DSN codes are grouped in an N4DS “generic code” named “Autres motifs de recours”. Some codes have a different meaning in N4DS and DSN.
As a consequence the code list displayed in infotype 0016/3316 is neither the list of codes for the DSN nor the list of codes of N4DS but a SAP list of codes. The code entered in the infotype will be converted to the code required by the corresponding program, either DSN or N4DS.
There is however one exception. The generic code 03 “Autres motifs de recours” shall not be used anymore since there is no corresponding code in DSN. This is the reason is why a message is raised in the payroll log if it is still used for an employee. Code 03 is kept in the list for compatibility reason for old infotype records. The end user has to maintain the code in the employee infotype 0016/3316 according to the text (but not using code 03). For instance, if the contract of the employee is corresponding to reason “Remplacement d’un salarié” then the end user has to select “Remplacement d’un salarié” that corresponds to SAP code 04. Code 04 will be convert to 03 “Autres motifs in N4DS”. Code 04 will be converted to 01 “Remplacement d’un salarié” in DSN. For the DSN, the mapping in done in table V_T5F99FMAPS for countr grouping 06 of sub application “DSN”.

26:May I use any field available in the F4 help for column “Zone” (FIELD) in view V_T5FDSNCOTIC?

No. You shall not use the value “SEKEY” because this is a technical field and that its length might exceed the length of field “Valeur” (COALP) in view V_T5FDSNCOTIC.

27:Should I send the DUCS declaration for the April contributions and for the following months?

Yes. Because of a too short pilot phase with the administration (the response time of the administration was terrible) and because the administration initially has requested productive declarations, SAP asks you to continue generating DUCS declarations in parallel to the DSN in order to mitigate the risks of an unexpected error. You have to generate the DUCS declarations as usual for the contributions of April 2015 even if you have double-checked that they are correct. Because once you have sent a DSN and stopped sending a DUCS then the administration switches to the DSN declaration and you cannot send anymore DUCS declarations. If an problem would occurred in the contribution part of the DSN for the May contributions you would not be able to generate a DUCS declaration to overwrite the DSN data.

28:How to generate a Cancel-Replace for a monthly DSN for which a B2A process was mistakenly not created?

The document “Comment faire une « Annule-Remplace » d’une DSN Mensuelle pour laquelle aucun processus B2A n’avait été créé” describes in detail the steps to perform to generate a Cancel-Replace in this specific case. For more information, please read this How to document pusblished on the Service Market Place under Resources -> DSN at http://service.sap.com/hrfr.

29:According to the update of April 17, 2015 of the user manual “Comment déclarer les cotisations URSSAF en DSN ?”, contribution type (CTP) 801 has to be declared in field S21.G00.23.004, however RPLDSNF0 generates the amount in field S21.G00.23.005, is my declaration going to be rejected?

No. Actually the GIP-MDS has admitted that this change was published very late. Therefore if the amount for CTP 801 is declared in field S21.G00.23.005 instead of S21.G00.23.004, it will be ignored by the ACOSS and a warning message “Montant déclaré différent du montant calculé” will be generated. Since you will continue sending your normal DUCS that will overwrite the DSN contributions declaration, no action is required. However, SAP works on delivering a fix as soon as possible. The fix is now available with note 2163315.

30:I have sent a productive DSN with contribution retroaccounted periods, but I cannot modify the DUCS in EFI mode. How can I fix the wrong contributions?

The French administration has acknowledged that it was its error. They have allowed several workarounds. Here a short summary list, please refer to the attached email DUCS_after_DSN.pdf.

• You can generate a corrective DUCS in EDI mode.
• It will be possible to maintain a corrective DUCS in EFI mode between May 5, 2015 at 13:00 (CET) and May 6, 2015 at 11:00 (CET).
• If you have not yet sent your DSN, you can choose to not send the contributions aggregated blocks, and continue sending the DUCS as before.
• If you are unable to send the contributions data neither in the DSN nor in the DUCS EDI/EFI, then you have to contact the URSSAF.

31:What should I do if my DSN file including several declarations of type “Cancel and Replace” is rejected with error message “An included declaration cancels another included declaration”?

The GIP-MDS has acknowledged that it was its error. There is currently no fix. You have therefore to send separately your declarations of type “Cancel and Repalce”. See the attached email Cancel_And_Replace_Rejected.pdf for details.

32:After sending a DSN file to the French administration, what should I do if I receive the following message “The GIP server has answered but it is a system error”?

The GIP server is probably unavailable. Please try sending the file again later.

33:Is it possible to use different source tables for a same contribution in V_T5FDSNCOTIS2?

Yes, but there is a limitation. All the three fields used for determining the contribution rate, assessment base and the amount have to use the same source table. As an example, you could use the RECOT table as source table for the contribution rate, assessment base and the amount and the RT table as source table for the INSEE code. It is not allowed to use for instance the RT table as source table for the contribution assessment base and the RECOT table as source table for the contribution rate and amount.
SAP recommendation is to always use the RECOT table as source table for the contribution rate, assessment base and the amount. If you however use the RT table, then it is mandatory that the corresponding wage types carry the SV split.

34:What is the prerequisite to install corrections to the DSN phase 2 and new developments for the DSN phase 3 after the productive start in May 2015?

Please refer to note 2145909.

35:Some blocks 51 have been generated for a rehired employee with a payroll period start date (field 51.001) greater than the payroll period end date (field 51.002), which is leading to an error (CCH-11) in the “DSN-Val” control tool; what is the cause of this error and how can it be fixed?

This error may be linked to a wrong infotype 0016 maintenance: in the case mentioned above, for a rehired action, a new infotype 0016 record with a new contract number has to be maintained at the date of the rehiring.

36:Is it allowed to reuse the same contract reference after a leaving action and a re-hiring action?

No. A leaving action followed by a re-hiring action has to always be associated to a new contract reference. A check will be put in place in a near future in infotype 0016 to enforce this rule.

37:How can I check the DSN results for the contributions, especially if I have a large number of SIRET?

While displaying the DSN select one block of the type you would like to check. E.g. select one block 23 if you would like to check the contribution results in all blocks 23. Then click on the “Download Spreadsheet” icon. All the content of all blocks of the selected type for all SIRET included in the declaration are downloaded to an Excel file. Then you can easily compare with the results originating from program RPLCOTF2, H99CWTR0 or RPLDUCSF0.

38:Why is no DSN declaration generated when I select declaration type 02 “Déclaration néant” in RPLDSNF0?

This happens if no employee having belonged to the SIRET for which you want to generate a “Déclaration néant” is selected. Check your selection criteria (payroll area, etc.) because at least one employee who belonged in the past to the corresponding SIRET has to be selected. If you have a SIRET without employee at all, then check SAP Note 2178263.

39:Why is contribution type 100D not generated in the DSN?

If you select the official format 04 “Cotisations agrégées format GIP-MDS” in the selection screen of RPLDSNF0 then no contribution type 100D is generated in the DSN declaration if there is already a contribution type 100A. This is the normal behavior that follows the declaration rule originating from the ACOSS organization (cf. http://www.dsn-info.fr/documentation/declarer-cotisations-urssaf-en-dsn.pdf). However you can always generate the contribution type 100D by choosing the option 03 “Cotisations agrégées format GIP-MDS avec montants et taux” in the selections creen of RPLDSNF0 for checking/test purposes. Refer to point 1 in note 2126228 for more information.

40:How to define authorizations to execute the RPLDSNF0 depending on the nature of declaration?

You can create specific transactions (one per nature of declaration). You would then give the authorizations to execute those transactions to the relevant users. The users shall of course not have the authorization to execute the standard transaction PC00_M06_DSN_REP.

41:How to be compliant with the legal requirement of generating an event declaration of nature “end of contract” in the five days following the event?

If the general execution of the payroll has been already performed or is planned in more than five days, you have to generate a monthly DSN declaration together with the “end of contract” event DSN declaration. This means that you have to execute the payroll for the leaving employee and then generate a monthly DSN declaration selecting only this employee and obviously an event “end of contract” DSN declaration. Later, when you will generate a monthly DSN for the whole population of the SIRET to which the leaving employee was belonging to, you will generate a monthly DSN of type “Cancel and Replace” that includes also the employee who’s left.

42:Despite all my effort, I am still struggling to produce a DSN with a high quality of the data. How could I avoid having to send DSN with bad data quality and to not pay penalties to the French administration?

After several complains from the MEDEF (the largest employer federation in France), the French administration has released the following statement:”En réponse à la demande officielle du MEDEF face au retard d’un certain nombre de développements techniques indépendant de la volonté des entreprises, la Direction de la Sécurité sociale a décidé d’instaurer les mesures de tolérances suivantes :
– aucune pénalité ne sera appliquée par l’URSSAF en cas d’absence de transmission de la DSN lors de la 1ère échéance prévue les 5 et 15 mai 2015,
– et aucune pénalité ne sera appliquée par l’URSSAF pour les trois échéances suivantes (DSN de juin, juillet et août), dès lors que l’entreprise a pris contact préalablement avec l’URSSAF et a démontré les efforts engagés et la réalité des problèmes rencontrés.”

Shortly translated, it means that there will be no penalties from the URSSAF for the DSN based on the April 2015 payroll results if it has not been sent, and there will be no penalties from the URSSAF for the DSN based on the May, June and July 2015 payroll results if it has not been sent and if you could demonstrate that you have made all possible efforts to generate it but you were facing actual problems.

43:Why is the INSEE code (field S21.G00.81.005) not generated for contribution code 226?

For block 81 and contribution code 226, you have to use the RECOT table (and not the RT) in your customizing of view V_T5FDSNCOTIS2 for DAQ section CPRO.
The RT table shall only be used for the DAQ section CBAS that corresponds to block 79 of the DSN with codes “01 – Montant du SMIC retenu pour le calcul de la réduction Fillon” and “02 – Montant du SMIC retenu pour le calcul du crédit d’impôt compétitivité-emploi”. For all other contributions blocks 23/78/81 (corresponding to the DAQ sections CAGR/BASE/CPRO), the RECOT table has to be used.

44:Why contribution type 027D using option 03 is generated with rate equals 0.20 instead of 0.016 in the DSN?

If you select format 03 “Cotisations agrégées format GIP-MDS avec montants et taux” in the selection screen of RPLDSNF0 for testing purposes, then field “Taux de cotisation” (S21.G00.23.003) is displayed with value 0,20 instead of the calculated value 0.016. This is the normal behaviour, because the expected format of the GIPS-MDS has only two decimals. As consequence the calculated rate 0.016 is rounded up to 0.20. Be aware that, with option 04 “Cotisations agrégées format GIP-MDS”, following the declaration rule originating from the ACOSS organization (cf. http://www.dsn-info.fr/documentation/dsn_cahier_technique_p2v5.pdf), field S21.G00.23.003 must not be provided.

45:How could I improve the performance of the DSN B2A Dashboard (program RPUDSNF1 or transaction P00_M06_DSN_B2A_ADM)?

Defining indexes for tables T5F99SE and T5F99SR increases significantly the performance of the DSN B2A Dashboard. You can create indexes in transaction se11 clicking on the Index… pushbutton. The index fields shall be the following: MANDT – MOLGA – TYPRO – STMOD – PERNR – GLBID – STATS for table T5F99FSE, and MANDT – MOLGA – TYPRO – STMOD – GLBID – STATS for table T5F99SR.

46:What is to do if a short dump “OBJECTS_OBJREF_NOT_ASSIGNED_NO CX_SY_REF_IS_INITIAL” occurs in class CL_HRPAYFR_DSN_CONTRIB_CORR?

SAP is working on a fix for this problem. The problem might appears if the first entry for a given SIRET in view V_T5F1P corresponds to a personnel area/subarea that is no more used and for which no customizing has been done in tables T596M and T596NV for the use of the contribution correction table T5FDSNCOTIC. Until the fix is provided by SAP, you can perform the following workarounds: either delete the corresponding entry if it has no impact for you or maintain the customizing in tables T596M and T596NV for the corresponding personnel area/subarea.

47:Is it allowed to use a personnel area/subarea for more than one SIRET?

No. A personnel area/subarea has to be assigned to one single SIRET. Since there are no validity dates in table T5F1P, this means that a personnel area/subarea that is not anymore in use cannot be reused for another SIRET. Whenever a personnel area/subarea is no more in use then it cannot be used anymore except for the very same SIRET as the initial one.

48:How do I correctly manage a change of SIRET?

A change of SIRET has always to be associated to a change of personnel area/subarea.

49:How to test an event DSN declaration of type “Cancel and replace” for a productive event DSN declaration?

You cannot generate an event DSN declaration of type “Cancel and replace” in test for a productive event DSN declaration. You can however generate it from the test event DSN declaration that you had generated to be on the safe side before generating the productive event DSN declaration.

50:Why is field S21.G00.30.020 (NTT) not filled with the personnel number of the employee?

Field S21.G00.30.020 is a concatenation of the gender, SIRET and the CP (central person) of an employee. The CP is a technical number used in organizational management that is unique across all personnel numbers of an employee. Notice that in infotype 0002 (Personal data) you shall not use field Q0002-INSTY: this field has been introduced for the public sector project “Trésorie générale” (TG) that has been disused and SAP recommends to hide it in your systems.

51:Is it needed to install also the EA-HRCFR synchronization support packages?

Yes. When you install a SAP_HRCFR synchronization support package always install it together with the corresponding EA-HRCFR support package. The purpose is to synchronize again the objects of software componenent EA-HRCFR with the objects of software component SAP_HRCFR. It is even more important to install the EA-HRCFR synchronization support package because the two software components are getting out-of-synchronization with each installation of a SAP_HRCFR CLC (no corresponding CLC being delivered for EA-HRCFR).

52:Since the installation of note 2215878 (or the corresponding HR-support packages 21 for releases ECC 6.0 EhP8, EhP7, EhP6, EhP5, 93 for releases ECC 6.0 EhP4, EhP3, EhP2 and C7 for release ECC 6.0) in my development or quality system, why does the selection by SIRET or by employees not work for employees whose data have been copied from another system or client? How can I fix this selection problem?

With the introduction of note 2215878, the selection by SIRET and by employees make use of transparent tables HRPY_RGDIR and HRPY_WPBP. Those tables include payroll results data and are filled automatically when the payroll results are created. However, when employees data are copied from another system (e.g. from the productive system) or from another client to the development or quality system, the content of those both tables might be not copied depending of your copy tool. If the content of those tables is not matching the content of payroll results clusters then the selection problems described in the question might occur. It therefore makes sense to adapt the copy tool you are using to include the content of tables HRPY_RGDIR and HRPY_WPBP. In the meantime, you can also create the content of tables HRPY_RGDIR and HRPPY_WPBP from the payroll results clusters using program H99U_RGDIR_WPBP.
Whenever you copy employees data from another system or from another client, ensure that the content of tables HRPY_RGDIR and HRPY_WPBP for the selected employees is also copied or execute program H99U_RGDIR_WPBP in the target system for the selected employees.

53:Why are some contribution types (CTP) not working correctly after having uploaded the contribution customizing file from the ACOSS in table T5FDSNCODCO using program RPCDSNF2?

The contribution customizing file from the ACOSS does not categorizied as “deduction” the regularization CTP of deductions. Since uploading the contribution customizing file from the ACOSS erases all the existing entries in table T5FDSNCODCO, you have to categorizied again as “deduction” the regularization CTP of deductions. We recommend to store the content of table T5FDSNCODCO before uploading again the contribution customizing file from the ACOSS. It is then easier to introduce your changes back.

54:Note 2207439 has the field ARBAN in the checksum but from SP C7/93/21 this field is not anymore in the checksum, why?

Due to an error of synchronisation, the field ARBAN of the section ARTR has been unselected by mistake in the view maintenance V_T5FDSNCHECKSUM. Please select this field for the checksum (only for the columns ‘DSNA’ and ‘DSNR’). With the SP D0/96/24 the field will be selected again.

55:Can the contribution type 100A be customized using the RT table in view V_T5FDSNCOTIS2?

No. The contribution type 100A has to be customized using the RECOT table in view V_T5FDSNCOTIS2 because it has a specific behavior requiring its alignment with the contribution type 100P.

56:Why is no block 50 generated in case of net regularization? What should I do to declare a net regularization?

Block 50 in case of net regularization are not supported by the GIP-MDS. You have therefore to transfer the net regularization to the current payroll period.

57:Why are the two date fields of the infotype view 3395 filled with ‘ . . ‘ instead of ‘00000000’ when I use transaction pa70 for mass filling the French infotype 0015?

You are actually using the international screen of infotype 0015. The international screen of infotype 0015 does not include the infotype view 3395. It is therefore not initialized. To avoid that, you have to use the French screen of infotype 0015 either by entering 0015/06 in the selection field or by adding it to the upper left table control in V_T588B.
SAP Note 2332084 ensures that infotype 3395 records are correctly initialized in pa70 even if the international screen for infotype 0015 is selected. With the installation of this SAP Note, the problem shall not occur anymore.

58:The declaration nature 04/05 can have different results when nature 01/02 is or is not selected. Why?

When only the nature 04/05 (“Arrêt de travail / Reprise de travail”) is selected in the selection screen, the system simulates the payroll from the infotype data –> it will ignore all the clusters tables generated for the in period (INPER) selected in the selection screen. In doing the simulation, the system will take from the infotype the latest data known. Take into account that the system will find from the infotype 0003 and RGDIR the retro period to simulate.

• With this simulation mode it’s mandatory to select a period in the selection screen that has not yet been re-calculate in another period. If you run the report for February 2016 and February has been re-calculate in March then you have to have to run the report for March.
• With this simulation mode, you can have the NIR, Name of the employee, contract number, SIRET,… that can correspond to a value that is not the latest one defined in the infotype. This is normal when the monthly DSN of the period selected in the selection screen has not yet been sent to the GIP-MDS. The GIP-MDS expects to have the nature 04/05 with the values that they are aware of.

When the nature 04/05 (“Arrêt de travail / Reprise de travail”) is selected in the selection screen and the nature 01/02 is also selected, the system will read the payroll data only from the clusters tables. In this mode all the data generated in the declaration nature 04/05 will correspond to the data of the cluster tables –> any modifications done in the infotypes after the payroll run will not be in the decaration nature 04/05.

59:Why is field S21.G00.40.019 “Identifiant du lieu de travail” filled although it is equal to the content of fields SIREN – S21.G00.06.001 + NIC – S21.G00.11.001?

In DSN phase 3, field S21.G00.40.019 is mandatory and has to be always filled. This has been implemented already in the DSN phase 2 because it is allowed to always fill field S21.G00.40.019.
You will notice that for the first payroll period in which this change is present, a block 41 with field S21.G00.41.013 filled is generated for some employees, and the following warning message “Loophole value 73282932000074 has been generated” (number 054 of the message class HRPAYFR_DSN) will be also generated in the log for those employees.
In case you do not want this message to appear in the log, you may use the “Message Mapping Tool” (“MMT”) to hide this warning message (see the note 2258133 for more details on how the MMT can be used).
It must be here highlighted that generating such a block 41 has here no incidence on the correctness of the transmitted DSN data.

60:What do I have to do if the PI/XI/PO system returns the error “Adapter Framework : org.xml.sax.SAXException: Fatal Error: URI=null Line=1: Premature end of file”?

We recommend you to implement the SAP Note 2338389 “Axis receiver channel could not process HTTP responses with compression” to solve this issue.

61:What customizing has to be done for the “prévoyance” contributions if there are several contracts for which the same couple ORGAN/COTIS is used for a given population?

You shall create only one MODA2 (Modifier for insurance and “prévoyance” contracts) and assign it to the relevant contributions in V_T5FDSNCOTIS2. In view V_T5F1BAP_DSN, you shall identified the different contracts using different values of CBMOD (Modifier for “prévoyance” contract) returned by feature FPREV.

62:I have an error message “Lecture T5F1BAP, aucune entrée trouvée avec mod.1 xxxx mod.2 0000 mod.3 yyyyy” when executing program RPLDSNF0. How can I fix this error?

In the error message one of the three modifiers has a value equal to 0000. If it is for modifier 1, then value 0000 has been defined in table T5F7B. If it is for modifier 2 then feature FRATE returns value 0000. If it is for modifier 3 then feature FPREV returns value 0000. However, an empty field is not equal to value 0000 in view V_T5F1BAP. Either you have to maintain value 0000 in view V_T5F1BAP or return an empty value in feature FRATE or FPREV.

63:Why is the implementation of blocks S89.G00.32, S89.G00.33, S89.G00.35, S89.G00.43, S89.G00.87, S89.G00.88, S89.G00.89 not yet delivered?

It is not mandatory to declare the information included in the blocks S89.G00.32, S89.G00.33, S89.G00.35 and S89.G00.43 in the DSN. The declaration channels used before the DSN creation can still be used for those blocks.
Blocks S89.G00.87, S89.G00.88 and S89.G00.89 can be declared on a yearly base.

64:Why do I get errors in DSN-VAL for the payment blocks 20 after the generation of the DSN Phase 3?

With the DSN Phase 3, the payment of contributions (other than URSSAF) have been included. The rules to generate the required blocks 20 depend of the recipient organization of the payment. Those rules might be quite complex and require in some cases to modify several DSN declarations. E.g. In the case of a SIRET paying for the other SIRET of the same company, the DSN declarations of all the SIRET of the company have to be modified by transferring (that is just one example of one rule, but as mentioned the rules are different depending of the recipient organization) the payments blocks of all SIRET from their DSN declaration to the DSN declaration of the SIRET that actually performs the payment.
Since the payment process requires that the DSN declarations of all SIRET of a company are generated, it is performed in a separate step (as a post-process of the DSN generation). This is unavoidable for the reasons mentioned above and had unfortunately the drawback that there might be errors for the block 20 in DSN-VAL when checking the DSN declarations just after their execution. You have therefore to ignore in a first step those errors in blocks 20 and fix the errors in the other blocks. Once this is done, then you can proceed with the payment process. Before sending the DSN declaration to the administration, you can then again execute DSN-VAL on the DSN declarations. The errors for blocks 20 should have disappeared. If it is not the case then you have to fix the customizing of the payment process (but this should not require a new execution of the payroll).

65:How could I improve the performance of the DSN B2A Dashboard (program RPUDSNF1 or transaction P00_M06_DSN_B2A_ADM) with ORACLE database?

Ignore the indexes given in point 45.
Defining indexes for tables T5F99SE and T5F99SR increases significantly the performance of the DSN B2A Dashboard. You can create indexes in transaction se11 clicking on the Index… pushbutton.
For table T5F99SE, the index fields shall be the following: Index1: PERNR and GLBID – Index2: GLBID and STMOD.
For table T5F99SR, the index fields shall be the following: Index1: GLBID and STMOD.

66:Is it possible to list all the payment references of all the payer SIRET for a given month?

In standard there is currently no such an option. However if you create a database table with the required data (SIRET, period, payment reference…) you could fill it by implementing method EXECUTE_ADDITIONAL_PROCESS of BAdI HRPAYFR_DSN_PP_CUST_PROCESS. Querying the content of this table would provide you with a list of payment references.

67:Why is a block 20 generated for the AGIRC-ARRCO with payment type 02 although in the specifications block 20 shall not be generated for the AGIRC-ARRCO and payment 02 is not allowed for the AGIRC-ARRCO?

This block 20 is generated for payment control purpose. The AGIRC-ARRCO has confirmed that although they are not using the block 20, its presence is not a cause of rejection. Furthermore the AGIRC-ARRCO has also confirmed that payment type 02 is allowed.

68:The result provided by the step ‘finalisation de versement’ is not correct, what do I have to check first before to create an OSS message?

You have to check that you have implemented at least the note 2406512, 2388870, 2406639 and optionally the notes that have a description that starts with “DSN: PP”.

69:The BADI HRPAYFR_DSN_B2A_SIRET_PAY_SKIP can be used or not and for what?

This BADI can still be implemented by the customer. This BADI is used just before to send or download the DSN, it checks if the step ‘finalisation de versement’ has to exist or not before to allow the sending/downloading of the DSN.
This means that the customer can bypass the step ‘finalisation de versement’ from the implementation of this BADI. BUT the customer has to be aware that some specifics adjustement done by the step ‘finalisation de versement’ will not be processed in this DSN (like blocks 20 for the OC will not have the period 01.01.2000, the blocks 20 AGIRRC-ARRCO (919/920) will not be transformed to 907, blocks 55 will not have the correct ‘Type Population’,…).

70:I have several unexpected blocks 78, 79, 81 and or 20 dated from previous payroll periods generated in the DSN declaration. How can I fix it?
Ensure that the entries in table T5FDSNCOTIS2 are all valid at least down to the maximum retroaccounting date of your payroll areas.

71:Why is the error message ‘Toutes les décl. SIRET non-payeur doivent avoir l’étape “vers.finalisée”‘ displayed when executing the B2A?

In transaction snro, create an interval
01 00000000000000000001 99999999999999999999
for HR_FR_DSN. Then create again the B2A of your declaration and execute again the payment finalization.

72:Why are the dates in block 20 set to 01012000 for the “Prévoyance” organizations?

According to the specifications, the dates in block 20 are irrelevant for the “Prévoyance” organizations and have therefore to be set to 01012000. Please refer to the specifications of fields S21.G00.20.006 and S21.G00.20.007.

73:Why is a block 20 generated for the URSSAF with payment types different than 05 although in the specifications block 20 shall be generated for the URSSAF only wiht payment type 05?

This block 20 is generated for payment control purpose. The URSSAF has confirmed that its presence with a payment type different than 05 is not a cause of rejection.

74:Why are the “Prévoyance” contributions not generated in the DSN although I have configured them using the RT table as source in view V_T5FDSNCOTIS2?

You cannot use the RT table as source in view V_T5FDSNCOTIS2 for the “Prévoyance” contributions. You have to use the RECOT table as source.

75:In case of quarterly payment of the contributions, is it allowed to have a different number of SIRET fractions in the months included in the quarter?

No. You have to have exactly the same number of SIRET fractions in each month included in the quarter in case of quarterly payment of the contributions. The same rule applies for other payment periodicities greater than one month.

76:My company, using shifted pay, has to make a quarterly payment to an organization (OPS) based on shifted periods, i.e. the first quarter corresponds to the months of December, January and Febraury. However the payment finalization process generates a payment only for the civil quarter (months of January to March). How should I proceed to have a shifted quarter?

You have to implement method CHANGE_T5FDSNOPSTY_RECORD of BAdI HRPAYFR_DSN_PP_T5FDSNOPSTY modifying the parameter cs_t5fdsnopsty-shift for the relevant type of OPS. If you would like to change also the payment date then you have to implement method GET_PAYMENT_DATE of BAdI HRPAYFR_DSN_PP_PAYMENT_DATE.

77:How to manage the anticipated payment (because of an employee’s leave for instance) of a non-monthly bonus for the year Y that occurs on the same month than the payment of the same bonus but for year Y-1?

If the same bonus is paid more than once during a month and if the “rattachement” periods have to be different, then you have to have two different wage types for that bonus: one for the payment at the planned deadline and one for the anticipated payment. You cannot use an infotype 0015 record for that business case because all records with the same wage types and with payment dates in the same month are merged in cluster table REM using the “rattachement” period of the oldest record.

Example: a bonus with a “rattachement” period from 01.01.2016 to 31.12.2016 is paid in March 2017. An employee who is leaving the company on March 17, 2017 receives additionally a prorata of the same bonus with a “rattachement” period from 01.01.2017 to 17.03.2017 paid in March 2017 with his “solde de tout compte”. In order to generate two blocks 53 with the same bonus type but with different “rattachement” period in the DSN with the declared month March, you have to use two different wage types for this bonus: one for the for the payment at the planned deadline and one in case of anticipated payment. Both wage types shall have the same customizing in view V_T5FPR.