Exibir origem

ÍNDICE

01. VISIÓN GENERAL

El presente documento tiene como objetivo explicar el funcionamiento actual del Procedimiento de Vacaciones y los Cierres respectivos y los cambios necesarios para ajustar al regionaliza con de Argentina.

Concepto:

En Argentina existen dos modalidades de realizar el pago de vacaciones:

Dentro del Procedimiento LIQ – donde en realidad se refleja el “Plus Vacacional” que es la diferencia de abonar los días de ausencias por Licencia de Vacaciones y el valor de una ausencia común. Si bien esta metodología no esta prohibida, no se ajusta a la Legislación Vigente
Como dos procedimientos separados. Un procedimiento de calculo VAC y un procedimiento (parte del mismo) complementario de la LIQ. Esta modalidad es la que se ajusta a la Normativa Vigente y es la que proporciona Protheus como Padrón del pago de Vacaciones.

02. EJEMPLO DE UTILIZACION

Especificaciones Generales de la rutina de Vacaciones (GPEA031):

Pasos del Procedimiento VAC
Creación de un periodo de Procedimiento VAC, que estará acorde a las fechas de inicio del periodo de vacaciones a abonar.
Verificación de los días derecho que posee el empleado, de manera que se pueda verificar los días que tiene el empleado para disfrutar sus vacaciones (Rutina GPEA050): Actualizaciones->Empleados->Dia de Derecho (Tabla SRF).
El punto anterior es realizado tanto por las rutinas de Misceláneas->Cálculos->Vacaciones (GPEM031.PRW) o Vacaciones Colectivas (GPEM032.PRX).
Selección de la modalidad de Liquidación del Procedimiento de Vacaciones: Dependiendo de la rutina seleccionada, Vacaciones o Vacaciones Colectivas los pasos para completar la información requerida por el sistema son diferentes pero pueden trabajar en forma complementaria:

1. Rutina de Vacaciones: Esta opción implica crear la “Cabecera del Registro de Vacaciones” del empleado.
  En este registro como datos obligatorios tenemos:
  - - Fecha de Inicio de la Licencias
    - Días de Licencia
    - Periodo de Calculo Asociado
    - El resto es informativo.

Estos datos y la creación del periodo de vacaciones no implica que se deba hacer la liquidación del mismo para completar el proceso.

b. Rutina de Vacaciones Colectivas: Esta opción NO implica crear la “Cabecera del Registro de Vacaciones” del empleado, los datos oblogatorios a ingresar se generan como parte del proceso de calculo de las vacaciones colectivas con sus respetivos controles.

Detalle de los diferentes sub-cálculos involucrados en el Calculo del Procedimiento de Vacaciones:

El procedimiento de Calculo de Vacaciones (VAC) esta compuesto por los siguiente subprocesos:

- - - Cálculo de Aportes y Contribuciones derivados del pago de las Vacaciones.
    - Cálculo del Impuesto a las Ganancias devengadas del pago de las vacaciones.
    - Valores bases Hora/Dia según la política de la Empresa.
    - Generación del Concepto de Vacaciones.
    - Concepto 644 - Control de Vacaciones,

04. RUTINAS

Conceptos por Proceso (GPEA161)

Sugerencia de configuración de Encabezado (RGA), para complementar la funcionalidad de la rutina Generación de Periodos Estándar (GPEA490):

Procedimiento de Cálculo (RGA_CALCUL)	Descripción	Est. Periodo (RGA_PDPERI)	Toleranc. Pago (RGA_TOLEPG)	Toler. Corte (RGA_TOLECT)	Fc. Ini. Periodo (RGA_DTINIC)
VAC	Vacaciones	VAC	30	30	01/01/2022

Toleranc. Pago (RGA_TOLEPG)

Se refiere al número de días que se deben sumar o restar a la fecha final del periodo, para calcular la Fecha de Pago (RCH_DTPAGO). Este campo debe llenarse manualmente, ya que cada cliente tiene una política de pago diferente.

Ejemplo 1: Si el cliente paga los días 20, entonces la tolerancia de pago sería -10.
Ejemplo 2: Si el cliente paga los días 5, entonces la tolerancia de pago sería +5.

Toler. Corte (RGA_TOLECT)

Se refiere al número de días que se deben sumar o restar a la fecha final del periodo, para calcular la Fecha de Corte (RCH_DTCORT). Este campo es usado cuando se tienen cálculos en monedas diferente de la local, pues esta fecha es la que toma para buscar el tipo de cambio en la tabla de monedas del módulo financiero. Este campo debe llenarse manualmente, ya que cada cliente tiene una política de cálculo de nómina diferente.

Ejemplo: Si el cliente tiene como límite calcular la nómina los días 22, entonces la tolerancia de pago sería -12.

Aunque no se tengan cálculos en otras monedas, este campo es obligatorio.
Si no se pone nada, en la fecha de corte se pondrá la fecha final del periodo.
Estos dos campos se ocupan cuando se generan los periodos con la rutina de Generación Periodos Estándar.
Una vez generados los Periodos Estándar, hay que entrar a Periodos para modificar las fechas que quedaron en días no hábiles. Por ejemplo, en enero se tienen 31 días - 10 = La fecha de pago sería 21/01/2022 que es correcto. En marzo se tienen 31 días - 10 = La fecha de pago generada sería el 21/03/2022, suponiendo que el 21/03/2021 es un día festivo, se tendrá que modificar la fecha al 18/03/2022.

Fc. Ini. Periodo (RGA_DTINIC)

Se refiere a la Fecha inicial del año en curso, la cual tendrá que ser modificada cuando cambie el año de forma manual.

05. FORMULACIÓN

Cambios de Legislación o Mantenimiento realizados a la Formulación

Buenas practicas en la Formulación

Uso de operador FILTRO_ACUM

En la formulación, cuando se ocupen los operadores de lectura de acumulados (UNIDADES_EMPRESA, IMPORTE_EMPRESA, UNIDADES_TOTAL, IMPORTE_TOTAL, SUMA_UNIDADES, SUMA_IMPORTES); se recomienda que se agregue el operador FILTRO_ACUM una línea antes para asegurarse que se limpie el filtro.

06. INFORMES LEGALES

07. NOTAS IMPORTANTES

No aplica.

<!-- esconder o menu --> 


<style>
div.theme-default .ia-splitter #main {
    margin-left: 0px;
}
.ia-fixed-sidebar, .ia-splitter-left {
    display: none;
}
#main {
    padding-left: 10px;
    padding-right: 10px;
    overflow-x: hidden;
}

.aui-header-primary .aui-nav,  .aui-page-panel {
    margin-left: 0px !important;
}
.aui-header-primary .aui-nav {
    margin-left: 0px !important;
}
</style>