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.
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:
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.
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
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.
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:
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:
Si es necesario controlar estos límites, los valores posibles para configuración de un gasto son:
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.
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:
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:
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?!
Vea cuáles son estos eventos:
En la rutina de Viajes (FINA665)
En la rutina de Anticipos (FINA667)
En la rutina de Rendición de cuentas (FINA677)
Para que todo este flujo tenga la dinámica del envío de e-mails, es necesario algunos requisitos previos, tales como:
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á.
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:
Atención
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).
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.
Importante
Si la configuración "Bloquea anticipo" estuviera com "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 cual 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:
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
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:
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
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:
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.
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:
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
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 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:
*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
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:
Lo mínimo de este proceso que necesita estar configurado para el funcionamiento de la aplicación es:
Por otro lado, un proceso completo de viajes para el App abarca:
Atención
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.