Árvore de páginas

Atenção

A partir do release 12.1.16.

O objetivo do processo de viagens no módulo Financeiro do Protheus é oferecer um controle de gastos relacionados às viagens corporativas de uma empresa ou entidade. Para tanto, efetuamos o registro das solicitações de viagens, as compras de serviços, concessão de adiantamentos, prestação de contas, pagamento de fornecedores e faturamento destas viagens, quando necessário.

Abaixo detalhamos os componentes do processo de viagens:


Por conta da complexidade de políticas de viagens corporativas e as variações de regras entre as empresas, o processo de viagens possui uma série de parametrizações. Estas estão concentradas no Assistente de Configuração (FINA691) e dividas em:


  • Avisos por e-mail - permite o envio de e-mail das notificações de aprovação da prestação de contas e do adiantamento
  • Dias de Retrocedência - permite a parametrização da data retroativa para consulta de pedidos via web service (integração Protheus x Reserve)
  • Aprovador Padrão - aprovador utilizado na importação de pedidos que não possuem autorizador vinculado (integração Protheus x Reserve)
  • Usa dias úteis ou corridos - define se a atuação do parâmetro "Dias de Retrocedência" será sobre dias úteis ou dias corridos
  • Grupo de Acesso Padrão - define um único grupo de acesso a ser considerado nas rotinas de viagens
  • Exportação Protheus/Reserve - habilita exportação de cadastros do Protheus para o Reserve: 1=Sim, 0=Não. Ordem: C. Custo, Clientes, Participantes. Ex: 001 (exporta apenas participantes)
  • Participante como aprovador - permite que o participante seja autoaprovador (informando o seu próprio código no campo Aprovador no cadastro de participante)
  • Usuário do Departamento de Viagens - define os usuários que atuarão no departamento de viagens, informando o código do usuário Protheus (e não o código do cadastro de participante)
  • Produto
  • Condição de Pagamento
  • TES de Entrada
  • TES de Saída
  • Antecipa o Faturamento
  • Prefixos dos títulos a pagar e receber
  • Tipos de título a pagar e receber
  • Naturezas dos títulos a pagar e receber
  • Natureza para os abonos a pagar e receber
  • Prefixo dos abonos
  • Dias de atraso
  • Cliente e loja padrões
  • Tipo de taxa utilizada - Cotação turismo, primeiro dia da viagem ou último dia da viagem
  • Moeda para o reembolso - Forte ou Original
  • Moeda para o adiantamento - Forte ou Original
  • Dias para vencimento dos títulos a pagar e receber


Importante - Tipos de Títulos

Os títulos gerados não poderão ser antecipações, créditos, débitos ou provisórios, sendo obrigatório que sejam títulos passiveis de operações de baixas.

Por este motivo os tipos de títulos RA,PA,NCC,NDF e PR não são permitidos serem informados na configuração.

  • Dias máximo - prestação de contas em aberto
  • Quantidade máxima - prestações de contas em aberto
  • Adiantamento sem pernoite
  • Valor Fixo
  • Valor Diário
  • Natureza
  • Dias para previsão
  • Previsão de adiantamentos urgentes
  • Tipo de viagem - Nacional, Internacional ou Ambas
  • Tipo de Título
  • Prefixo de adiantamento solicitado com a viagem
  • Prefixo de adiantamento avulso
  • Data base do cálculo - Pedido ou início da viagem

Pedido: Considera como base de cálculo a data da solicitação da viagem até a data de finalização 
Início da Viagem: Considera como base de cálculo a data inicial da viagem até a data final

  • Conversão do Turismo - antes ou depois da geração do título
  • Bloqueia Adiantamento - define se o adiantamento será bloqueado na solicitação de viagens ou na aprovação do adiantamento, conforme configuração dos parâmetros "Dias máximo" e "Quantidade máxima".

Importante - Adiantamentos

Se a opção "Bloqueia Adiantamento" estiver com "1=Sim", o sistema passará a não permitir a geração do adiantamento, caso exista alguma prestação de contas em aberto para o participante na filial no qual está sendo incluída a solicitação, conforme parametrização das configurações "Dias (max.)" e "Quantidade (max.)".

Importante - Tipos de Títulos

Os títulos gerados não poderão ser antecipações, créditos, débitos ou provisórios, sendo obrigatório que sejam títulos passiveis de operações de baixas.

Por este motivo os tipos de títulos RA,PA,NCC,NDF e PR não são permitidos serem informados na configuração.

  • E-mails dos administradores
  • Centro de Custo de Rateio
  • Ambiente de interação com o Reserve
  • Integração com o Reserve - Desativado, Online, Schedule, Online e Schedule
  • Numeração de Viagens Internacionais
  • Numeração de Viagens Avulsas
  • Configuração de Aprovações
  • Aéreo
  • Hotel
  • Carro
  • Seguro
  • Rodoviários
  • Outros
  • Passageiro
  • Cliente
  • Data - com tolerância
  • Centro de Custo
  • Prefixo
  • Tipo de título
  • Natureza
  • Fornecedor e Loja


É importante ressaltar que todas as alterações efetuadas neste assistente reflete diretamente nos parâmetros do Protheus (SX6).


Esta rotina é responsável pelo mapeamento das filiais do backoffice Protheus com o ambiente Reserve, tais como usuário e senha de acesso para integração. Para mais informações, veja a página o manual desta integração aqui.

O grupo de acesso define as hierarquias de visualização dos dados de viagens dos colaboradores.

Por exemplo:

Temos os seguintes colaboradores da Empresa A:

  • João - Gerente
  • Paulo - Coordenador
  • Luciana - Analista de Sistemas
  • Ricardo - Analista de Sistemas

Existem dois grupos possíveis para configuração neste cenário:

1) João é o responsável do Grupo Departamento A, onde Paulo, Luciana e Ricardo são integrantes. Logo, João consegue visualizar as suas próprias viagens e as viagens que contém pelo menos um dos participantes do seu grupo;

2) Paulo é o responsável do Grupo Departamento A.1, onde Luciana e Ricardo são integrantes. Paulo consegue visualizar as próprias viagens e as que contém pelo menos um dos demais participantes do seu grupo.

Importante

Os usuários configurados no parâmetro de Usuário do Departamento de Viagens possuem visualização total dos dados.

As despesas são os tipos de gastos que um colaborador pode prestar contas à empresa. Através do cadastro de Tipo de Despesas (FINA679) é possível configurá-las.

Estas podem ou não efetuar algum controle de limites para a prestação de contas, tais como:

  • Sem limite - As despesas informadas serão consideradas reembolsáveis
  • Limite diário - A soma das despesas lançadas de mesmo tipo e no dia não deve ultrapassar o limite informado
  • Limite total - A soma de todas as despesas de mesmo tipo lançadas na prestação não deve ultrapassar o limite informado
  • Limite/despesa - A despesa está limitada ao limite informado

Caso seja necessário controlar estes limites, os valores possíveis para configuração de uma despesa são:

  • Valor Unitário - Para cálculo automático quando informada a quantidade na prestação de contas (ex. Km.).


    Importante

    Caso este campo esteja preenchido não será possível alterar o valor unitário da despesa na prestação de contas. 

    Para que seja possível informar valores diferente na prestação de contas, este campo deve permanecer com o valor zero (0) e será controlado o limite através dos campos de Limite sem pernoite e Limite com pernoite.

  • Limite sem pernoite - Valor limite para viagens que não exigem pernoite
  • Limite com pernoite - Valor limite para viagens que exigem pernoite
  • Limite Moeda 2 - Valor limite para gastos efetuados em dólar
  • Limite Moeda 3 - Valor limite para gastos em euro

Os limites possuem vigência, ou seja, caso seja necessário alterar a política é possível encerrar uma vigência informando a Data Final e informando os valores para um novo período.

É possível vincular os tipos de despesas a localizações:

  • Nacionais
  • Internacionais
  • Ambos

Essa amarração é realizada como uma outra ação na tela de cadastro de tipo de despesas.

Dica

O Tipo de Despesa possui em seu cabeçalho os dados das entidades de custo como facilitador para o lançamento da linha de despesas na prestação de contas.

O Grupo de despesas pode ser informado, mas não é obrigatório.

O Grupo de Despesas (FINA681) possui as mesmas características do Tipo de Despesa, com exceção das entidades de custo, tipo de limite por despesa e valor unitário, que são específicos da linha de despesas, e tem como objetivo agrupar e definir limites padrões para um determinado grupo.

Atenção

O valor configurado na despesa, quando informado, é prioritário no cálculo da prestação de contas.

O processo de viagens utiliza a base de Participantes (APDA020) do SIGAAPD - Avaliação e Pesquisa de Desempenho. Para tanto, neste cadastro existe na aba Viagens as informações necessárias para torná-lo um viajante, são elas:

  • Aba "Dados Gerais"
    • E-mail - utilizado para que o participante receba e-mails da notificação de aprovação de prestações de contas e adiantamentos
    • Disp Viage - Informe se um participante possuí disponibilidade para viagens. Utilizado apenas na integração com RESERVE, para solicitação de viagens este campo foi descontinuado.
  • Aba "Viagem"
    • Nível de cargo - utilizado para a integração com o Reserve e que define o tipo de acesso que o participante terá
    • Login Reserve - login do participante no Reserve
    • ID Reserve - preenchido após a integração do cadastro com o Reserve
    • Empresa e Filial atual - empresa e filial onde o participante atua no momento para controle dos pedidos do Reserve
    • Empresa e Filial anterior - registro histórico da empresa e filial onde o participante atuou anteriormente para controle dos pedidos do Reserve
    • Permite Adiantamento - informa se o participante é elegível a adiantamento
    • Aprovador - ID do usuário aprovador
    • Substituto - ID do usuário aprovador substituto
    • Fornecedor e Loja - Código do fornecedor e loja para crédito dos adiantamentos e reembolsos
    • Substituto da Prestação de Contas - ID do usuário que pode realizar a prestação de contas no lugar do participante (Ex. Funcionário de um Escritório de Projetos, Secretárias ou Assistentes Executivas etc).
    • Permite Viagem? - Indica se o participante terá permissão de solicitação de viagens ou utilização do app minha prestação de contas.

Um participante pode ou não ser um funcionário e as integrações com o módulo de Gestão de Pessoal para este são as existentes no Protheus (do cadastro do Participante replicando para a folha ou vice-versa com a configuração do .ini)

Importante

Caso utilizado o campo "Permite Viagem? - SIM", o código de usuário utilizado no cadastro do participante não poderá se repetir em outro código de participante com a mesma permissão de viagem.

Importante

Para que o participante seja considerado autoaprovador, é necessário configurar o parâmetro MV_RESAPRT com o valor "1" (sim) e preencher o campo Aprovador no cadastro de Participantes (aba Viagem) com o seu próprio código. Só é possível realizar este processo do cadastro em operação de Alteração.

Privilégios para controle de acesso a rotinas

Os usuários que possuem acesso a rotina do menu aprovação (F677APROVA), rotina: FINA677 também deverão possuir acesso ao menu Aprovar/Reprovar (F677ARVrpv) da rotina FINA677APR. Caso o privilégio FINA677APR não seja adicionado junto ao FINA677, ocorrerá um erro de permissão no momento da aprovação de uma prestação de contas.

Segue abaixo um exemplo de configuração:


Para mais informações da integração de Participantes com o Reserve, consulte aqui.

Apesar do Reserve possuir somente como entidade de custo o Centro de Custo e o Protheus trabalhar com outras entidades, é possível efetuar as classificações no Protheus através da rotina de Viagens (FINA665). Em Ações Relacionadas, através da opção Alterar Ent. Custos, é possível informar também a Classe de Valor e o Item Contábil.

O restante das rotinas carregam estes custos da viagem ou então, no caso da Prestação de Contas ou Solicitação de Viagem, possuem campos para a entrada das entidades.

Para mais informações da integração de Centro de Custos com o Reserve, consulte aqui.

Alguns eventos do processo de Viagens realizam o envio de e-mail padrão para notificar o participante envolvido na ação que acabou de ser executada. Muito legal né ?! (sorriso) 

Veja quais são esses eventos:

Na rotina de Viagens (FINA665)

  1. Ao conferir a solicitação, transitando o status da mesma p/ "Aguardando Aprovação" - Notifica o aprovador.

Na rotina de Adiantamentos (FINA667)

  1. Ao gerar o adiantamento em status "Solicitado" - Notifica o aprovador;
  2. Ao reprovar um adiantamento na etapa de aprovação do gestor (incluindo a aprovação por lote) - Notifica o viajante;
  3. Ao liberar o pagamento do adiantamento gerando o título financeiro através da ação "Liberar Pagto" - Notifica o viajante.

Na rotina de Prestação de Contas (FINA677)

  1. Ao conferir uma prestação de contas pelo departamento de viagens através da ação "Conferir" - Notifica o aprovador;
  2. Ao reprovar uma prestação de contas na etapa de aprovação do gestor - Notifica o viajante;
  3. Ao liberar o reembolso para o viajante ou a devolução p/ a empresa, gerando o título financeiro através da ação "Liberar Financ." - Notifica o viajante.

Para que todo esse fluxo tenha a dinâmica do envio de e-mails, é necessário alguns pré-requisitos, tais como:

  • Configurar servidor de e-mail do Protheus;
  • Ter o campo "E-mail" preenchido no cadastro do Participante com um endereço válido;
  • Ter o parâmetro MV_RESAVIS (presente no Assistente de Configuração, seção "Gerais") configurado como "1";
  • Permitir que o serviço de e-mail (Google, Office365, etc) seja acessado pelo Protheus. Essa ação só se faz necessária caso você receba um alerta Google/Microsoft sobre o bloqueio à tentativa de conexão de um dispositivo desconhecido.

Exemplo de um e-mail que foi disparado para o gestor aprovador no momento em que o departamento de viagens conferiu a prestação de contas (ação "Conferir->Aprovar"):

Importante

Em caso de utilização do workflow com o Fluig, para cada processo configurado (SOLVIAJ1 - Solicitação de Viagem, SOLADIANTA - Adiantamento, APVPRESTCO - Prestação de Contas), o envio de e-mail nesses eventos será desconsiderado.

01. VISÃO GERAL

Um funcionário (neste cenário, o chamamos de Participante) necessita fazer uma viagem corporativa, por algum motivo, seja ele qual for (ex: atendimento/visita ao cliente, reunião de negócios, evento). Então esta rotina terá como principal objetivo registrar a solicitação dessa viagem, contemplando informações relevantes para controlar as despesas da viagem e suas políticas.

Importante

Esta rotina contempla apenas solicitações do Protheus. As viagens integradas com o Reserve não geram solicitação, pois são compradas e emitidas diretamente pela agência.


Nos itens da viagem será possível selecionar e justificar/detalhar os seguintes serviços:

  • Vôo
  • Hotel
  • Carro
  • Rodoviário
  • Seguros
  • Outros


Atenção

  • Estes itens de serviço são parametrizáveis e estão no Assistente de Configuração. Caso a empresa não ofereça algum destes itens em sua política, será possível oculta-lo(s).
  • O item Outros é o único em que não é necessário a compra de serviço, logo solicitações somente com este serviço não passam pela etapa de conferência da solicitação, por essa razão o email informando que a solicitação de viagem finalizada não é disparado. Esta é necessária quando um colaborador deseja solicitar somente um adiantamento, pois irá fazer, por exemplo, uma visita a um cliente com veículo próprio e deseja somente o adiantamento.

Quando parametrizadas para aprovação após a solicitação, será gerada uma pendência de aprovação para o superior dos participantes. Caso contrário esta pode ser enviada para o departamento de viagens (diretamente após a solicitação ou em um segundo momento através da opção de envio) e a viagem será gerada automaticamente.

Exemplo:

A empresa pode decidir por passar por todas as aprovações, neste caso o fluxo será:

Ou então pode ser que apenas uma das aprovações seja necessária, neste caso temos:


Importante

Quando não existir a etapa de aprovação de viagens, para que a solicitação de viagens (FW3), se torne uma viagem (FL5) e possa dar continuidade ao fluxo, a solicitação passará obrigatoriamente pelo conferencia do departamento de viagens, na rotina de solicitação de viagens (FINA666) vá em OUTRAS AÇÕES → Enc. p/ Dpto Viagens (Gerando a viagem na rotina FINA665)



02. EXEMPLO DE UTILIZAÇÃO

Acesso à rotina pelo caminho: Atualizações > Viagens > Solicitação de Viagem

O viajante deve informar os dados básicos da viagem no cabeçalho da sua solicitação, como origem e destino, datas de partida e chegada, cliente para atendimento (se houver), etc.
Para cada serviço deve ser informado o(s) Participante(s) e a(s) sua(s) respectiva(s) Entidade(s) de Custo.



Além disso, na aba Adiantamentos é possível marcar quais participantes receberão adiantamento.

Importante

Se a opção "Bloqueia Adiantamento" estiver com "1=Sim", o sistema passará a não permitir a geração do adiantamento, caso exista alguma prestação de contas em aberto para o participante na filial no qual está sendo incluída a solicitação, conforme parametrização das configurações "Dias (max.)" e "Quantidade (max.)".


O valor calculado é uma previsão e é exibido somente quando estiver parametrizado:

03. ROTINA AUTOMÁTICA

Para execução da rotina automática, ilustramos algumas funcionalidades como Inclusão (MyFA666Inc), Alteração (MyFA666Alt) e Exclusão (MyFA666Del), nos seguintes exemplos:


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

//---------- Inclusao da solicitacao de viagem ----------//
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 ambiente com usuario solicitante

oModel := FWLoadModel("FINA666")
oModelFW3 := oModel:GetModel("FW3MASTER") // Cabecalho da viagem
oModelFW4 := oModel:GetModel("FW4DETAIL") // Servicos 
oModelFW5 := oModel:GetModel("FW5DETAIL") // Participantes
oModelFW6 := oModel:GetModel("FW6DETAIL") // Centro de custo
cFilAtu := xFilial("FW3")

oModel:SetOperation(MODEL_OPERATION_INSERT)
oModel:Activate()
// Preenche cabecalho da solicitacao de viagem
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") // Em Aberto, status inicial
// Preenche grid do servico incluso na solicitacao da viagem
oModelFW4:SetValue("FW4_ITEM",StrZero(1,TamSX3("FW4_ITEM")[1]))
oModelFW4:SetValue("FW4_TIPO","1") // Aereo
oModelFW4:SetValue("FW4_OBS", "Visita ao cliente")
// Preenche grid dos participantes viajantes
oModelFW5:SetValue("FW5_ITEM",StrZero(1,TamSX3("FW4_ITEM")[1]))
oModelFW5:SetValue("FW5_PARTIC","000001")
oModelFW5:SetValue("FW5_ADIANT",.T.) // Adiciona adiantamento ao participante
oModelFW5:AddLine() // Adiciona linha para um segundo viajante
oModelFW5:SetValue("FW5_ITEM",StrZero(2,TamSX3("FW4_ITEM")[1]))
oModelFW5:SetValue("FW5_PARTIC","000002")
oModelFW5:SetValue("FW5_ADIANT",.T.) // Adiciona adiantamento ao participante
// Preenche grid do centro de custo
oModelFW6:SetValue("FW6_ITEM",StrZero(1,TamSX3("FW4_ITEM")[1]))
oModelFW6:SetValue("FW6_CC","002 ")
oModelFW6:SetValue("FW6_PORCEN",100)
oModelFW5:GoLine(1)
// Validacao e gravacao dos dados se consistentes
If oModel:VldData() 
     oModel:CommitData()
     Conout("Inclusao da solicitacao de viagem concluida com sucesso.")
Else 
     VarInfo("",oModel:GetErrorMessage())
     Conout("Erro na validacao, solicitacao de viagem nao foi incluida.")
EndIf

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

Return


//---------- Alteracao da solicitacao de viagem ----------//
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 ambiente com usuario solicitante

dbSelectArea("FW3")
dbSetOrder(1)
dbSeek(xFilial("FW3")+cSolic)
// Carrega modelo de dados com a solicitacao de viagem posicionada
oModel := FWLoadModel("FINA666")
oModelFW5 := oModel:GetModel("FW5DETAIL") // Participantes
oModelFW6 := oModel:GetModel("FW6DETAIL") // Centro de custo
// Chave de busca do participante dentro da sol. da viagem
aKeyFW4 := { {"FW5_FILIAL",xFilial("FW5")},{"FW5_SOLICI",cSolic},{"FW5_ITEM","01"},{"FW5_PARTIC","000002"} }

oModel:SetOperation(MODEL_OPERATION_UPDATE)
oModel:Activate()
// Remove um dos viajantes, no caso o participante 000002
If oModelFW5:SeekLine(aKeyFLE)
     oModelFW5:DeleteLine()
Else
     Conout("Viajante nao encontrado nesta solicitacao de viagem.")
EndIf
// Altera o centro de custo (posicionado automaticamente no primeiro grid)
oModelFW6:SetValue("FW6_CC","003 ")

// Validacao e gravacao dos dados se consistentes
If oModel:VldData() 
     oModel:CommitData()
     Conout("Alteracao da solicitacao de viagem efetuada com sucesso.")
Else 
     VarInfo("",oModel:GetErrorMessage())
     Conout("Erro na validacao, solicitacao de viagem nao foi alterada.")
EndIf

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

Return


//---------- Exclusao da solicitacao de viagem ----------//
User Function MyFA666Del()

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

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

dbSelectArea("FW3")
dbSetOrder(1)
dbSeek(xFilial("FW3")+cSolic)
// Carrega modelo de dados com a solicitacao de viagem posicionada
oModel:= FWLoadModel("FINA666")
oModel:SetOperation(MODEL_OPERATION_DELETE)
oModel:Activate()

// Validacao e gravacao da exclusao
If oModel:VldData() 
     oModel:CommitData()
     Conout("Solicitacao de viagem excluida com sucesso.")
Else 
     VarInfo("",oModel:GetErrorMessage())
     Conout("Erro na validacao, solicitacao de viagem nao foi excluida.")
EndIf

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

Return




04. TABELAS UTILIZADAS

  • FW3 - Cabeçalho da Solicitação
  • FW4 - Serviços (itens)
  • FW5 - Participantes
  • FW6 - Entidades de Custos


A rotina de Viagens (FINA665) possui todas as informações relacionadas às viagens já emitidas via agência ou solicitação de viagem avulsa.

Uma viagem é composta por:

Cabeçalho da viagem, que possui os dados de data de início e fim, origem e destino, cliente a ser atendido (quando aplicável) etc.

Na aba adiantamentos são listados os participantes e os adiantamentos solicitados para cada um deles.

Na aba da viagem propriamente dita temos a listagem de todos os pedidos efetuados.

Ao selecionar um item de pedido da viagem, é habilitado um contexto por serviço com os dados específicos de cada um deles, como por exemplo: Para vôo temos a Cia. Aérea, Localizador, Classe etc.; no caso de um hotel temos o Nome do Hotel, datas de check-in e check-out etc. O serviços possíveis são:

  • Vôo
  • Hotel
  • Carro
  • Rodoviário
  • Seguros
  • Outros

São exibidos também os Participantes e as Entidades de Custo relacionadas.

Uma viagem efetuada no Reserve, é integrada somente quando está emitida, ou seja, não é possível alterar os seus serviços no Protheus (datas, valores etc). Os únicos dados passíveis de edição são as Entidades de Custo. Para mais detalhes, consulte o manual da integração TOTVS X Reserve.

Já uma viagem gerada de uma Solicitação de Viagens do Protheus, deve ter os seus detalhes de serviços informados pelo departamento de viagens através da opção de Conferência, já que a solicitação é um pedido para a compra da viagem. Caso a aprovação esteja habilitada após a conferência, será gerada um pendência de aprovação para o superior dos participantes.

Uma viagem com todos os seus serviços e gastos devidamente pagos e prestado contas é elegível para faturamento. Este processo exibe os custos da viagem que podem ser repassados para o cliente, integral ou parcialmente, e gera um pedido de venda para o cliente. Caso não seja aplicável para o segmento da empresa, este passo não é obrigatório.



01. VISÃO GERAL

Os Adiantamentos (FINA667) são os valores creditados aos colaboradores para cobrir os gastos de uma viagem, tais como alimentação, transporte, comunicação etc.

Estes valores são calculados através da configuração da política de viagens da empresa, podendo ser:

  1. Valor Fixo: Este é o valor fixo concedido, normalmente para o valor de traslado.
  2. Valor com e sem Pernoite: Quando a viagem possui período dentro do mesmo dia, é calculado o valor do adiantamento sem pernoite, caso extrapole uma diária, será calculado com o valor com pernoite
  3. Outras moedas: Os valores em outras moedas são normalmente concedidos mediante crédito em traveller check ou compra de moeda. Para este caso o Protheus não faz o cálculo, mas o valor do crédito deste adiantamento deve ser informado. As taxas de conversão da compra desta moeda para a moeda forte podem ser informadas antes ou depois da geração do título mediante configuração no Assistente de Configuração.

Na rotina de Viagens (FINA665) ainda é possível solicitar complementos de adiantamentos. Caso um colaborador precise de mais dinheiro em uma viagem, esta solicitação pode ser efetuada selecionando a viagem e a opção Adiantamento Avulso. Neste caso é gerado mais um adiantamento vinculado à viagem.

As regras de geração de título, tais como Prefixo, Natureza, Data de Vencimento para adiantamentos normais e urgentes (aqueles solicitados fora da regra da política de antecedência) estão no Assistente de Configuração.

Os adiantamentos solicitados tanto via Reserve, Solicitação de Viagens ou Avulso não são aprovados em conjunto com a viagem e geram uma pendência para o superior do viajante, se configurado.


Importante

Se a opção "Bloqueia Adiantamento" estiver com "1=Sim", o sistema passará a não permitir a geração do adiantamento, caso exista alguma prestação de contas em aberto para o participante na filial no qual está sendo incluída a solicitação, conforme parametrização das configurações "Dias (max.)" e "Quantidade (max.)".

Exemplo:

Se for necessária a aprovação do superior e avaliação financeira, temos:


Ou então teremos os seguintes cenários se uma etapa puder ser realizada automaticamente:

Dica

A contabilização do adiantamento é realizado pelo lançamento padrão de inclusão de título.

Para os casos em que o adiantamento é em outra moeda e a taxa informada depois da geração do título, o mesmo deve ser contabilizado offline.

Atenção

Este processo não é obrigatório.


02. EXEMPLO DE UTILIZAÇÃO

O adiantamento pode ser gerado à partir da solicitação de viagem (FINA666), selecionando esta opção na aba Adiantamentos:

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


O campo RD0_DVIAGE é de uso exclusivo para a integração do RESERVE e que está descontinuado.

Ao clicar no campo adiantamento para o participante, o a adiantamento somente será solicitado se o cadastro do participante estiver com o campo Adiantamento "SIM". Esse controle será feito através do campo RD0_PERMAD (Cadastro de Pessoas).

Se o campo RD0_PERMAD estiver com o valor igual a "Não", o sistema irá mostrar tela de help, conforme abaixo e não permitirá e inclusão do adiantamento para o participante.

Mesmo com a adiantamento bloqueado pelo sistema para adiantamento ao participante na inclusão de viagnes, o sistema não bloqueará a prestação de contas se houver necessidade para esse praticante.

 

Ou após a Viagem já ter sido enviada para o departamento de viagens (FINA665), clicando no botão "Solic. Adiant." e selecionando os participantes que receberão o adiantamento:



Então, através da rotina FINA667, o adiantamento pode ser visualizado, e seguir seu fluxo de ações:

03. ROTINA AUTOMÁTICA

Para execução da rotina automática, ilustramos a solicitação do adiantamento após a efetivação da viagem (MyFA667A), no seguinte exemplo:


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

//---------- Solicitacao de adiantamento da viagem ----------//
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 ambiente com usuario solicitante

dbSelectArea("FL5")
dbSetOrder(1)
dbSeek(xFilial("FL5")+cViagem) // Viagem ja solicitada

// Carrega modelo de dados com a solicitacao de viagem posicionada
oModel := FWLoadModel("FINA667A")
oModelFLC := oModel:GetModel("FLCDETAIL") // Participantes
oModelFLD := oModel:GetModel("FLDDETAIL") // Adiantamentos
// Chave de busca do participante dentro da da viagem
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 recebera adiantamento
     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","Adiantamento para viajante")
          // Validacao e gravacao dos dados se consistentes
          If oModel:VldData()
               oModel:CommitData()
               Conout("Adiantamento solicitado com sucesso.")
          Else 
               VarInfo("",oModel:GetErrorMessage())
               Conout("Erro na validacao, adiantamento nao foi solicitado.")
         EndIf
     Else
          Conout("Viajante nao encontrado nessa viagem.")
     EndIf
EndIf

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

Return



04. TABELAS UTILIZADAS

  • FL5 - Viagem
  • FLC - Passageiros
  • FLD - Adiantamentos

Com uma viagem em andamento ou após a sua conclusão, o viajante deve efetuar sua prestação de contas das despesas para a empresa.

Toda viagem, independente de possuir ou não um adiantamento, gera automaticamente um registro na rotina de Prestação de Contas (FINA677) vinculada à ela.

Uma prestação de contas possui os dados básicos de uma viagem, como o seu número, data de início e fim, local, cliente que foi atendido (se for aplicável), além das entidades de custo e percentual de faturamento contra o cliente (se o cliente for aplicável) etc.

O colaborador poderá informar item à item, os gastos que teve em sua viagem informando: despesa, local, valor (na moeda corrente ou em outra e sua taxa de conversão), quantidade, entidades de custos etc.

Além disso, os adiantamentos são listados na prestação de contas e abatidos do valor total no rodapé da prestação de contas.

Os valores gastos, os reembolsáveis e o saldo também são exibidos no rodapé, nas 3 moedas tratadas pelo Protheus: corrente, dólar e euro.

Atenção

  • Uma prestação de contas só pode ser finalizada desde que todos os adiantamentos vinculados à viagem, se houverem, estiverem pagos, ou seja, creditados ao colaborador. Isso previne que seja creditado um valor de reembolso indevido ao colaborador.
  • Todas as outras moedas são convertidas para dólar, uma vez que a operação mais comum é a de concessão de traveller checks em dólar para débito, crédito ou saque na moeda corrente de outros países. Por exemplo: Em uma despesa efetuada em rúpias, a taxa informada da transação do traveller check deve ser a de referência de conversão em dólar.
  • Título oriundo da prestação de contas: FINA667 ou FINA677 não pode ser negociado.

Uma vez finalizada e encaminhada para o departamento de viagens (após sua inclusão ou em momento posterior pela opção de envio para conferência), o departamento de viagens fará a conferência da prestação. Apesar do sistema já efetuar os cálculos dos valores reembolsáveis dos gastos através da regra de limites das despesas, se o conferente identificar algum item nos comprovantes que estão fora da política de viagens, o mesmo pode lançar os descontos neste momento e o valor a ser devolvido/reembolsado é atualizado.

Caso os passos de aprovação e/ou liberação para financeiro estejam ativos, serão geradas pendências para o superior do viajante e para o financeiro/departamento de viagens, respectivamente.

Exemplo:

No caso em que o processo todo deve passar por aprovação ou conferência, temos:

Caso alguma etapa possa ser realizada automaticamente, temos:


Por fim, além das viagens, a rotina também permite efetuar prestações de contas avulsas.


Na inclusão de uma Prestação de Contas Avulsa, existe a opção "Alt. Viajante" em que é possível alterar o participante da Prestação de Contas.

Como exemplo: 

Dois funcionários de uma empresa precisam fazer uma visita em um determinado cliente e um deles irá incluir a prestação de contas para o outro funcionário. 

Funcionário João : é quem irá incluir a prestação de contas para a Maria. Será o Substituto da Maria.

Funcionária Maria:  é quem terá a prestação de contas incluída pelo João. No seu cadastro de participante (APDA020), deverá ter configurado o usuário João como seu Substituto (RD0_USRPRE). 

Nesse caso, o usuário João deve acessar o sistema e na inclusão da Prestação de Contas Avulsa, deve efetuar a alteração do Viajante, informando o Participante: Maria . 

Dessa forma, o participante da  Prestação de Contas passará a ser a usuária Maria (FLF_PRESTA).  

Dica

A contabilização da prestação de contas possui lançamentos específicos para a contabilização das despesas, sendo eles:

  • 8B3 - Item da Prestação de Contas/Despesa
  • 8B4 - Estorno do Item da Prestação de Contas/Despesa
  • 8B5 - Cabeçalho da Prestação de Contas*
  • 8B6 - Estorno do Cabeçalho da Prestação de Contas*

*Os totalizadores da prestação de contas são gravados na tabela FLF - Cabeçalho da Prestação de Contas




A Conferência de Serviços nada mais é que o espelho da fatura de uma agência de viagens ou dos próprios fornecedores diretos (companhias aéreas, hotéis, locadoras de carros etc.).

Nesta rotina é possível selecionar os itens de viagens, seja por serviço ou considerando todos os tipos, para seleção e edição do pagamento enviado na fatura. Com os pedidos devidamente selecionados e os valores editados quando necessário, será gerado um pedido de compra, uma nota ou um título a pagar.

Importante

  • Quando uma viagem é remarcada, o pedido apenas é cancelado dentro da viagem, uma vez que muitos serviços incorrem taxas/custos de cancelamento ou remarcação. Por este motivo, tanto o remarcado quanto o ativo serão exibidos no pagamento.
  • Ao selecionar um pedido para conferência, é sugerido o valor do serviço cadastrado na viagem, mas é possível editá-lo para maior ou menor, sendo que esta última opção também permite finalizar o pagamento do item ou manter o saldo para conferências parciais.
  • Os percentuais das entidades de custo da viagem são proporcionalizados e carregados para o registro gerado da conferência.

Dica

A contabilização do adiantamento é realizado pelo lançamento padrão de inclusão de título.

Quando existe um acordo entre fornecedor e cliente a respeito do pagamento de gastos das viagens, o Protheus permite faturar tanto a viagem completa como um prestação de contas avulsa.

O faturamento de uma viagem inclui os custos dos serviços contratados (voo, hotel, locação de carros, seguros e rodoviário) e os gastos dos colaboradores envolvidos. Quando todos os serviços estiverem pagos e a prestação de contas finalizada e aprovada, a viagem estará apta a ser faturada contra o cliente, seja parcial ou totalmente. Contudo, é possível parametrizar as regras de viagens e permitir o faturamento antecipado de uma viagem, desde que ao menos a prestação de contas esteja finalizada, uma vez que este é um custo variável, diferentemente dos serviços que possuem uma previsão na sua contratação.

Já as prestações de contas avulsas podem ser faturadas assim que finalizadas.

Atenção

Este processo não é obrigatório.

Para mais informações acesse os manuais de integração TOTVS X Reserve e PCO X Reserve.

O App Minha Prestação de Contas permite um controle fácil e rápido para que viajantes corporativos mantenham sua prestação de contas atualizada durante uma viagem.

Com este aplicativo é possível:

  • Sincronizar as prestações de contas de viagens;
  • Incluir uma prestação de contas avulsa;
  • Gerir/Controlar despesas;
  • Acompanhar o saldo da prestação de contas;
  • Encaminhar uma prestação de contas para conferência e aprovação;
  • Acompanhar as prestações de contas já encerradas;
  • Corrigir as prestações de contas recusadas.

O mínimo deste processo que precisa estar configurado para o funcionamento do aplicativo é:

  • Cadastros
    • Despesas (com ou sem amarração por localidade e grupo)
    • Grupo de acesso
    • Participantes
  • Prestação de Contas (avulsa)

Já um processo completo de viagens para o App engloba:

  • Cadastros
    • Wizard de Configuração
    • Participante
    • Grupo de Acesso
    • Despesa
    • Grupo de Despesa
  • Solicitação de Viagem (Via integração Reserve ou Protheus)
  • Viagem
  • Adiantamento
  • Prestação de Contas (foco do app)

Atenção

  • Este aplicativo é complementar ao processo de controle de viagens do Financeiro Protheus;
  • É preciso ter um usuário e senha do Protheus (a partir da versão 12.1.17 expedição Janeiro/18) para utilizá-lo;
  • Não é obrigatório o uso da integração TOTVS Reserve, pois já é possível efetuar solicitação de viagem avulsa no Protheus.

Para mais informações acesse o TOTVS Minha Prestação de Contas na área do Aplicativos.

Para fazer o download do App acesse o Google Play.