El objetivo sería que el responsable del cálculo de planilla pueda “fijar” las transacciones que participan en el cálculo y no le "aparezcan" nuevas transacciones durante el proceso de cálculo que le hagan complicado el cuadre de planilla.

asked 29 Oct '13, 18:14

Fernando%20Paz's gravatar image

Fernando Paz ♦♦
17.3k81635
accept rate: 51%


Evolution implementa una serie de columnas en las entidades que afectan directamente al pago de planilla que le permiten clasificar las transacciones, estas columnas son:

  • xxx__codppl Código de Período de Planilla al que está asociado este registro
  • xxxaplicadoplanilla Verdadero cuando el registro fue aplicado en el último cálculo de planilla ejecutado. Entidades no aplicadas se entienden como aquellas que no afectaron el salario neto a pagar del empleado.
  • xxxplanillaautorizada Verdadero cuando el registro pertenece a una planilla que ya fue autorizada. Cuando esta bandera y la anterior tienen valor verdadero, se considera que esta acción tuvo aplicación en el período de planilla.
  • xxxignoraren__planilla Permite marcar un registro de tal manera que los cursores de la formulación puedan ignorarlo para el cálculo de la planilla. Además, existe una pantalla en Evolution, que permite al responsable de planilla cambiar esta bandera para las transacciones autorizadas asociadas a períodos de planilla.

Todas las transacciones que poseen estas columnas dan el control al implantador sobre cómo procesar las autorizaciones en un periodo de planilla en particular. O sobre qué hacer con transacciones que fueron autorizadas pero nunca fueron aplicadas en planilla.

Entonces aunque en la versión actual de Evolution (1.7.3.1) el código fuente no tiene nada codificado que permita excluir las transacciones autorizadas con fecha posterior a la fecha de corte del período de planilla, es posible ajustar la columna xxx_ignorar_en_planilla, para que tenga verdadero cuando se da la situación anterior en un trigger a nivel de base de datos.

Por ejemplo, si quisiéramos implementar la regla de negocio para las Horas Extras. Deberíamos agregar un Trigger a la tabla con el siguiente código:

CREATE TRIGGER sal.ext_ignorar_en_planilla_fecha_corte 
   ON  sal.sal.ext_horas_extras 
   AFTER INSERT, UPDATE
AS 
BEGIN
    SET NOCOUNT ON;

    -- Se ejecuta solamente si se modificó la columna ext_estado
    if UPDATE(ext_estado) begin
        update sal.ext_horas_extras set ext_ignorar_en_planilla = 1
          from sal.ext_horas_extras e
          join inserted i on i.ext_codigo = e.ext_codigo
          join sal.ppl_periodos_planilla on ppl_codigo = i.ext_codppl
         where i.ext_estado != e.ext_estado
           and i.ext_estado = 'Autorizado'
           and i.ext_estado_workflow = 'Autorizado'
           and i.ext_fecha_cambio_estado > ppl_fecha_corte
    end
END
GO

Este Trigger se asegurará de poner 1 en la columna [ext_ignorar_en_planilla], cuando la fecha de cambio de estado de la hora extra [ext_fecha_cambio_estado] sea mayor que la fecha de corte del período de planilla [ppl_fecha_corte].

Ahora es posible separar aquellos registros que fueron autorizados en fecha posterior a la fecha de corte del período de planilla.

Luego lo que sigue es asegurarse que los cursores de formulación de planilla NO tomen registros que tienen 1 en la columna ignorar_en_planilla.

Por ejemplo, la instrucción select para el cursor de formulación que toma los registros de horas extras debería ser algo similar a esto:

select *
  from sal.ext_horas_extras
 where ext_codppl = $$CODPPL$$
   and ext_estado = 'Autorizado'
   and ext_ignorar_en_planilla = 0
   and sal.empleado_en_gen_planilla('$$SESSIONID$$', ext_codemp) = 1

Esto se debe modificar utilizando la herramienta de configuración de la formulación de planilla (FormulaEditor.Exe) instalado junto con el resto de herramientas de Evolution.

Conclusión

Con estas pequeñas modificaciones se puede impedir que los registros que se autoricen posteriormente a la fecha de corte del período de planilla asociado, sean incluidos cuando se calcula la planilla, de tal manera que el usuario pueda “fijar” las transacciones que va a incluir, sin impedir que el proceso de autorización continúe.

Evolution a través de la pantalla de “Transacciones que Aplican en Planilla” del módulo de “Administración de Salarios”, le da el control al usuario para que incluya o ignore registros autorizados fuera del plazo aceptado de cualquiera de las transacciones que tiene ese atributo.

link
This answer is marked "community wiki".

answered 29 Oct '13, 18:26

Fernando%20Paz's gravatar image

Fernando Paz ♦♦
17.3k81635
accept rate: 51%

wikified 29 Oct '13, 18:55

Este trigger se tendría que construir para cada entidad que posea dichos campos?

(06 Nov '13, 17:27) JulioRosales JulioRosales's gravatar image
Your answer
toggle preview

Follow this question

By Email:

Once you sign in you will be able to subscribe for any updates here

By RSS:

Answers

Answers and Comments

Markdown Basics

  • *italic* or _italic_
  • **bold** or __bold__
  • link:[text](http://url.com/ "title")
  • image?![alt text](/path/img.jpg "title")
  • numbered list: 1. Foo 2. Bar
  • to add a line break simply add two spaces to where you would like the new line to be.
  • basic HTML tags are also supported

Evolution en BitBucket

En este sitio puede acceder al código fuente, centro de descargas y reportar bugs, propuestas y mejoras para Evolution.

Evolution en JIRA

En este sitio puedes sugerir nueva funcionalidad para Evolution, o puedes votar por la funcionalidad ya propuesta por otros usuarios.

Tags:

×92
×47

Asked: 29 Oct '13, 18:14

Seen: 2,351 times

Last updated: 06 Nov '13, 17:27

[Acerca de] [Preguntas Frecuentes] [Privacidad] [Soporte] [Contacto]
Copyright 2013-2018. Asesores en Informática