Viajes - Financiero - P12

Índice

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.

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

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

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:

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.



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

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:

#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:

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:

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:

#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.

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.

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.

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.

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.

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)

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.