Kontakt

Ansicht
Dokumentation

PAY_ES_EVHAC_T5EI5 - Set valid wage types for Internal Revenue evaluations

PAY_ES_EVHAC_T5EI5 - Set valid wage types for Internal Revenue evaluations

General Data in Customer Master   RFUMSV00 - Advance Return for Tax on Sales/Purchases  
This documentation is copyright by SAP AG.
SAP E-Book

In this IMG activity you determine the wage types that have to flow to the different payment keys and subkeys of model 190.

The view set up in this activity offers the following fields:

  • REGFI: Tax modifier
  • CPER1: Payment key
  • CPER2: Payment subkey
  • LGART: Wage Type
  • DIESP: Type of payment: monetary, deduction in kind, payment in kind.
  • ENDDA: end date of the validity
  • BEGDA: start date of the validity
  • WSIGN: Sign with which the wage type cumulates in the payment key.

The aim of this table is to identify the wage types that must be considered in the generation of the model 190 to add to the different payment keys and subkeys. Next the contents of the different fields of this table are described:

  • Tax modifier (REGFI)
    It is only necessary to have entries for the modifiers 51 (Ceuta), 52 (Melilla) y 99 (rest of the state Tax Office). It is not necessary to make entries for the regional Tax Offices unless they (or some of them) decide to adopt the new format.
  • Payment key (CPER1)
    The range of values is, in principle, from A to L. However, if some keys are not used in their system, it is not necessary to create entries with these keys.
  • Payment subkey (CPER2)
    There are certain payment keys with subkeys (eg., payment key B has subkeys 01 and 02). If a key does not have a payment subkey (eg., the key A), 00 should be shown as subkey. The subkeys that are not used in their system can also be omitted here.
  • Wage type (LGART):
    In this field it is necessary to show ALL the wage types that cumulate to the combination of payment key/payment subkey of the record in question. In general: the technical wage type devoted to collecting the payments of a specific key should be shown here:
  • /151: Money payments, key A. This assignment is only valid if the cumulator /151 does not contain monetary payments corresponding to other payment keys such as for example F. In that case, the key A should be set as described in the section ‘special cases’. As the cumulator /151 refers to monetary payments, the field ‘type of payment’ should contain a ‘D’.

  • /152: Monetary payment, key B. This assignment is only valid if the cumulator /153 does not contain monetary payments corresponding to other payment keys such as for example F. In that case, the key E should be set as described in the section ‘special cases’.

  • /153: Monetary payments, key E (board members, previous key: C). This assignment is valid only if cumulator /153 does not contain monetary payments corresponding to other payment keys such as F. In this case, set key E as described in section 'Special cases'.

  • /154: The new model 190 does not contemplate a payment key devoted to the irregular income that is cumulated in the wage type /154: It is understood that it should be added to the main key (defined in infotype 62). As in general this key can be A, B or old key C = new key E, the need is considered for a dynamic assignment to the employee’s main key. It is NOT correct to have three entries for this wage type, one with key A, another with key B and another with key E (C), as in the case of finding a wage type /154, the system would add the amount of the three keys. In this case the correct setting consists of leaving the payment key field (CPER1) EMPTY. In this way the system recognizes that it should add the amount of the wage type /154 to the main payment key set by infotype 62.

  • /155: If all the exempt payments correspond to a single payment subkey (eg. to the 01, Per diems and assignments for travel costs), the wage type /155 can be used with key L and this single subkey. Should there be exempt payments in the system with more than one subkey, it will be necessary to set the payment key L.

  • /156: Payments in kind charged to the employee: The new model 190 does not contemplate a payment key devoted to payments in kind (old key F). Their valuation and payment should be reported in the corresponding fields of the record of a specific key. For employees in somebody else’s employ the amount of the wage type /156 should be added to the valuation field of key A, in the case of pensioners or directors, to the valuation field of the keys B and C respectively. Similarly to that shown for wage type /154, this flexible assignment is achieved by leaving the key field (CPER1) EMPTY. If there are no pensioners or board members in your system with payments in kind, you can also opt to specify the value ‘A’ in the key field (CPER1) and specify an ‘R’ in the field ‘type of payment’ (DIESP) if the payment has received by the employee, or an ‘N’ if it has not.

  • /15F: Payments in kind not charged to the employee This wage type only appears in the payroll results if a distinction has really been made between payments charged and not charged. Proceed as described in the section corresponding to the wage type /156 entering an ‘N’ in the field ‘Payment type’ (DIESP).

  • /157: Monetary income of professional activities. In general, this amount should only be added to the key G, subkey 01, except in those cases in which this cumulator contains payments corresponding to another different key from G. In that case, the key G should be set as shown in the section ‘Special cases’.

  • /158: In kind income of professional activities. This wage type should only be assigned to the key G, subkey 01, payment type ‘R’ except in those cases in which this cumulator contains payments corresponding to another different key from G. In that case, the key G should be set as shown in the section ‘Special cases’. For this cumulator the cases considered in relation to the wage type /156 and the payments/deductions could arise. You should proceed similarly.

  • /15H: In kind income of professional activities. This wage type should only be assigned to the key G, subkey 01, payment type ‘N’ except in those cases in which this cumulator contains payments corresponding to another different key from G. In that case, the key G should be set as shown in the section ‘Special cases’.

  • /159: Prizes for participation in games, competitions, raffles or number combinations of chance. The setting for this wage type is unique: key = 'K', subkey = '00', payment type = 'D'.

  • /160: Prizes for participation in games, competitions, raffles or number combinations of chance. The setting for this wage type is unique: key = 'K', subkey = '00', payment rate = 'R', unless one of the cases mentioned for the wage type /156 arises, in which case you should proceed similarly.

  • /16J: Prizes for participation in games, competitions, raffles or number combinations of chance. The setting for this wage type is unique: key = 'K', subkey = '00', payment type = 'N'.

  • /161: Monetary income of agricultural and cattle-related activities. The setting of this wage type is unique, as long as there is not more than one key in the system: key = subkey = 01 or 02, depending on the subkey used in the system, payment type ‘D’. Otherwise, the payment key H should be set as described in the section ‘special cases’.

  • /162: In kind income of agricultural and cattle-related activities, payments charged. If there is not more than one subkey, this can be set in the following way: key =H, subkey 01 or 02, payment rate ‘R’. As in all payments in kind the cases mentioned for the wage type /156 can arise, you should proceed similarly.

  • /16L: In kind income of agricultural and cattle-related activities, payments charged. If there is not more than one subkey, this can be set in the following way: key =H, subkey 01 or 02, payment type ‘N’.

Special cases

Special case 1

This setting should be applied to those payment keys that cannot be derived from the cumulators /15x. The table T5EI5 allows you to create records with customer wage types, for which the corresponding deduction will be calculated respecting the carry forward principle of bases used in the payroll for the cumulators /15x.

As in the majority of cases, the exempt payments would correspond to more than one payment subkey. To be able to correctly reflect this situation in the model 190, all the customer amounts that cumulate to the /155 should be set, assigning them the corresponding payment subkey, instead of using the cumulator /155.

Special case 2

A situation could arise in which a very large group of amounts of the customer cumulate, for example, to the /151, and only a very small number of these do not correspond to the key of this cumulator (key A, money payments) but rather, for example, to the key F. In this case it would be very bothersome to enter all the wage types that cumulate to the /151 for the payment key A. To avoid this, records can be created for the (few) wage types that add to the key different to A, assigning them their key (eg, F) and letting the cumulator /151 for the payment key A Of course, this configuration would create erroneous results because the wage types corresponding to the key F, even if they would create a record in model 190 for this key, will continue adding to the key A. Therefore, it is necessary to create for each record with customer wage types noting in the key F an equivalent record that notes to key A and has the field sign (WSIGN) maintained with an ‘-‘, that is, that this wage type should SUBTRACT from the payment key A. It remains up to the customer whether or not it is worth using the special case solution 1 or that of special case 2 depending on the distribution of their wage types

There are SAP model entries. Check the SAP model entries and adapt them to your needs.

Set up the fields of this table according to the information previously specified.






BAL Application Log Documentation   ROGBILLS - Synchronize billing plans  
This documentation is copyright by SAP AG.

Length: 11947 Date: 20240607 Time: 034503     sap01-206 ( 586 ms )