Pular para o conteúdo
Português - Brasil
Nosso contato
  • Não há sugestões porque o campo de pesquisa está em branco.

Roteiro de Implantação do InnCash

Passo a passo para implantação do InnCash em um novo cliente

  • 1 KICKOFF E PRIMEIROS PASSOS



    Após a formalização do contrato comercial, é realizada a reunião de Kickoff com o cliente, com o objetivo de alinhar expectativas e compreender melhor seus processos e o escopo da implementação.

    Durante essa reunião:


    • Apresentamos a equipe técnica responsável pelo projeto;
    • Identificamos e priorizamos as principais demandas do cliente;
    • Avaliamos a necessidade de customizações específicas.

    A partir desse momento, o time comercial conclui sua participação e a gestão passa a ser conduzida integralmente pela equipe de projetos.


    Nos anexos, está disponível a planilha utilizada para pegar as informações do cliente. É importante questionar se o cliente já utiliza arquivos de pagamento/recebimento, porque alguns bancos após a ativação da Van, deixa de trafegar no Internet Banking (ex.: Itaú). Se o cliente já utiliza o envio de arquivos, é necessário primeiro habilitar o tráfego em base teste e depois combinar com o cliente uma data de virada.


    • Criação do Grupo e Reuniões Semanais

    Durante a reunião de Kickoff, informamos ao cliente que será criado um grupo no WhatsApp para centralizar a comunicação do projeto. Nesse grupo serão incluídos:


    • Equipe de Implantação (InnCash);
    • Equipe Técnica (InnCash);
    • Equipe Financeira (InnCash);
    • Representantes do cliente (TI e demais responsáveis pelo projeto).

    O grupo segue o padrão de nomenclatura:

    InnCash | Nome Cliente | Implantação


    A logo do grupo é padronizada pelo time de Marketing, sendo necessário solicitar o envio antes da criação.

    ⚠️ Importante: a equipe de Suporte será adicionada apenas após a conclusão do projeto, no momento de transição para a fase de sustentação.


    • Solicitações ao Cliente

    Solicitamos a logo do cliente em formato PNG com fundo transparente, para ser incluído dentro da plataforma.













    2 CONFIGURAÇÕES TÉCNICAS




    O primeiro passo após a reunião de Kickoff é o envio de um e-mail ao cliente com a lista de liberações necessárias em seu ambiente. Esse envio é realizado pela equipe de ADVPL (Francisco). 


    O cliente pode optar por aplicar internamente todas as liberações solicitadas e, posteriormente, disponibilizar para validação, ou, se preferir, pode agendar uma reunião conjunta para que as liberações sejam feitas em parceria com a equipe responsável.


    2.1 Configuração pela equipe de TI do cliente


    Nesse caso, solicitamos ao cliente apenas uma data prevista para a liberação e nos colocamos à disposição para esclarecer eventuais dúvidas durante o processo. Essa etapa contempla a criação das triggers, a configuração dos campos no Protheus e a execução dos scripts necessários.


    2.2 Configuração pela equipe do InnCash


    Caso o cliente opte, realizamos as configurações em call juntamente com eles. Neste caso, nós quem rodamos todos os processos mencionados anteriormente.


    2.3 Configuração da VMLINUX


    Esta etapa é realizada pela equipe de WEB (Julio). Com o acesso ao banco que o cliente irá nos passar, criamos a atividade para ele configurar o integrador. 



















    3 CRIAÇÃO DO CRONOGRAMA




    3.1 Detalhamento das Atividades


    Para a criação do cronograma, é necessário compreender quantas contas e produtos foram contratados pelo cliente. Os módulos do InnCash podem ser divididos em:


    • Remessa de Pagamento
    • Remessa de Cobrança
    • Conciliação de DDA
    • Conciliação de Extrato
    • Pix Puro
    • Remessa de Instruções
    • Folha de Pagamento
    • Módulo de Cobrança

    Após o levantamento das atividades, elaboramos o cronograma com base nas demandas identificadas e nas programações já existentes. No Anexo I encontra-se o link com os prazos padrão, sendo que, em média, o tempo de conclusão do projeto é de três meses.


    3.2 Atividades no Artia


    Com as datas definidas, precisamos criar um projeto no Artia para o cliente e incluir cada atividade lá dentro. Com isso temos o seguinte padrão:



    1. Solicitar ao administrativo a criação de um centro de custo específico para o cliente.
    2. No módulo do InnCash, cria uma pasta com o nome do cliente:




    1. Dentro da pasta do cliente, cria-se os seguintes projetos padrões: 
    • 01 – Implantação InnCash
    • 02 – Suporte InnCash. 

    Caso tenha algum novo desenvolvimento, é necessário criar outro projeto e passar a nomenclatura no email do financeiro.


    1. Dentro de cada projeto, terão pasta e subpastas. Todas devem seguir o mesmo padrão:


    1. Após a criação das pastas, é necessário preencher as atividades do cronograma em Implantação e Testes. Para isso, basta criar as atividades do cronograma separadas, estabelecer a data, o responsável e amarrar uma tag com o nome do cliente.


    1. Após a vinculação da tag em todas as atividades, precisamos criar uma visão desse cliente. Pode duplicar a visão de outro cliente e só mudar o nome e a tag vinculada.



    1. Com todas as atividades criadas, é necessário gerar o link do cronograma. Primeiro de tudo, precisa ir em Projetos – Relatório de Situação. 


    1. Os relatórios precisam ser criados dessa forma:


    1. Por fim, precisamos ir em lista de projetos e vincular o link do cronograma.




    1. Com o link pronto, basta enviar ao cliente. A partir desse momento, conforme as atividades forem sendo apontadas no Artia, a visão do cliente será atualizada automaticamente.





    3.3 Acompanhamento do Cronograma


    Com o cronograma entregue, é necessário alinhar com o cliente uma data fixa para as reuniões semanais. Nessas reuniões, será apresentado o status de cada atividade, bem como a análise de eventuais pontos que possam estar impactando o andamento da implantação.



    4. ENVIO DAS CARTAS BANCÁRIAS



    Essa etapa pode ser feita em paralelo com as configurações técnicas. Ela consiste em enviar uma planilha (anexo II) para o cliente após o Kickoff para ser preenchido todas as contas e produtos que serão utilizados na plataforma.

    É importante validar se todas as contas e produtos foram contratados.



    4.1 Criação das cartas


    Para o sistema funcionar, é fundamental que o tráfego dos arquivos ocorra. Para isso acontecer, o banco precisa fazer a liberação dos arquivos para cada Van correspondente. O modelo das cartas está disponível no Anexo III.


    • Santander – Van Cisa
    • Banco do Brasil – BBSIA
    • Safra – Tráfego via SFTP
    • Demais bancos: Accestage

    Após a elaboração de cada documento, é necessário enviar ao cliente e pedir que ele assine e envie por email ao gerente, conosco em cópia para acompanhamento.



    4.2 Contratação dos Tráfegos


    Para os bancos que utilizam a Van Accestage, é necessário fazer uma planilha com todas as contas e produtos e enviar para contratação da Van, nos seguintes emails: expansao@accesstage.com.br



    4.3 Acompanhamento dos Tráfegos


    É necessário criar uma planilha no Drive (anexo IV) e compartilhar com o cliente. Essa planilha iremos atualizar todos os dias e repassar as pendências nas reuniões semanais.




    5 CONFIGURAÇÃO DE CADASTROS



    Nesta etapa entraremos com as configurações das atividades baseadas no cronograma de implantação. Isso tudo ocorre após a finalização das configurações técnicas (Protheus e Integrador).


    5.1 Configuração de Empresas


    Esta etapa é configurada pelo Líder do Projeto ou do Desenvolvimento. Consiste no cadastro dessas tabelas:


    • fluxocaixa.settings_external_company_databases: necessário criar uma para cada company, informando as tabelas a serem utilizadas pelo cliente, o número da empresa e filial, com base no cadastro dessa empresa no Protheus.
    • fluxocaixa.customers_erp: nessa tabela é informada a integração com o ERP e o DNS utilizado para isso.
    • fluxocaixa.user: para o primeiro acesso, é necessário criar o usuário de administrador para conseguir acessar o InnCash e fazer o restante das configurações.
    • fluxocaixa.purchased_modules: para criar o primeiro usuário, é necessário vincular em qual módulo ele terá acesso.
    • fluxocaixa.company_configurations: nessa tabela é informada os tipos de documentos que a empresa utiliza, conforme o padrão dela do Protheus.
    • fluxocaixa.company_group: é informado o número do grupo da empresa.
    • fluxocaixa.company: é informado o número das filiais com base no company_group.
    • fluxocaixa.financial_document_situation: nesta tabela são cadastradas as carteiras dos títulos com base no que o cliente trabalha.
    • fluxocaixa.bordero_config: aqui é informada a carteira para geração do borderô na API.
    • fluxocaixa.company_group_dictionary: se refere ao cadastro do dígito da conta e dígito da agência.
    • fluxocaixa.company_group_configuration: aqui são cadastradas as configurações dos grupos de empresas.
    • fluxocaixa.user_groups: nesta tabela são cadastrados os grupos de usuário do cliente.
    • fluxocaixa.user_group_modules: nesta tabela são amarradas o módulo com o grupo de usuário.
    • fluxocaixa.cnab_directory_configuration: aqui devem ser realizados os cadastros para ler o retorno bancário. É realizado para cada banco do company do cliente, informando qual o diretório ele irá cair na Van e só pode ser realizado o cadastro após a criação dessa pasta no client.
    • fluxocaixa.cnab_bank_configuration: nesta tabela devem ser cadastradas as configurações de cnab para ler o arquivo de retorno. Cada campo se refere as principais posições do layout do banco.
    • fluxocaixa.bank_config_send_type: é necessário fazer a vinculação do retorno na tela de configurações bancárias.





    5.1 Configuração de Tipo de Usuários e Usuários


    Nesta etapa teremos que ir ao menu do InnCash – Acesso e realizar os seguintes cadastros:


    • Tipo de Usuário: Define as permissões de cada um.
    • Usuários: Informa os usuários que terão acesso ao sistema. Quem envia essa informação é o próprio cliente. Cadastramos o email e a senha, mas só repassamos a eles após os treinamentos.

    5.2 Cadastro das formas de pagamento e recebimento


    No menu de cadastros, é necessário configurar a forma de pagamento e recebimento que o cliente irá iniciar. Por padrão, habilitamos esses, mas se necessário, cadastramos depois alguma outra que o cliente necessite.


    Pagamento:

    001 – Boleto

    002 – TED

    004 – TED – Outra Titularidade

    005 – GPS

    006 – DARF

    007 – Pix

    008 – Boleto – Outra Titularidade

    010 – Concessionária

    011 – Tributos Municipais

    012 – Tributos 


    Recebimento:

    001 – Boleto


    5.3 Cadastro dos Agrupadores Previsto/Realizado


    Esta etapa é necessária para fazer a distribuição dos títulos nos fluxos de Caixa. Dividimos em três agrupadores: Nível 0, Nível 1 e Nível 2. Estes cadastros realizamos padronizados (pode entrar em outros clientes e copiar as mesmas informações), mas pode ser ajustado após as validações dos clientes.


    Após a criação dos agrupadores, é necessario vincular o id de cada nível 0 na tabela fluxocaixa.grouper no campo cashflow_grouper_id. A ordem correta é Bancos, Entradas e Saídas.


    5.4 Cadastrar as Configurações de CNAB


    Aqui iremos precisar fazer o cadastro de todos os produtos que o cliente irá utilizar (remessa e retorno de pagamento, remessa e retorno de cobrança, extrato e DDA). Para fazer a configuração, basta entrar em outro cliente com usuário de administrador, ir nas confugurações de Cnab e copiar todas as configurações dos mesmos bancos em comum.



    Após a duplicação, é necessário verificar se copious todas as validações, muitas vezes acaba se perdendo (principalmente no retorno).



    5.5 Cadastrar as Configurações de Conciliação Bancária


    O cadastro das configurações de conciliação bancária é para leitura dos arquivos de extrato. Basta ir no botão “adicionar” e vincular o banco e o retorno cnab para cada conta homologada do extrato.


    Nesta tela, é necessário se atentar em alguns campos:


    Dia Liquidação: se refere à data que irá considerar no extrato, quando há movimentos do dia anterior. Nesses casos, geralmente cadastra como -1 e valida no Resumo Bancário da conciliação de extrato se o valor inicial do saldo está correto.


    Data para início da conciliação: Data em que irá considerar para início da conciliação das ações automáticas.

    Dia conciliação: dia em que irá considerar para início da conciliação das ações automáticas. Considera o menor entre a data para início da conciliação e dia conciliação.


    Nas configurações de lançamento, pode deixar habilitado apenas o que o cliente utiliza como padrão de preenchimento.



    5.6 Cadastrar configurações de DDA


    O cadastro das configurações de DDA, se refere à leitura do arquivo de DDA para disponibilizar as linhas na conciliação. Obrigatoriamente, tem que ter um único banco por empresa.


    Aqui tem duas validações:


    Conciliação Automática: São os campos que o InnCash irá considerar para montar o par com o ERP. Por padrão, colocamos tolerância de valor 0,00,  tolerância de vencimento 0, considera nº título não e somente considera raiz do CNPJ. No campo tipos para ignorar, é caso o cliente queira que algum e2_tipo (da tabela de contas a pagar) não apareça na tela para montar o par.

    Conciliação Manual: por padrão definimos tolerância de valor 10,00, tolerância de vencimento 5, considera nº do título não e apenas raiz do CNPJ. Esses são os casos que o InnCash monta uma pré conciliação para o cliente conciliar manualmente as divergências.


    Alguns clientes utilizam filiais no DDA e o banco nos retorna tudo em um único arquivo. No entanto,  é necessário fazer uma configuração para cada título ler em sua filial:


    • Nas configurações de segmentos cnab ter cadastrado no segmento G um campo chamado cnpj_agregado
    • Na tabela company_configurations o campo dda_use_cnpj_from_segment deve estar como 1
    • Na tabela dda_aggregate_company deve ter uma linha que faça referência ao código da empresa company_id e o código do banco bank_code


    5.6 Cadastrar configurações de API

    O primeiro passo é solicitar as credenciais aos bancos.


    Santander: https://drive.google.com/file/d/1LxPbVD9SIidOEKnqJrMkIB_FPQM_hkYN/view?usp=drive_link

    Solicitar ao cliente que entre com o usuário master, vai em Aplicação via Parceiros – Nova Aplicação – Procura o InnCash.

    Itaú: solicitar via email para o gerente abrir a demanda. Solicitar que a equipe técnica gere um certificado público com base no CNPJ e no company. Envia o email com a chave para o banco, em seguida o Itaú vai enviar um token com expiração de 7 dias, no qual é enviado para a equipe técnica finalizar as configurações.

    Bradesco: solicitar as credenciais via portal.

    Banco do Brasil: solicitado via portal. O cliente precisa acessar com o usuário master: https://app.developers.bb.com.br/#/

    Após a geração das credenciais, realizamos o cadastro na tabela fluxocaixa.api_banking_credential. Analisar o tipo da API se é C (company) ou G (company_group). E vincular o client_id, client_secret , client_basic_token e url_param quando houver. Nesta etapa, pode criar a atividade no Artia para a equipe realizar o cadastro do usuário no InnPay.


    Para configuração dos campos da configuração de API, é necessário copiar de um outro cliente e ajustar as informações de juros, multa, protest, conta, agência e convênio.



    6 TESTES



    6.1 Fluxo Previsto


    6.1.2 Testes do Fluxo Previsto no Contas a Receber

    Gera o fluxo previsto na tela e escolher um título para realizar as alterações abaixo:


    • Alteração de Vencimento: por padrão alteramos o campo e1_zdtflux, mas é configurável. Caso o cliente queira alterar o e1_vencto, podemos pedir para fazer um de/para no integrador.
    • Inclusão de Acréscimo/Decréscimo: alterar um valor para cada item e conferir nos campos e1_acresc e e1_acresc
    • Incluir comentário: Essa parte não integra, fica apenas no fluxo previsto.
    • Alterar forma de recebimento: por padrão colocamos apenas boleto, mas o cliente pode querer realizar mais cadastros e alterar no e1_zforrc.
    • Visualizar detalhes: validar as informações do título e o log de alteração.
    • Alterar valor: preenche no campo e1_zvalinn. Importante saber que esse campo não muda o saldo do título.

    6.1.2 Testes do Fluxo Previsto no Contas a Pagar


    Gera o fluxo previsto na tela e escolher um título para realizar as alterações abaixo:


    • Alteração de Vencimento: por padrão alteramos o campo e2_zdtflux, mas é configurável. Caso o cliente queira alterar o e2_vencto, podemos pedir para fazer um de/para no integrador.
    • Inclusão de Acréscimo/Decréscimo: alterar um valor para cada item e conferir nos campos e2_acresc e e2_acresc
    • Incluir comentário: Essa parte não integra, fica apenas no fluxo previsto.
    • Alterar forma de pagamento: realizar as alterações conforme os cadastros das formas de pagamento e conferir no campo e2_zforpg.
    • Alterar dados bancários: realizar a alteração dos dados bancários no cadastro do fornecedor: a2_cod, a2_agencia, a2_dvage, a2_numcon, a2_dvcta e a2_tipcta.
    • Visualizar detalhes: validar as informações do título e o log de alteração.
    • Alterar valor: preenche no campo e2_zvalinn. Importante saber que esse campo não muda o saldo do título.

    6.2 Remessa de Pagamento

    • Alterar forma de pagamento: escolher entre as opções cadastradas na plataforma e validar o campo e2_zforpg. Se selecionar o campo para alterar também no fornecedor, irá alterar no a2_zforpg.
    • Editar: no editar, irá realizar a ação conforme a forma de pagamento escolhida: 
    • Boleto: irá realizar a alteração da linha digitável (e2_codbar).
    • Boleto Outro Beneficiário: irá realizar a alteração da linha digitável (e2_codbar) e a outra titularidade (e2_znome e e2_zcgc).

    • Concessionária: para os casos de faturas de internet, água, luz. irá realizar a alteração da linha digitável (e2_codbar).
    • DARF (S/ Cod Barras): irá preencher os campos e2_zdocrec, e2_znumref, e2_zperiod, e2_zcodrec e e2_zvlent.
    • GPS (S/ Cod Barras): irá preencher os campos e2_zdocrec, e2_znumref, e2_zperiod, e2_zcodrec e e2_zvlent.
    • Pix: há três opções de chave: CNPJ/CPF, telefone (precisa iniciar com +55 e o DDD) e email. Irá preencher os campos a2_tippix e e2_zchvpix.
    • Pix Outra Titularidade: há três opções de chave: CNPJ/CPF, telefone (precisa iniciar com +55 e o DDD) e email. Irá preencher os campos a2_tippix e e2_zchvpix e a outra titularidade (e2_znome e e2_zcgc).
    • TED: Irá preencher os campos a2_cod, a2_agencia, a2_dvage, a2_numcon, a2_dvcta e a2_tipcta.
    • TED Outra Titularidade: Irá preencher os campos a2_cod, a2_agencia, a2_dvage, a2_numcon, a2_dvcta e a2_tipcta e a outra titularidade (e2_znome e e2_zcgc).
    • Impostos: irá realizar a alteração da linha digitável (e2_codbar).
      • Incluir acréscimo/decréscimo: alterar um valor para cada item e conferir nos campos e2_acresc e e2_acresc
      • Incluir comentário: Essa parte não integra, fica apenas no fluxo previsto.
      • Visualizar detalhes: validar as informações do título e o log de alteração.
      • Alterar valor: preenche no campo e2_zvalinn. Importante saber que esse campo não muda o saldo do título.
      • Alteração de Vencimento: por padrão alteramos o campo e2_zdtflux, mas é configurável. Caso o cliente queira alterar o e2_vencto, podemos pedir para fazer um de/para no integrador.
    • Gerar fatura: ao selecionar um ou mais títulos, gera um único título com o valor agrupado. Essa parte não integra no InnCash, só precisa validar se está funcionando.
    • Gerar Remessa de Pagamento: Para o teste, pode habilitar nas configurações bancárias a transação “Download em Tela”.  Nessa etapa, pode validar a geração do borderô (e2_numbor).
    • Envio ao Banco: após as liberações bancárias, é necessário testar cada conta contratada pelo cliente. É necessário ajustar a transação nas configurações bancárias conforme a Van do cliente. Após isso, solicitar ao cliente um título teste e gerar a remessa enviando ao banco. Acompanhar o tráfego do arquivo e validar se iremos receber o retorno na pasta da Van.

    6.3 REMESSAS ENVIADAS


    Nessa tela, irá listar todos os borderôs enviados ao banco.

    Na opção de Retorno Bancário, irá listar a ocorrência de cada título. Para que isso aconteça, é necessário cadastrar a leitura automática:


    • cnab_directory_configuration: duplicar a última linha feita e ajustar o id da configuração de acordo com a ordem. Incluir o id do company que está sendo configurado, o id da van e o status para T. Colocar o caminho da pastinha que pegará do filezilla. Verificar se o arquivo é 400 ou 240 e a posição em que fica o código do banco (cod do banco vai ser do 1 ao 3 ou do 77 ao 79).


    • cnab_bank_configuration duplicar a linha e buscar pelo banco e tipo da conta. Confirmar as posições de banco (initial_bank_code e final_bank_code), agência (initial_bank_agency e final_bank_agency), dígito da agência (initial_bank_agency_digit e final_bank_agency_digit), conta (initial_bank_account e final_bank_account) e dígito da conta (initial_bank_account_digit e final_bank_account_digit). Caso o cliente utilize convênio, pode preencher as posições de banco e convênio (initial_bank_insurace e final_bank_insurace) no arquivo de acordo com o cadastro de bancos da tabela do cliente. Trocar company id e company group.
    • bank_config_send_type: nas configurações bancárias, vincular o retorno na transação da conta.

    Após os cadastros, incluir o arquivo manualmente no menu de “Retorno Bancário” e acompanhar a leitura na cnab_files e cnab_bank_transaction.


    Nesta tela, também é possível gerar os comprovantes. No momento da baixa, é necessário Validar se o comprovante está lendo corretamente.


    6.4 CONCILIAÇÃO DE DDA

    Após a leitura dos arquivos, iremos realizar algumas ações na linha de DDA:


    • Gerar Fatura: ao selecionar um ou mais títulos, gera um único título com o valor agrupado. Essa parte não integra no InnCash, só precisa validar se está funcionando.
    • Procurar título: essa é uma conciliação manual de DDA. É necessário validar se o campo e2_codbar foi preenchido.
    • Gerar Título a Pagar: incluir um título de PR. Esse título integrará no sistema, então é necessário questionar o cliente se integrou e contabilizou.

    6.5 REMESSA DE COBRANÇA


    • Após a configuração da API e as credenciais funcionando, solicitamos ao cliente um título de teste. Precisamos validar com ele se utiliza a geração do boleto pelo Protheus ou pelo banco.
    1. Se for pelo Protheus: o cliente precisa gerar o boleto e preencher o nosso número. Obrigatoriamente precisa ficar fora de borderô, se o processo for gerar o boleto e colocar direto em borderô, é necessário ajustar ou trocar para gerar o nosso número pelo banco. Se for pelo cliente, o campo invoice_generator na company_configurations precisa estar como SELF.*
    2. Se for pelo banco: tem a opção de gerar o nosso número pelo banco, ou seja, precisa pedir para o banco trocar o tipo de carteira para banco numera, cliente emite e expede, ou então, gerar pelo InnCash. Se for pelo banco, o campo invoice_generator na company_configurations precisa estar como BANK. Se for pelo InnCash, mantém o campo como BANK e ajusta o campo must_create_our_number na bank_config para 1.**

    *Tem duas opções: ou altera para o company inteiro, ou altera na bank_config para apenas uma conta. Ele irá considerar primeiro o da bank_config, se tiver em branco, considera o da company_configurations.

    **Irá pegar o sequencial do nosso número pela artificial_bordero_links. Caso não tenha nenhum envio ainda, é possível colocar o sequencial na tabela bank_config no campo our_number_sequential_to_start, respeitando os caracteres do banco.



    • Após o envio do título e as configurações de nosso número, enviamos ao banco para registro. No registro precisa preencher todos os campos levantados no Kickoff pelo levantamento de requisitos.
    • Após o registro, o cliente efetua o pagamento do boleto e precisamos configurar a baixa:
    1. cnab_directory_configuration: duplicar a última linha feita e ajustar o id da configuração de acordo com a ordem. Incluir o id do company que está sendo configurado, o id da van e o status para T. Colocar o caminho da pastinha que pegará do filezilla. Verificar se o arquivo é 400 ou 240 e a posição em que fica o código do banco (cod do banco vai ser do 1 ao 3 ou do 77 ao 79).
    2. cnab_bank_configuration duplicar a linha e buscar pelo banco e tipo da conta. Confirmar as posições de banco (initial_bank_code e final_bank_code), agência (initial_bank_agency e final_bank_agency), dígito da agência (initial_bank_agency_digit e final_bank_agency_digit), conta (initial_bank_account e final_bank_account) e dígito da conta (initial_bank_account_digit e final_bank_account_digit). Caso o cliente utilize convênio, pode preencher as posições de banco e convênio (initial_bank_insurace e final_bank_insurace) no arquivo de acordo com o cadastro de bancos da tabela do cliente. Trocar company id e company group.
    3. bank_config_send_type: nas configurações bancárias, vincular o retorno na transação da conta.

    6.6 REMESSA DE INSTRUÇÕES


    É solicitado um título teste ao cliente e registrado via API bancária.
    Algumas validações necessárias: 

    • Acessar a bank_config e definir o campo has_instructions para 1.
    • Verificar se o campo e1_zforrc está preenchido com 001.
    • Na tabela api_banking_field_detail, preencher o campo update_data_field com uma fórmula que formate o nosso número. Fazer essa mudança apenas no campo do data_field que se refere ao  nosso número.

    Na remessa temos as seguintes opções:

    1. Alteração de Data: é necessário alterar a data do título na tela de fluxo previsto, onde irá gerar a instrução em tela.
    2. Alteração de Juros: é necessário alterar o acréscimo do título na tela de fluxo previsto, onde irá gerar a instrução em tela.
    3. Alteração de Desconto: é necessário alterar o decréscimo do título na tela de fluxo previsto, onde irá gerar a instrução em tela.
    4. Baixa de Título: remover o título de borderô ou pedir para o cliente colocar em carteira dentro do Protheus.

    Todas as instruções realizadas nos títulos ficam gravadas na tabelas instrucoes_cobrancas do banco do cliente.


    6.7 CONCILIAÇÃO DE EXTRATO

    Após a leitura do arquivo, os testes necessários são:

    • Lançamento de tarifa: em uma linha de débito do extrato, é necessário ir à opção do movimento e adicionar uma nova movimentação bancária. Os parâmetros confirmamos com o cliente o que é obrigatório e o valor de cada um (natureza, centro de custo, item contábil e classe de valor). Após o lançamento, solicitar ao cliente a validação e a contabilização do movimento dentro do ERP.

    • Transferência bancária: em uma linha de débito do extrato, é necessário ir à opção do movimento e adicionar uma nova movimentação bancária. Precisa alterar o campo “Realizar Transferência Bancária”  para sim e confirmar com o cliente a conta de destino e a informação da natureza. Observação: alguns clientes irão utilizar uma natureza para cada movimento da transferência (débito e crédito), se for esse o caso, precisa alterar na configuração de conciliação bancária o campo para lançamento da natureza de débito. Após o lançamento, solicitar ao cliente a validação e a contabilização do movimento dentro do ERP.
    • Procurar Movimentação Bancária: realizar uma conciliação manual e validar se a integração ficou correta.
    • Gerar Adiantamento: Essa opção irá aparecer somente quando for uma linha de crédito. Os parâmetros confirmamos com o cliente o que é obrigatório e o valor de cada um (natureza, centro de custo, item contábil e classe de valor). Após o lançamento, solicitar ao cliente a validação e a contabilização do movimento dentro do ERP.
    • Baixa de Título a Receber: Essa opção irá aparecer somente quando for uma linha de crédito. Solicitamos ao cliente um título que possamos realizar a baixa por aqui. Após o lançamento, solicitar ao cliente a validação e a contabilização do movimento dentro do ERP.

    Importante: validar o saldo inicial e final da coluna do banco na tela de Resumo Bancário.


    6.8 FOLHA DE PAGAMENTO

    Após a configuração da Van, solicitamos um arquivo para o cliente. O arquivo bancário continua sendo feito pelo Protheus e dentro do InnCash terá apenas o tráfego do arquivo.

    Na tela de Folha de Pagamento, vinculamos o título na opção em tela, colocamos os dados da conta e enviamos ao banco.

    No retorno do arquivo, disponibilizará na mesma tela de Folha de Pagamento, junto com o comprovante.

    Para configurar o retorno:

    1. cnab_directory_configuration: duplicar a última linha feita e ajustar o id da configuração de acordo com a ordem. Incluir o id do company que está sendo configurado, o id da van e o status para T. Colocar o caminho da pastinha que pegará do filezilla. Verificar se o arquivo é 400 ou 240 e a posição em que fica o código do banco (cod do banco vai ser do 1 ao 3 ou do 77 ao 79).
    2. cnab_bank_configuration duplicar a linha e buscar pelo banco e tipo da conta. Confirmar as posições de banco (initial_bank_code e final_bank_code), agência (initial_bank_agency e final_bank_agency), dígito da agência (initial_bank_agency_digit e final_bank_agency_digit), conta (initial_bank_account e final_bank_account) e dígito da conta (initial_bank_account_digit e final_bank_account_digit). Caso o cliente utilize convênio, pode preencher as posições de banco e convênio (initial_bank_insurace e final_bank_insurace) no arquivo de acordo com o cadastro de bancos da tabela do cliente. Trocar company id e company group.
    3. bank_config_send_type: nas configurações bancárias, vincular o retorno na transação da conta.

    6.9 MÓDULO DE COBRANÇA


    Caso o cliente já possua as APIs contratadas para o registro de boletos padrão, não será necessária nenhuma configuração adicional.

    Caso não possua, deverá ser realizado o processo de configuração da API, conforme descrito no item 6.5.


    Após a conclusão dos cadastros, é necessário efetuar o vínculo dos operadores. Para isso, acesse o menu “Distribuição de Operadores” e conceda acesso ao módulo aos usuários solicitados.


    Regras para cadastro:

    • O operador precisa ter acesso ao módulo de cobrança;
    • A quantidade de dias em atraso, valor total e saldo total dos títulos é o máximo que ele irá conseguir ver. Caso não tenha limite pode colocar um valor alto.
    • Durante a ausência temporária, pode cadastrar um outro usuário para ter as mesmas permissões dele, sem necessidade de inativar ou cadastrar um novo.

    Realização de testes:

    • Na listagem de pendências, executar pré-negociações, alteração de data de vencimento e ajuste de juros.
    • Pré negociação: irá gerar novos títulos com base nos selecionados. Exemplo:


    • Definir a quantidade de parcelas. Aqui é possível também realizar a alteração da porcentagem dos juros.

    • Essa ação irá gerar novos títulos e enviar ao Protheus. Os títulos antigos serão baixados e substituídos por esses. 


    • No fim desse processo, também é possível fazer o envio direto do boleto ao banco.

    • Alteração de data: Irá alterar o vencimento do título 
    • Ajuste de juros: irá incluir juros no título (e1_acresc).

    • Na aba “Contatos” e “Inf. Complementares”, é necessário validar se os campos de telefone, e-mail e observações estão sendo gravados corretamente. Essa ação irá alterar os cadastros dentro do Protheus.

    • No menu “Clientes” também é possível realizar as mesmas alterações que na “Listagem de Pendências”. 

    No “Histórico de Cobrança” é possível criar uma interação. Essa ação geralmente é utilizada quando tem o contato com o cliente (por telefone, por exemplo) e deseja colocar o histórico conversado por ali. Essa ação não integra no ERP.