Linha Microsiga Protheus - Espanhol

Atalhos

Árvore de páginas

Atención

A partir del release 12.1.16.

El objetivo del proceso de viajes en el módulo Financiero del Protheus es ofrecer un control de gastos relacionados a los viajes corporativos de una empresa o entidad. Por lo tanto, efectuamos el registro de las solicitudes de viajes, las compras de servicios, concesión de anticipos, rendición de cuentas, pago de proveedores y facturación de estos viajes, cuando sea necesario.


image2018-6-20_18-20-5.png

A continuación detallamos los componentes del proceso de viajes:


Debido a la complejidad de políticas de viajes corporativos y las variaciones de reglas entre las empresas, el proceso de viajes tiene una serie de parametrizaciones. Están concentradas en el Asistente de Configuración (FINA691) y dividas en:


  • Avisos por e-mail - permite el envío de e-mail de las notificaciones de aprobación de la rendición de cuentas y del anticipo
  • Días de retroceso - permite parametrizar la fecha retroactiva para consulta de pedidos por medio de la web service (integración Protheus vs. Reserve)
  • Aprobador Estándar - aprobador utilizado en la importación de pedidos que no tienen autorizador vinculado (integración Protheus vs. Reserve)
  • Usa días hábiles o calendario - define si la actuación del parámetro "Días de Retroceso" será sobre días hábiles o días calendario
  • Grupo de Acceso Estándar - define un único grupo de acceso que se considerará en las rutinas de viajes
  • Exportación Protheus/Reserve - habilita exportación de registros del Protheus para el Reserve: 1=Sí 0=No Orden: C. Costo, Clientes, Participantes. Ej: 001 (exporta solo participantes)
  • Participante como aprobador - permite que el participante sea auto aprobador (informando su propio código en el campo Aprobador en el registro de participante)
  • Usuario del Departamento de Viajes - define a los usuarios que actuarán en el departamento de viajes, informando el código del usuario Protheus (y no el código del registro de participante)
  • ¿Valida acceso del participante? - Define si el acceso a las solicitudes de viaje se controlará por medio de la relación del aprobador/participante con la solicitud deseada.
  • Producto
  • Condición de pago
  • TES de Entrada
  • TES de Salida
  • Anticipa la facturación
  • Prefijos de los títulos por pagar y cobrar
  • Tipos de título por pagar y cobrar
  • Origen de los títulos por pagar y cobrar
  • Origen para los abonos por pagar y cobrar
  • Prefijo de los abonos
  • Días de atraso
  • Cliente y tienda estándares
  • Tipo de tasa utilizada - Cotización turismo, primer día del viaje o último día del viaje
  • Moneda para el reembolso - Fuerte u Original
  • Moneda para el anticipo - Fuerte u Original
  • Días para vencimiento de los títulos por pagar y cobrar


Importante - Tipos de títulos

Los títulos generados no podrán ser antecipos, créditos, débitos o provisionales, siendo olrigatorio que sean títulos susceptibles de operaciones de bajas.

Por este motivo los tipos de títulos RA,PA,NCC,NDF y PR no se permite que se informen en la configuración.

  • Días máximo - rendición de cuentas pendiente
  • Cantidad máxima - rendiciones de cuentas pendientes
  • Anticipo sin estadía
  • Valor fijo
  • Valor diario
  • Modalidad
  • Días para previsión
  • Previsión de anticipos urgentes
  • Tipo de viaje - Nacional, Internacional o Ambas
  • Tipo de título
  • Prefijo de anticipo solicitado con el viaje
  • Prefijo de anticipo separado
  • Fecha base del cálculo - Pedido o inicio del viaje

Pedido: Considera como base de cálculo la fecha de la solicitud del viaje hasta la fecha de finalización 
Inicio del viaje: Considera como base de cálculo la fecha inicial del viaje hasta la fecha final

  • Conversión del turismo - antes o después de generar el título
  • Bloquea anticipo - define si el anticipo se bloqueará en la solicitud de viajes o en la aprobación del anticipo, de acuerdo con la configuración de los parámetros "Días máximo" y "Cantidad máxima".


Importante - Anticipos

Si la opción "Bloquea anticipo" estuviera con "1=Sí", el sistema no permitirá la generación del anticipo, si existiera alguna rendición de cuentas pendiente para el participante en la sucursal en la cal se está incluyendo la solicitud, de acuerdo con la parametrización de las configuraciones "Días (máx.)" y "Cantidad (máx.)".

Importante - Tipos de títulos

Los títulos generados no podrán ser antecipos, créditos, débitos o provisionales, siendo obligatorio que sean títulos susceptibles de operaciones de baja.

Por este motivo los tipos de títulos RA,PA,NCC,NDF y PR no se permite que se informen en la configuración.

  • E-mails de los administradores
  • Centro de costo del prorrateo
  • Entorno de interacción con el Reserve
  • Integración con el Reserve - Desactivado, On Line, Schedule, On Line y Schedule
  • Numeración de viajes internacionales
  • Numeración de viajes sueltos
  • Configuración de aprobaciones
  • Aéreo
  • Hotel
  • Automóvil
  • Seguro
  • Carreteras
  • Otros
  • Pasajero
  • Cliente
  • Fecha - con tolerancia
  • Centro de costo
  • Prefijo
  • Tipo de título
  • Modalidad
  • Proveedor y tienda


Es importante resaltar que todas las modificaciones efectuadas en este asistente refleja directamente en los parámetros del Protheus (SX6).


Esta rutina es responsable por el mapeo de las sucursales del backoffice Protheus con el entorno Reserve, tales como usuario y contraseña de acceso para integración. Para más informaciones, vea en la página el manual de esta integración aquí.

El grupo de acceso define las jerarquías de visualización de los datos de viajes de los colaboradores.

Por ejemplo:

Tenemos los siguientes colaboradores de la Empresa A:

  • Juan - Gerente
  • Pablo - Coordinador
  • Luciana - Analista de sistemas
  • Ricardo - Analista de sistemas

Existen dos grupos posibles para configuración en este escenario:

1) Juan es el responsable del Grupo Departamento A, donde Pablo, Luciana y Ricardo son integrantes. Entonces, Juan logra visualizar sus propios viajes y los viajes que contienen por lo menos uno de los participantes de su grupo.

2) Pablo es el responsable del Grupo Departamento A.1, donde Luciana y Ricardo son integrantes. Entonces, Pablo logra visualizar sus propios viajes y los viajes que contienen por lo menos uno de los demás participantes de su grupo.

Importante

Los usuarios configurados en el parámetro de Usuario del Departamento de Viajes tienen visualización total de los datos.

Los gastos son los tipos de gastos que un colaborador puede rendir cuentas a la empresa. Se puede configurarlas a través del registro de Tipo de Gastos (FINA679).

Estas pueden o no efectuar algún control de límites para la rendición de cuentas, tales como:

  • Sin límite - Los gastos informados se considerarán reembolsables
  • Límite diario - La suma de los gastos registrados del mismo tipo y en el día, no debe superar el límite informado
  • Límite total - La suma de todos los gastos del mismo tipo registrados en la rendición de cuentas no debe superar el límite informado
  • Límite/Gasto - El gasto está limitado al límite informado

Si es necesario controlar estos límites, los valores posibles para configuración de un gasto son:

  • Valor unitario - Para cálculo automático cuando se informa la cantidad en la rendición de cuentas (ej. Km.)


Importante

Si este campo estuviera completado, no será posible modificar el valor unitario del gasto en la rendición de cuentas. 

Para que sea posible informar valores diferente en la rendición de cuentas, este campo debe permanecer con el valor cero (0) y se controlará el límite por medio de los campos Límite sin estadía y Límite con estadía.


  • Límite sin estadía - Valor límite para viajes que no exigen estadía
  • Límite con estadía - Valor límite para viajes que exigen estadía
  • Límite Moneda 2 - Valor límite para gastos efectuados en dólar
  • Límite Moneda 3 - Valor límite para gastos en euro

Los límites tienen vigencia, es decir, si es necesario cambiar la política se puede finalizar una vigencia informando la fecha final e informando los valores para un nuevo período.

Se pueden vincular los tipos de gastos a las localizaciones:

  • Nacionales
  • Internacionales
  • Ambos

Este vínculo se realiza como otra acción en la pantalla de registro del tipo de gastos.

Importante

El tipo de gasto tiene en su encabezado los datos de los entes de costo como facilitador para el registro de la línea de gastos en la rendición de cuentas.

Se puede informar el grupo de gastos, pero no es obligatorio.

El Grupo de Gastos (FINA681) tiene las mismas características del Tipo de Gasto, excepto los entes de costo, tipo de límite por gasto y valor unitario, que son específicos de la línea de gastos, y tiene como objetivo agrupar y definir límites estándar para un determinado grupo.

Atención

El valor configurado en el gasto, cuando se informa, es prioritario en el cálculo de la rendición de cuentas.

El proceso de viajes utiliza la base de participantes (APDA020) del SIGAAPD - Evaluación y Encuesta de Desempeño. Por lo tanto, en este registro existe en la solapa Viajes las informaciones necesarias para volverlo en viajero, son estas:

  • Solapa "Datos generales"
    • E-mail - utilizado para que el participante reciba e-mails de la notificación de aprobación de rendiciones de cuentas y anticipos
    • Disp Viage - Informe si un participante tiene disponibilidad para viajes. Solo se utiliza en la integración con RESERVE, para solicitud de viajes este campo fue descontinuado.
  • Solapa "Viaje"
    • Nivel de cargo - utilizado para la integración con el Reserve y que define el tipo de acceso que el participante tendrá
    • Login Reserve - acceso del participante en el Reserve
    • ID Reserve - informado después de integrar el registro con el Reserve
    • Empresa y Sucursal actual - empresa y sucursal donde el participante actúa en el momento para el control de los pedidos del Reserve
    • Empresa y Sucursal anterior - registro historial empresa y sucursal donde el participante actuó anteriormente para el control de los pedidos del Reserve
    • Permite Anticipo - informa si el participante es elegible al anticipo
    • Aprobador - ID del usuario aprobador
    • Sustituto - ID del usuario aprobador sustituto
    • Proveedor y tienda - Código del proveedor y tienda para crédito de los anticipos y reembolsos
    • Sustituto de la Rendición de cuentas - ID del usuario que puede realizar la rendición de cuentas en lugar del participante (Ej. Empleado de una Oficina de Proyectos, Secretarías o Asistentes Ejecutivas, etc).
    • ¿Permite viaje? - Indica si el participante tendrá permiso para solicitud de viajes o utilización del app Mi rendición de cuentas.

Un participante puede ser o no un empleado, y las integraciones con el módulo de Gestión de Personal para este son las que existen en el Protheus (del registro del participante, copiando a la planilla de haberes o viceversa con la configuración del .ini)


Importante

Si se utiliza el campo "¿Permite viaje? - SÍ", el código de usuario utilizado en el registro del participante no podrá repetirse en otro código de participante con el mismo permiso de viaje.

Importante

Para que el participante se considere autoaprobador, es necesario configurar el parámetro MV_RESAPRT con el valor "1" (sí) y completar el campo Aprobador en el registro de Participantes (solapa Viaje) con su propio código. Solo se puede realizar este proceso del registro en operación de Modificación.

Privilegios para el control de acceso a rutinas

Los usuarios que tienen acceso a la rutina del menú aprobación (F677APROVA), rutina: FINA677 también deben tener acceso al menú Aprobar/Reprobar (F677ARVrpv) de la rutina FINA677APR. Si el privilegio FINA677APR no se agrega al FINA677, ocurrirá un error de permiso en el momento de aprobar una rendición de cuentas.

Veamos enseguida un ejemplo de configuración:


Para más informaciones de la integración de participantes con el Reserve, consulte aquí.

A pesar de que el Reserve tiene solamente como ente de costo al Centro de Costo y el Protheus trabaja con otros entes, se pueden efectuar las clasificaciones en el Protheus a través de la rutina de viajes (FINA665). En Acciones Relacionadas, a través de la opción Modificar Ent. Costos, se puede informar también la Clase de Valor y el Ítem Contable.

El restante de las rutinas cargan estos costos del viaje o entonces, en el caso de la Rendicón de cuentas o Solicitud de viaje, tienen campos para la entrada de los entes.

Para más informaciones de la integración del Centro de Costos con el Reserve, consulte aquí.

Algunos eventos del proceso de viajes realizan el envío de e-mail estándar para notificar al participante involucrado en la acción que acabó de ejecutarse. ¡¿Muy bueno no?! (sorriso) 

Vea cuáles son estos eventos:

En la rutina de Viajes (FINA665)

  1. Al verificar la solicitud, transitando el estatus de esta p/ "Esperando aprobación" - Notifica el aprobador.

En la rutina de Anticipos (FINA667)

  1. Al generar el anticipo en estatus "Solicitado" - Notifica el aprobador.
  2. Al reprobar un anticipo en la etapa de aprobación del administrador (incluyendo la aprobación por lote) - Notifica el viajante.
  3. Al liberar el pago del anticipo generando el título financiero, por medio de la acción "Liberar Pago" - Notifica el viajante.

En la rutina de Rendición de cuentas (FINA677)

  1. Al verificar una rendición de cuentas por parte del departamento de viajes, mediante la acción "Verificar" - Notifica el aprobador.
  2. Al reprobar una rendición de cuentas en la etapa de aprobación del administrador - Notifica el viajante.
  3. Al liberar el reembolso para el viajante o la devolución p/ la empresa, generando el título financiero a través de la acción "Liberar Financ." - Notifica el viajante.

Para que todo este flujo tenga la dinámica del envío de e-mails, es necesario algunos requisitos previos, tales como:

  • Configurar servidor de e-mail del Protheus.
  • Tener el campo "E-mail" informado en el registro del participante con una dirección válida.
  • Tener el parámetro MV_RESAVIS (presente en el Asistente de Configuración, sección "Generales") configurado como "1".
  • Permitir que el servicio de e-mail (Google, Office365, etc.) se acceda por medio del Protheus. Esta acción solo es necesaria si usted recibe un aviso de alerta Google/Microsoft sobre el bloqueo al intento de conexión de un dispositivo desconocido.

Ejemplo de un e-mail que se ejecutó para el administrador aprobador en el momento en que el departamento de viajes verificó la rendición de cuentas (acción "Verificar->Aprobar"):

Importante

Si se utiliza el workflow con el Fluig, para cada proceso configurado (SOLVIAJ1 - Solicitud de viaje, SOLADIANTA - Anticipo, APVPRESTCO - Rendición de cuentas), el envío de e-mail en estos eventos se desconsiderará.

01. VISIÓN GENERAL

Un empleado (en este escenario, lo llamamos Participante) necesita realizar un viaje corporativo, por algún motivo, sea este cual fuera (ej: atención/visita al cliente, reunión de negocios, evento). Entonces esta rutina tendrá como principal objetivo registrar la solicitud de este viaje, considerando informaciones relevantes para controlar los gastos del viaje y sus políticas.

Importante

Esta rutina considera solamente solicitudes del Protheus. Los viajes integrados con el Reserve no generan solicitud, porque se compran y emiten directamente en la agencia.

Atención

En los ítems del viaje se podrán seleccionar y justificar/detallar los siguientes servicios:

  • Vuelo
  • Hotel
  • Automóvil
  • Por carretera
  • Seguros
  • Otros


Atención

  • Estos ítems de servicio son parametrizables y están en el asistente de configuración Si la empresa no ofrece alguno de estos ítems en su política, se puede ocultarlos.
  • El ítem Otros es el único en que no es necesario comprar servicio, entonces solicitudes solo con este servicio no pasan por la etapa de verificación de la solicitud. Esta es necesaria cuando un colaborador desea solicitar solamente un anticipo, porque hará, por ejemplo, una visita a un cliente con vehículo propio y desea solamente el anticipo.

Cuando se parametrizan para aprobación después de solicitarlas, se generará un asunto pendiente de aprobación para el superior de los participantes. En caso contrario, esta se puede enviar al departamento de viajes (directamente después de la solicitud o en un segundo momento a través de la opción de envío) y el viaje se generará automáticamente.

Ejemplo:

La empresa puede decidir por pasar por todas las aprobaciones, en este caso el flujo será:

O entonces puede ser que tan solo una de las aprobaciones sea necesaria, en este caso tenemos:


Importante

Cuando no exista la etapa de aprobación de viajes, para que la solicitud de viajes (FW3), se vuelva un viaje (FL5) y logre dar continuidad al flujo, la solicitud pasará obligatoriamente por la verificación del departamento de viajes, en la rutina de solicitud de viajes (FINA666) vaya a OTRAS ACCIONES → Enc. p/ Depart Viajes (Generando el viaje en la rutina FINA665).



02. EJEMPLO DE UTILIZACIÓN

Acceso a la rutina por el camino: Actualizaciones > Viajes > Solicitud de viaje

El viajero debe informar los datos básicos del viaje en el encabezado de su solicitud, como origen y destino, fechas de partida y llegada, cliente para atención (si hubiera), etc.
Para cada servicio se deben informar lo(s) Participante(s) y su(s) respectivo(s) Ente(s) de costo.



Importante

No se permite incluir el mismo centro de costo en el prorrateo de centro de costos.

Si la clave única fuera: Sucursal + Núm. Solicitud + Ítem + C.Costo ( FW6_FILIAL+FW6_SOLICI+FW6_ITEM+FW6_CC), no se permitirá utilizar el mismo centro de costo, aunque los otros entes contables sean diferentes. 

En la release 12.1.2410, con aplicación del paquete acumulado con fecha igual o superior al 08/11/2024, el sistema pasa a considerar la modificación de la clave única y del índice 1 de la tabla FW6 para: FW6_FILIAL+FW6_SOLICI+FW6_ITEM+FW6_CC+FW6_ITECTA+FW6_CLVL.

De esta manera, si la clave única es:  Sucursal + Núm. Solicitud + Ítem + C.Costo  + Ítem contable + Clase de valor (FW6_FILIAL+FW6_SOLICI+FW6_ITEM+FW6_CC+FW6_ITECTA+FW6_CLVL), no se permitirá utilizar la misma combinación de entes contables ( C. Costo, Ítem contable y Clase de valor).                 

Si se modifica la clave única de la tabla FW6, es necesario realizar también la adecuación  de la clave única y del índice 1 de la tabla FLH  a: 

FLH_FILIAL+FLH_VIAGEM+FLH_ITEM+FLH_CC+FLH_ITECTA+FLH_CLVL 

Las adecuaciones de las tablas FW6 y FLH están disponibles a partir del paquete acumulado con fecha igual o superior al 08/11/2024 exclusivamente para la release 12.1.2410.                                                                                       


Además, en la solapa Anticipos se pueden marcar los participantes que recibirán el anticipo.

Importante

Si la opción "Bloquea anticipo" estuviera com "1=Sí", el sistema no permitirá generar el anticipo, si existiera alguna rendición de cuentas pendiente para el participante en la sucursal donde se está incluyendo la solicitud, de acuerdo con la parametrización de las configuraciones "Días (máx.)" y "Cantidad (máx.)".


El valor calculado es una previsión y se muestra solamente si estuviera parametrizado:

03. RUTINA AUTOMÁTICA

Para ejecutar la rutina automática, ilustramos algunas funcionalidades como Inclusión (MyFA666Inc), Modificación (MyFA666Alt) y Borrado (MyFA666Del), en los siguientes ejemplos:

Ejemplo de ejecución de la rutina automática 
#INCLUDE "PROTHEUS.CH"
#INCLUDE "FWMVCDEF.CH"

//---------- Inclusión de la solicitud de viaje ----------//
User Function MyFA666Inc()

Local oModel := Nil
Local oModelFW3 := Nil
Local oModelFW4 := Nil
Local oModelFW5 := Nil
Local oModelFW6 := Nil
Local cFilAtu := ""

RpcSetEnv("T1","D MG 01 ","claudio.ribeiro","1") // Inicializa entorno con usuario solicitante

oModel := FWLoadModel("FINA666")
oModelFW3 := oModel:GetModel("FW3MASTER") // Encabezado del viaje
oModelFW4 := oModel:GetModel("FW4DETAIL") // Servicios 
oModelFW5 := oModel:GetModel("FW5DETAIL") // Participantes
oModelFW6 := oModel:GetModel("FW6DETAIL") // Centro de costo
cFilAtu := xFilial("FW3")

oModel:SetOperation(MODEL_OPERATION_INSERT)
oModel:Activate()
// Informa el encabezado de la solicitud de viaje
oModelFW3:SetValue("FW3_FILIAL",cFilAtu)
oModelFW3:SetValue("FW3_NACION","1")
oModelFW3:SetValue("FW3_CODORI","SP")
oModelFW3:SetValue("FW3_CODDES","RJ")
oModelFW3:SetValue("FW3_DTINI",StoD("20190702"))
oModelFW3:SetValue("FW3_DTFIM",StoD("20190705"))
oModelFW3:SetValue("FW3_CLIENT","001 ")
oModelFW3:SetValue("FW3_LOJA","01")
oModelFW3:SetValue("FW3_STATUS","0") // Pendiente, Estatus inicial
// Informa la cuadrícula del servicio incluso en la solicitud del viaje
oModelFW4:SetValue("FW4_ITEM",StrZero(1,TamSX3("FW4_ITEM")[1]))
oModelFW4:SetValue("FW4_TIPO","1") // Aéreo
oModelFW4:SetValue("FW4_OBS", "Visita al cliente")
// Informa la cuadrícula de los participantes viajeros
oModelFW5:SetValue("FW5_ITEM",StrZero(1,TamSX3("FW4_ITEM")[1]))
oModelFW5:SetValue("FW5_PARTIC","000001")
oModelFW5:SetValue("FW5_ADIANT",.T.) // Agrega anticipo al participante
oModelFW5:AddLine() // Agrega línea para un segundo viajero
oModelFW5:SetValue("FW5_ITEM",StrZero(2,TamSX3("FW4_ITEM")[1]))
oModelFW5:SetValue("FW5_PARTIC","000002")
oModelFW5:SetValue("FW5_ADIANT",.T.) // Agrega anticipo al participante
// Informa la cuadrícula del centro de costo
oModelFW6:SetValue("FW6_ITEM",StrZero(1,TamSX3("FW4_ITEM")[1]))
oModelFW6:SetValue("FW6_CC","002 ")
oModelFW6:SetValue("FW6_PORCEN",100)
oModelFW5:GoLine(1)
// Validación y grabación de los datos si fueran consistentes
If oModel:VldData() 
     oModel:CommitData()
     Conout("Inclusión de la solicitud del viaje finalizada con éxito.")
Else 
     VarInfo("",oModel:GetErrorMessage())
     Conout("Error en la validación, solicitud de viaje no se incluyó.")
EndIf

oModel:DeActivate()
oModel:Destroy()
RpcClearEnv()

Return


//---------- Modificación de la solicitud de viaje ----------//
User Function MyFA666Alt()

Local aKeyFW4 := {}
Local oModel := Nil
Local oModelFW5 := Nil
Local oModelFW6 := Nil
Local cSolic := "0000000010"

RpcSetEnv("T1","D MG 01 ","richard.santos","1") // Inicializa entorno con usuario solicitante

dbSelectArea("FW3")
dbSetOrder(1)
dbSeek(xFilial("FW3")+cSolic)
// Carga modelo de datos con la solicitud de viaje marcada
oModel := FWLoadModel("FINA666")
oModelFW5 := oModel:GetModel("FW5DETAIL") // Participantes
oModelFW6 := oModel:GetModel("FW6DETAIL") // Centro de costo
// Clave de búsqueda del participante dentro de la Sol. de Viaje
aKeyFW4 := { {"FW5_FILIAL",xFilial("FW5")},{"FW5_SOLICI",cSolic},{"FW5_ITEM","01"},{"FW5_PARTIC","000002"} }

oModel:SetOperation(MODEL_OPERATION_UPDATE)
oModel:Activate()
// Retira uno de los viajeros, en este caso el participante 000002
If oModelFW5:SeekLine(aKeyFLE)
     oModelFW5:DeleteLine()
Else
     Conout("Viajero no encontrado en esta solicitud de viaje.")
EndIf
// Modifica el centro de costo (marcado automáticamente en la primera cuadrícula)
oModelFW6:SetValue("FW6_CC","003 ")

// Validación y grabación de los datos si fueran consistentes
If oModel:VldData() 
     oModel:CommitData()
     Conout("Modificación de la solicitud de viaje efectuada con éxito.")
Else 
     VarInfo("",oModel:GetErrorMessage())
     Conout("Error en la validación, solicitud de viaje no se modificó.")
EndIf

oModel:DeActivate()
oModel:Destroy()
RpcClearEnv()

Return


//---------- Borrado de la solicitud de viaje ----------//
User Function MyFA666Del()

Local oModel := Nil
Local cSolic := "0000000010"

RpcSetEnv("T1","D MG 01 ","claudio.ribeiro","1") // Inicializa entorno con usuario solicitante

dbSelectArea("FW3")
dbSetOrder(1)
dbSeek(xFilial("FW3")+cSolic)
// Carga modelo de datos con la solicitud de viaje marcada
oModel:= FWLoadModel("FINA666")
oModel:SetOperation(MODEL_OPERATION_DELETE)
oModel:Activate()

// Validación y grabación del borrado
If oModel:VldData() 
     oModel:CommitData()
     Conout("Solicitud de viaje borrada con éxito.")
Else 
     VarInfo("",oModel:GetErrorMessage())
     Conout("Error en la validación, solicitud de viaje no se borró.")
EndIf

oModel:DeActivate()
oModel:Destroy()
RpcClearEnv()

Return


04. TABLAS UTILIZADAS

  • FW3 - Encabezado de la solicitud
  • FW4 - Servicios (ítems)
  • FW5 - Participantes
  • FW6 - Entes de costos


La rutina de viajes (FINA665) tiene todas las informaciones relacionadas a los viajes ya emitidas mediante la agencia o solicitud de viaje separada.

Un viaje está compuesto por:

Encabezado del viaje, que tiene los datos de la fecha de inicio y fin, origen y destino, cliente que se atenderá (cuando sea aplicable) etc.

En la solapa anticipos, se listan los participantes y los anticipos solicitados para cada uno de estos.

En la solapa del viaje propiamente dicho, tenemos la lista de todos los pedidos efectuados.

Al seleccionar un ítem del pedido de viaje, se habilita un contexto por servicio con los datos específicos de cada uno de estos, como por ejemplo: Para vuelo tenemos la Cia. Aérea, Localizador, Clase etc. En el caso de un hotel tenemos el Nombre del Hotel, fechas de check-in y check-out etc. Los servicios posibles son:

  • Vuelo
  • Hotel
  • Automóvil
  • Carretera
  • Seguros
  • Otros

También se muestran a los participantes y a los entes de costo vinculados.

Un viaje realizado en el Reserve, se integra solamente cuando está emitido, es decir, no se pueden modificar sus servicios en el Protheus (fechas, valores, etc). Los únicos datos pasibles de edición son los entes de costo. Para más detalles, consulte el manual de la integración TOTVS vs. Reserve.

Por otro lado, un viaje generado de una solicitud de viajes del Protheus, debe tener sus detalles de servicios informados por el departamento de viajes a través de la opción de Verificación, puesto que la solicitud es un pedido para la compra del viaje. Si la aprobación está habilitada después de verificar, se generará un asunto pendiente de aprobación para el superior de los participantes.

Un viaje con todos sus servicios y gastos debidamente pagados y cuentas prestadas, es elegible para facturación. Este proceso muestra los costos del viaje que se pueden repasar al cliente, integral o parcialmente, y genera un pedido de venta para el cliente. Si no resulta aplicable para el segmento de la empresa, este paso no es obligatorio.



ÍNDICE



01. VISIÓN GENERAL

Los anticipos (FINA667) son los valores acreditados a los colaboradores para cubrir los gastos de un viaje, tales como alimentación, transporte, comunicación, etc.

Estos valores se calculan por medio de la configuración de la política de viajes de la empresa, que pueden ser:

  1. Valor fijo: Este es el valor fijo concedido, usualmente para el valor de traslado.
  2. Valor con y sin Pernoctar: Si el viaje tiene período dentro del mismo día, se calcula el valor del anticipo sin pernoctar, si supera un valor diario, se calculará con el valor con pernoctar.
  3. Otras monedas: Los valores en otras monedas usualmente son concedidos mediante crédito en traveller check o compra de moneda. En este caso el Protheus no hace el cálculo, pero se debe informar el valor del crédito de este anticipo. Las tasas de conversión de la compra de esta moneda para la moneda fuerte, se pueden informar antes o después de generar el título mediante la configuración en el asistente de Configuración.

En la rutina de viajes (FINA665) aun se puede solicitar complementos de anticipos. Si un colaborador necesita más dinero en un viaje, esta solicitud se puede efectuar seleccionando el viaje y la opción Anticipo por Separado. En este caso se genera otro anticipo más vinculado al viaje.

Las reglas de generación de título, tales como Prefijo, Modalidad, Fecha de Vencimiento para anticipos normales y urgentes (aquellos solicitados fuera de la regla de la política de anticipación) están en el Asistente de Configuración.

Los anticipos solicitados, tanto vía Reserve, solicitud de viajes o por separado, no se aprueban junto con el viaje y generan un asunto pendiente para el superior del viajero, si se configura.

Ejemplo:

Si es necesario la aprobación del superior y evaluación financiera, tenemos:

O entonces tendremos los siguientes escenarios si una etapa se pudiera realizar automáticamente:

Sugerencia

La contabilización del anticipo se realiza por medio del registro estándar de inclusión de título.

Para los casos en que el anticipo es otra moneda y la tasa informada después de generar el título, este se debe contabilizar Off Line.

Atención

Este proceso no es obligatorio.


02. EJEMPLO DE UTILIZACIÓN

El anticipo se puede generar a partir de la solicitud de viaje (FINA666), seleccionando esta opción en la solapa Anticipos:

image2019-7-8_15-12-37.png

O después de haber enviado el viaje al departamento de viajes (FINA665), haciendo clic en el botón "Solic. Antic." y seleccionando los participantes que recibirán el anticipo:



Entonces, por medio de la rutina FINA667, el anticipo se puede visualizar y seguir su flujo de acciones:

03. RUTINA AUTOMÁTICA

Para ejecutar la rutina automática, ilustramos la solicitud del anticipo tras hacer efectivo el viaje (MyFA667A), en el siguiente ejemplo:

Exemplo de execução da rotina automática 
#INCLUDE "PROTHEUS.CH"
#INCLUDE "FWMVCDEF.CH"

//---------- Solicitud de anticipo del viaje ----------//
User Function MyFA667A()

Local aKeyFLC := {}
Local aUser := {}
Local oModel := Nil
Local oModelFLC := Nil
Local oModelFLD := Nil
Local cViagem := "0000000001"
Local cPartic := "000002"

RpcSetEnv("T1","D MG 01 ","claudio.ribeiro","1") // Inicializa entorno con usuario solicitante

dbSelectArea("FL5")
dbSetOrder(1)
dbSeek(xFilial("FL5")+cViagem) // Viaje ya solicitado

// Carga modelo de datos con la solicitud de viaje marcada
oModel := FWLoadModel("FINA667A")
oModelFLC := oModel:GetModel("FLCDETAIL") // Participantes
oModelFLD := oModel:GetModel("FLDDETAIL") // Anticipos
// Clave de búsqueda del participante dentro del viaje
aKeyFLC := { {"FLC_FILIAL",xFilial("FLC")},{"FLC_VIAGEM",cViagem},{"FLC_PARTIC",cPartic} }

oModel:SetOperation(MODEL_OPERATION_UPDATE)
oModel:Activate()
If FINXUser(RetCodUsr(),aUser,.T.)
     // Participante que recibirá anticipo
     If oModelFLC:SeekLine(aKeyFLC)
          oModelFLC:SetValue("OK",.T.)
          oModelFLD:LoadValue("FLD_DTSOLI",dDatabase)
          oModelFLD:LoadValue("FLD_DTPREV",DataValida(dDatabase+3))
          oModelFLD:LoadValue("FLD_SOLIC" ,aUser[1])
          oModelFLD:LoadValue("FLD_NOMESO",PadR(aUser[2],TamSx3("FLD_NOMESO")[1]))
          oModelFLD:SetValue("FLD_VALOR",400)
          oModelFLD:SetValue("FLD_MOEDA","1")
          oModelFLD:SetValue("FLD_JUSTIF","Anticipo para el viajero")
          // Validación y grabación de los datos si fueran consistentes
          If oModel:VldData()
               oModel:CommitData()
               Conout("Anticipo solicitado con éxito.")
          Else 
               VarInfo("",oModel:GetErrorMessage())
               Conout("Error en la validación, anticipo no fue solicitado.")
         EndIf
     Else
          Conout("Viajero no encontrado en este viaje.")
     EndIf
EndIf

oModel:DeActivate()
oModel:Destroy()
RpcClearEnv()

Return


04. TABLAS

  • FL5 - Viaje
  • FLC - Pasajeros
  • FLD - Anticipos




Con un viaje en marcha o después de su finalización, el viajero debe efectuar su rendición de cuentas de los gastos para la empresa.

Todo viaje, independientement de tener o no un anticipo, genera automáticamente un registro en la rutina Rendición de cuentas (FINA677) vinculada a esta.

Una rendición de cuentas tiene los datos básicos de un viaje, como su número, fecha inicial y final, local, cliente que se atendió (si fuera aplicable), además de los entes de costo y porcentaje de facturación contra el cliente (si el cliente fuera aplicable), etc.

El colaborador podrá informar ítem por ítem, los gastos que tuvo en su viaje informando: gasto, local, valor (en la moneda actual o en otra y su tasa de conversión), cantidad, entes de costo, etc.

Además, los anticipos se listan en la rendición de cuentas y se descuenta del valor total al pie de la rendición de cuentas.

Los valores utilizados, los reembolsables y el saldo también se muestran al pie del documento, en las 3 monedas tratadas por el Protheus: actual, dólar y euro.

Atención

  • Una rendición de cuentas solo se puede finalizar siempre y cuando todos los anticipos vinculados al viaje, si existen, están pagados, es decir, acreditados al colaborador. Esto previene que sea acreditado un valor de reembolso indebido al colaborador.
  • Todas las demás monedas se convierten a dólar, una vez que la operación más común es la de concesión de traveller checks en dólar a débito, crédito o retirada en la moneda actual de otros países. Por ejemplo: En un gasto realizado en Rupias, la tasa informada dela transacción del Traveller Check debe ser la referencia de conversión en dólar.
  • Título oriundo de la rendición de cuentas: FINA667 o FINA677 no puede negociarse.

Una vez finalizada y enviada al departamento de viajes (después de incluirla o en momento posterior por la opción de envío para verificación), el departamento de viajes hará la verificación de la rendición de cuentas. A pesar que el sistema ya efectúa los cálculos de los valores reembolsables de los gastos por medio de la regla de límites de los gastos, si el verificador identifica algún ítem en los comprobantes que están fuera de la política de viajes, este puede registrar los descuentos en este momento y el valor que se devolverá/reembolsará se actualiza.

Si los pasos de aprobación y/o liberación para el financiero están activos, se generarán asuntos pendientes para el superior del viajante y para el financiero/departamento de viajes, respectivamente.

Importante

El proceso de aprobación de las rendiciones de cuentas por el Administrador inmediato, solo podrá realizarse mediante la selección del filtro "En Evaluación del administrador" en el acceso a la rutina FINA677(Rendición de cuentas). Si el filtro se desmarca. se mostrará el help indicando que el proceso de aprobación solo podrá realizarse mediante el registro del ítem en el acceso a la rutina.

Ejemplo:

Si todo el proceso debe pasar por aprobación o verificación, tenemos:

Si alguna etapa se pudiera realizar automáticamente, tenemos:


Finalmente, además de los viajes, la rutina también permite efectuar rendiciones de cuentas separadas.


En la inclusión de una Prestación de cuentas por separado, existe la opción "Modif. Viajante", donde es posible modificar el participante de la Rendición de cuentas.

Por ejemplo: 

Dos empleados de una empresa deben realizar una visita a un determinado cliente y uno de estos incluirá la rendición de cuentas al otro empleado. 

Empleado João : es quien incluirá la rendición de cuentas para María. Será el Sustituto de María.

Empleada María:  es quien tendrá la rendición de cuentas incluida por João. En su registro de participante (APDA020), debe haber configurado el usuario João como su Sustituto (RD0_USRPRE). 

En este caso, el usuario João debe acceder al sistema y en la inclusión de la Rendición de cuentas por separado, debe efectuar la modificación del Viajante, informando la Participante: Maria. 

De esta manera, el participante de la Rendición de cuentas será la usuaria Maria (FLF_PRESTA).  

Sugerencia

La contabilidad de la rendición de cuentas tiene registros específicos para contabilizar los gastos, son estos:

  • 8B3 - Ítem de la rendición de Cuentas/Gasto
  • 8B4 - Reversión del ítem de la rendición de Cuentas/Gasto
  • 8B5 - Encabezado de la Rendición de cuentas*
  • 8B6 - Reversión del encabezado de la Rendición de cuentas*

*Los totalizadores de la rendición de cuentas se graban en la tabla FLF - Encabezado de la rendición de cuentas

Para la contabilidad off-line de la rendición de cuentas: LP 8B3 y 8B5 - Contabilidad de la rendición de cuentas off-line




La verificación de servicios es simplemente la copia de la factura de una agencia de viajes o de los propios proveedores directos (compañías aéreas, hoteles, alquiladoras de automóviles, etc.).

En esta rutina se pueden seleccionar los ítems de viajes, sea por servicio o considerando todos los tipos, para selección y edición del pago enviado en la factura. Con los pedidos debidamente seleccionados y los valores editados cuando sea necesario, se generará un pedido de compra, una factura o un título por pagar.

Importante

  • Cuando un viaje se remarca, el pedido solo se anula dentro del viaje, ya que en muchos servicios incurren tasas/costos de anulación o remarcación. Por este motivo, tanto lo remarcado como lo activo aparecerán en el pago.
  • Al seleccionar un pedido para verificación, se sugiere el valor del servicio registrado en el viaje, pero es posible editarlo como mayor o menor, considerando que esta última opción también permite finalizar el pago del ítem o mantener el saldo para verificaciones parciales.
  • Los porcentajes de los entes de costo del viaje, se hacen proporcionales y se cargan para el registro generado de la verificación

Sugerencia

La contabilidad del anticipo se realiza por medio del asiento estándar de inclusión de título.

Cuando existe un acuerdo entre proveedor y cliente referente al pago de gastos de los viajes, el Protheus permite facturar tanto el viaje completo como una rendición de cuentas separada.

La facturación de un viaje incluye los costos de los servicios contratados (vuelo, hotel, alquiler de automóviles, seguros y carretera) y los gastos de los colaboradores involucrados. Cuando todos los servicios estén pagados y la rendición de cuentas finalizada y aprobada, el viaje estará apto para facturar contra el cliente, sea parcial o totalmente. Aun así, se pueden parametrizar las reglas de viajes y permitir la facturación anticipada de un viaje, siempre y cuando por lo menos la rendición de cuentas esté finalizada, considerando que este es un costo variable, diferente de los servicios que tienen una previsión en su contratación.

Por otro lado, las rendiciones de cuentas separadas, se pueden facturar después de que se finalicen.

Atención

Este proceso no es obligatorio.

Para más informaciones acceda a los manuales de integración TOTVS vs. Reserve y PCO vs. Reserve.

El App Mi Rendición de cuentas permite un control fácil y rápido para que viajantes corporativos mantengan su rendición de cuentas actualizada durante un viaje.

Con esta aplicación se puede:

  • Sincronizar las rendiciones de cuentas de viajes.
  • Incluir una rendición de cuentas separada
  • Administrar/Controlar gastos
  • Hacer un seguimiento del saldo de la rendición de cuentas.
  • Enviar una rendición de cuentas para verificación y aprobación.
  • Hacer un seguimiento de las rendiciones de cuentas ya finalizadas.
  • Corregir las rendiciones de cuentas rechazadas.

Lo mínimo de este proceso que necesita estar configurado para el funcionamiento de la aplicación es:

  • Registros
    • Gastos (con o sin vínculo por localidad y grupo)
    • Grupo de acceso
    • Participantes
  • Rendición de cuentas (separada)

Por otro lado, un proceso completo de viajes para el App abarca:

  • Registros
    • Wizard de configuración
    • Participante
    • Grupo de acceso
    • Gasto
    • Grupo de gasto
  • Solicitud de viaje (Por integración Reserve o Protheus)
  • Viaje
  • Anticipo
  • Rendición de cuentas (objetivo del app)



Atención

  • Esta aplicación es complementaria al proceso de control de viajes del Financiero Protheus.
  • Es necesario tener un usuario y contraseña del Protheus (a partir de la versión 12.1.17 expedición Janeiro/18) para utilizarlo.
  • No es obligatorio el uso de la integración TOTVS Reserve, porque se puede efectuar la solicitud del viaje suelto del Protheus.

Para más informaciones acceda al TOTVS Mi Rendición de cuentas en el área del Aplicaciones.

Para descargar (download) del App acceda al Google Play.