Histórico da Página

Inclusão de Nota Fiscal nos processos de envio de XML ou geração de PEG manual via Portal do Prestador

Informações Gerais

Objetivo

A presente especificação visa detalhar as regras e procedimentos necessários para a inclusão da Nota Fiscal (seja um arquivo XML da NF-e, RPA - Recibo de Pagamento a Autônomo ou scan/foto da Nota Fiscal), de forma que possamos associar esta nota aos protocolo e lotes gerados posteriormente pela rotina de pagamento do Plano de Saúde, permitindo uma rápida integração entre os setores operacionais da Operadora e a rápida visualização da Nota Fiscal, permitindo solicitar quando não houve anexos deste documento, bem como solicitar a troca por uma nova nos casos de erros ou glosas no processo, tornando a dinâmica mais rápida e a comunicação mais eficaz entre a Operadora e seus Prestadores.

Definição da Regra de Negócio

O processo de incluir a Nota Fiscal pelo Portal do Prestador visa torna mais rápida e eficaz a comunicação entre Operadora e Prestador, facilitando a gestão do prestador no tocante  ao envio da Nota Fiscal (NF) durante o envio do XML ou durante a geração manual do Protocolo de Entrega de Guias (PEGs) de diversas formas, como:

• Inclusão do XML da NF;
• Inclusão da imagem/scan da Nota Fiscal (nota emitida pelas Prefeituras ou bloco manual);
• Digitação manual da RPA - Recibo de Pagamento Autônomo, quando o prestador for pessoa física.
  
  

Definições primárias:

1. A funcionalidade abaixo descrita só será ativada caso o parâmetro MV_NEWDFC esteja ativo, com valor verdadeiro (.T.). Caso contrário, as rotinas envolvidas irão funcionar da maneira normal. Ou seja, as rotinas existentes deverão manter o seu legado de funcionamento, não devendo nada ser alterado para as Operadoras que não desejarem utilizar a nova cobrança.
   Caso as alterações necessárias sejam profundas com relação as existentes, criar novos fontes, dividindo o legado da nova funcionalidade.
2. Caso ocorra integração com sistema de leitura de Arquivo de XML da Nota Fiscal Eletrônica, as partes onde o prestador deveria entrar com algumas informações da Nota Fiscal de forma manual, será feito de forma automática, sem a necessidade de interação do prestador.
3. Será necessário bloquear os campos para edição no Pré_nota do módulo de Compras, quando a Pré-Nota for proveniente do Portal do Prestador, pois hoje, ao acessar a Pré-Nota, podemos alterar todos os campos. Logo, será necessário verificar a questão do bloqueio da pré_nota de acordo com a origem quando vier do PLS.

Regras de Negócio - Pessoa Jurídica/Física (Envio de XML ou Nota de Bloco Manual)

1. Prestador acessa o Portal do prestador, com seu login e senha;
2. Acessa a opção Portal TISS / Upload XML TISS (fonte PPLCHAIMP);
3. Realiza o upload do arquivo para o servidor:
   1. Aqui, o XML deverá ser validado com regras de precificação, schemas da TISS e demais pertinentes no processo de upload do XML;
4. Após verificação do XML, deverá ser exibido para o usuário se o XML está acatado ou não:
   1. Deverá ser criado na opção de Motivos de críticas (tabela BCT) um campo para informar que a crítica não impede o processamento do XML e que é apenas Informativa. Deverá ser visto em que frente ou processo será estabelecido esta mudança, pois por exemplo, pode existir diferenças de valores (como valor contratado e o valor apresentado) e o sistema deve apenas alertar sobre o caso, não impedindo que o processo continue. 
   2. Se o XML estiver certo ou só contiver mensagens de alerta (após solução das críticas apenas de alerta no item acima), deverá ser informado no grid dos XML’s processados o valor total do XML enviado, para que o Prestador verifique o total. 
   3. O grid onde são apresentados os resultados do XML deverão possuir novas colunas, que são:
      1. Valor total das guias do XML;
      2. Cadastrar Documento Fiscal, que será um botão, para abrir uma nova tela;
      3. Número do Documento Fiscal. 
   4. Porém deverá existir fora do grid um campo de total dos XMLs enviados, para consulta do prestador, onde o valor exibido será a somatória do valor de cada XML enviado.
5. O prestador poderá realizar o upload de quantos XMLs desejar, de acordo com sua demanda;
6. O sistema deve verificar se no cadastro da RDA consta a obrigatoriedade de enviar a Nota Fiscal junto ao XML (campo BAU_OBRDFC):
   1. Se sim, o botão do campo Cadastrar Documento Fiscal deverá ficar visível e o status do protocolo será Acatado - Aguardando DFC;
   2. Devido ao novo status  - Acatado - Aguardando NF - será necessário alterar os fontes PLSA974 (com a inclusão de uma nova legenda e cor) e PLROBOTXML, que deverá ser alterado para que não processe os arquivos XML que estiverem neste status de Acatado - Aguardando NF (BXX_STATUS) da tabela BXX - Importação de XML.
      1. Criar um novo campo na tabela BXX, campo BXX_STSDFC, para registrar o status do envio da NF, para diferenciar posteriormente quais prestadores enviaram ou não o Documento Fiscal.
      2. Todos os fontes que envolvem o campo BXX_STATUS deverão ser revistos, em função deste novo status de obrigatoriedade, onde o arquivo está validado, mas não pode ser importado enquanto não houver inclusão da Nota Fiscal se a RDA é obrigada a enviar.
      
      
7. Caso o prestador deseje anexar a NF, mesmo que seja uma nota para cada XML (um-para-um) ou uma nota para vários XMLs (um-para-vários), o funcionamento será conforme abaixo:
   1. Ao clicar no botão Cadastrar Nota Fiscal, deverá ser aberta uma nova janela de Inclusão de Nota Fiscal (criar fonte PPLINCNFR), onde o prestador deverá proceder com as seguintes ações:
      1. Adicionar manualmente algumas informações sobre a NF (criar campos no PPLINCNFR conforme item B abaixo);
      2. Anexar o XML da nota Fiscal Eletrônica ou (criar campo de submissão de  arquivos);
      3. Adicionar uma imagem da NF; 
      4. O prestador poderá escolher se deseja enviar o XML da NF ou imagem, conforme itens ii e iii acima.
      
   2. Os campos que deverão ser preenchidos pelo prestador nesta tela de cadastro de Nota Fiscal (em decorrência da Pré-Nota que será utilizada no processo, que encontra-se no módulo de Compras) são:
      1. Número da Nota Fiscal (campo F1_DOC - Número da Nota Fiscal - Tabela SF1);

      2. Série da Nota Fiscal (campo F1_Serie – Série da Nota);

      3. Data de Emissão da Nota Fiscal (campo F1_EMISSAO – Data de Emissão);

      4. Estado de Emissão da Nota Fiscal (campo F1_EST – Estado de emissão);

      5. Valor Bruto da Nota Fiscal (campo D1_TOTAL – Valor bruto da NF e deve ser inserido também no campo  D1_VUNIT);

      6. Código de verificação da Nota Fiscal Eletrônica - F1_CODNFE 

      7. OBS: Caso o Prestador seja Pessoa Física, ao invés dos campos acima descritos, deverá ser exibido a tela de cadastro da RPA - Recibo de Pagamento a Autônomo.

   3. Importante: Da geração da pré-Nota, além dos campos acima onde o usuário irá preencher estes dados, de acordo com a nota, é necessário internamente preencher os seguintes dados, para que a Pré-Nota seja gerada corretamente, que são:
      1. Fornecedor - campo F1_FORNEC. Este dado é o código do fornecedor, que é diferente do código da RDA. O campo número do fornecedor fica no campo BAU_CODSA2;
      2. Loja - F1_LOJA. Esta dado é obtido do campo BAU_LOJSA2;

      3. Condição de pagamento - F1_COND. Será necessário pegar este valor do cadastro de fornecedores e fica localizado no campo A2_COND;

      4. Data de Digitação - D1_DTDIGIT. É a data de inclusão da Pré-Nota; 

      5. Quantidade do produto/Serviço - D1_QUANT. Colocar o valor 1;

      6. A natureza é proveniente do Cadastro de Fornecedor – A2_Natureza

      7. Código do Produto / Serviço - D1_COD. No PLS, usar a informação do campo BLR_CODPRO.

   4. Quando o prestador clicar no botão Confirmar, deverá ser exibido uma caixa (usar modalBs, presente no arquivo jspls.js) para que o Prestador possa associar esta nota inserida com o XMLs enviados. Aqui, ele pode associar uma nota para um XML enviado ou uma Nota para vários XMLs. Ou seja, posso enviar 5 XMLs que juntos dão o valor de R$ 2.000,00 e gerar uma única NF neste valor. 

      

   5. Adicionar novo campo na tabela BXX (BXX_CODDFR), que irá armazenar de forma consecutiva os campos Número da Nota + Série +Fornecedor +Loja, para identificar quais XMLs estão atrelados a este Documento Fiscal. 

8. Quando o prestador clicar no botão Confirmar da página, o sistema deve atualizar o status do arquivo XML na tabela BXX, passando de Acatado - Aguardando NF para apenas Acatado, de forma que o robô possa realizar a importação e processamento destes dados posteriormente e atualizar o campo BXX_STSDFC. Se o prestador realizou o upload do arquivo (XML ou imagem), o campo BXX_STSDFC ficará com o valor "3" Enviado. 
   
   1. Quando o robô é executado, gera a PEG, criando um registro na Tabela BCI - Protocolo de Entrega de Guias, de acordo com os dados do XML.
      1. Devido a necessidade de caracterizar se a PEG está com o Documento Fiscal anexado ou digitado (quando RPA), quando está faltante ou necessita de troca, será necessário criar um novo campo na Tabela BCI - Protocolo de Entrega de Guias, para caracterizar e realizar esta filtragem. O campo será BCI_STSDFC. 
   2. A PEG gerada pelo robô deverá constar com o status 1 - Recebido, conforme Tabela 47 - Terminologia de status da guia e do protocolo da TISS.
      1. A função  PLRETSTISS é a função responsável em realizar o De/Para dos status dos protocolos do sistema com os status da TISS de forma correta. Esta função deverá ser alterada adiante, para contemplar novos status.
      2. Além de gerar com o status conforme TISS, o robô deverá preencher o campo BCI_STSDFC com o valor do campo BXX_STSDFC, para caracterizar se o Documento Fiscal foi adicionado ou não no Processo.
   3. O sistema irá gerar a Pré-Nota no Módulo de Compras, com os dados informados pelo usuário nos campos da tela e irá adicionar ao Banco de Conhecimento da tabela SF1 os arquivos subidos pelo usuário, ou seja, o XML da NF eletrônica ou a imagem desta Nota.
      1. Verificar a possibilidade de incluir Banco de Conhecimento direto na tela de Digitação de Guias do PLS, de forma que lá também tenhamos réplica destes arquivos.
   4. Para gerar a Pré-Nota (Fonte MATA140), pode-se utilizar o MsExecAuto da função MATA140. Os seguintes fontes contêm o MSExecAuto para a geração da Pré-Nota:
      1.  fonte ACDV125;
      2. fonte LOJA701C;
      3. fonte GFEA065.
   5. OBS: A Pré-Nota somente será criada quando o prestador inserir uma Nota Fiscal no Portal. Caso contrário, não será criado a Pré-Nota
9. Será necessário criar uma rotina de JOB para efetuar a importação de forma automática para o Protheus, sem a necessidade do usuário acessar o Gerenciador de XML, selecionar o arquivo XML e realizar a importação. Esse JOB deve ser criado com esta finalidade, a fim de realizar a importação automática para o sistema sem interação do usuário.
   1. De acordo com a tabela BXX - Importação XML, será necessário verificar quais registros estão com status de Acatado = "1" (BXX_STATUS) e o campo Envio pelo Portal = "1" (BXX_TPNFS)
   2. No fonte PLSA974 temos a rotina de Gerenciador de XML. 
   3. A função que executa a importação das guias para a PEG gerada no fonte PLSA974 é a rotina PLSPPXML, que depois invoca as demais funções para importação (PLSPRXML -> PROCTISS e outras) para que as guias sejam importadas no sistema para a PEG gerada.
   4. Desta forma, será necessário verificar qual foi a PEG gerada pelo Robô e em seguida, importar as guias do XML para esta PEG de forma automática.
   5. Este job deverá ser configurável pelo Schedulle do Protheus, de acordo com as necessidades do cliente.
   6. Após o término da importação das guias para a PEG correta, a PEG deverá ficar com o status 2 - Em Análise, conforme status da TISS.
   7. Criar novo campo na tabela BCI (BCI_CODDFR), que irá receber o valor do campo BXX_CODDFR, para associar a Pré_nota com esta PEG. 
10. Os operadores do Contas Assistenciais irão realizar as análises de acordo suas diretrizes.
11. Caso a PEG e suas guias estejam corretas e o Documento Fiscal Anexado e também correto, o operador irá liberar a PEG (Mudança de Fase) com o status 3 - Liberado para pagamento, onde o ao gerar os lotes de Pagamento deverá ser considerado este status (a função PLRETSTISS não contempla este status. Logo, será necessário realizar o De/Para do sistema para realizar a troca para o status correto).
    1. O método de Mudança de fase hoje terá que ser alterado, devido aos status aqui mencionados e de forma que fique fácil para o operador selecionar para qual fase a guia será mandada. 
       1. Poderia ser exibido um campo do tipo combo, onde o usuário escolheria o status conforme sua necessidade e após escolha, o sistema pedir a confirmação (MSGYESNO) de que o status está certo;
       2. Exibir um alerta com as opç~eos e o operador seleciona a fase que atende a guia, sempre perguntando no final do processo se a escolha está correta.
12. Caso na análise seja constatado que falte o anexo do Documento Fiscal (pois a RDA pode não ser obrigada a enviar o Documento Fiscal no envio do XML, conforme campo BAU_OBRDFC) ou exista glosa, a PEG será liberada com o status 5 - Analisado e aguardando liberação para o pagamento, onde o ao gerar os lotes de Pagamento deverá ser considerado este status (a função PLRETSTISS não contempla este status. Logo, será necessário realizar o De/Para do sistema para realizar a troca para o status correto).
13. Quando a PEG estiver sem o Documento Fiscal, o sistema deve enviar um e-mail solicitando ao Prestador a inclusão da NF no Portal (os e-mails deverão utilizar as diretrizes do item Regras de Negócio - Cadastro e envio de E-mail)
    1. O e-mail deverá constar algumas das informações da PEG e deverá ter o link para o Portal, se possível, para a nova tela de Gerenciamento de Documentos Fiscais (incluir no RUP_PLS a entrada do novo menu no Portal do Prestador, dentro do menu Portal TISS)
    2. A nova tela de Gerenciamento de Documentos Fiscais (fonte PPLINCDF), será o meio onde o prestador irá realizar a troca de NF (nos casos de glosas ou a NF contiver algum erro) ou anexar a NF quando não for obrigatório no Processo. 
       Esta tela deverá permitir a pesquisa por Data Inicial e Data Final, além de filtrar pelos tipos de pendência (Pendente de NF, Troca de NF ou Ambos), sendo que abaixo deverá ter um grid com os dados encontrados, conforme layout abaixo. Essa pesquisa é proveniente da Tabela BCI e só serão exibidos as PEGs que estiverem no status 5 - Analisado e aguardando liberação para o pagamento. O grid deverá exibir:
       1. Exibir as PEGs encontradas, com os parâmetros informados;
       2. Exibir o status da PEG com relação ao Documento Fiscal;
       3. Exibir o Valor da PEG;
       4. Exibir o número do Documento Fiscal (caso tenha sido incluída anteriormente);
       5. Exibir o campo número da Nova Nota Fiscal (caso seja troca);
       6. Exibir botão para adicionar o novo Documento Fiscal ( que deverá encaminhar para a tela PPLINCNFR) .
          
          
    3. Tanto para inclusão do Documento Fiscal faltante quanto para a troca esta será a tela de gerenciamento geral. Quando pressionar o botão Incluir Nota Fiscal, o sistema irá abrir a tela de Inclusão de Nota Fiscal (fonte PPLINCNFR) e submeter o arquivo XML ou scan da nota e preencher as informações obrigatórias, conforme parágrafo 7, item B.
    4. Se o status do campo BCI_STSDFC for "1" - Documento Fiscal Pendente - ou seja, não foi adicionado - o sistema deverá seguir os mesmo procedimentos que ocorrem no parágrafo 7, do item B ao D e no final, salvar no campo BCI_CODDFR o número do Documento Fiscal inserido no sistema para as PEGs que foram associadas ao Documento Fiscal. 
       1. • Após a inclusão do Documento Fiscal pelo Prestador no Portal, será gerada a Pré-Nota no sistema.
          • O sistema terá que atualizar o status da PEG de 5 - Analisado e aguardando liberação para 3 - Liberado para pagamento.
            
14. No casos onde ocorreram Glosas, o sistema deve enviar um e-mail ao prestador, solicitando a troca do Documento Fiscal por um novo, de forma  que seja possível detalhar o novo valor bruto pelo qual a nova nota deve ser geradae demais informações pertinentes que a Operadora quiser colocar no e-mail.
    1. O e-mail deverá constar algumas das informações da PEG e deverá ter o link para o Portal, se possível, para a nova tela de Gerenciamento de Documentos Fiscais.
    2. Se o status do campo BCI_STSDFC for de Troca de Documento Fiscal, o sistema irá trabalhar da seguinte maneira:
       1. • A tela de inclusão irá funcionar da mesma maneira, ou seja, terá que entrar com os dados obrigatórios na tela e subir o arquivo XML da NF ou imagem.
          • No final do processo, deverá ser exibido a modalBs (presente no arquivo jspls.js) mostrando todas as PEGs que estão atreladas ao Antigo Documento Fiscal e informar que na atualização, a nova Nota inserida será atualizada para estas PEGs.
          • Caso clique em Confirmar, o sistema deverá atualizar o campo BCI_CODDFR com o novo número gerado.
          • A Pré-Nota existente deverá ser cancelada ou deletada;
          • Gerar uma nova Pré-Nota com os dados informados (para efeitos de histórico, transferir o XML da NF ou imagem da pré-nota cancelada para a nova nota no Banco de Conhecimentos)
          • O sistema terá que atualizar o status da PEG de 5 - Analisado e aguardando liberação para 3 - Liberado para pagamento.
15. Quando a operadora for realizar o processo de Geração de Lotes de Pagamento (fonte PLSA470), o Pergunte exibido deverá ser alterado, para que conste as seguintes informações, devido ao novo processo:
    1. Campo para Seleção da RDA - F3;
    2. Campo para digitar o Número da Nota;
    3. Campo para digitar a Série da Nota;
    4. Campo para seleção do Fornecedor - F3.
       
       
       
16. Após a seleção destes parâmetros, o sistema deverá pesquisar quais PEGs se encaixam nestas características (as PEGs deverão estar com o status 3 - Liberado para Pagamento)  e trazer em tela, conforme funciona hoje.
17. Será necessário alterar o fluxo da rotina de geração de Lotes de Pagamento do PLS - PLSA470 - para que ela gere todas as tabelas auxiliares no processo, mas que não gere os títulos na SE2, pois isso será gerado via Documento de Entrada, que é a cópia da Pré-Nota, pois estrá de acordo coma nota inserida no sistema pelo prestador.
    1. Durante o processamento do lote de cobrança pelo PLS, a função ProcTite será a responsável em gerar o título para o prestador.
       1. Durante o processamento da ProcTite, é chamado a função PLGERCRE (fonte PLSMPAG). Aqui, devemos passar para a função os valores do campo BCI_CODDFR, de acordo com a chamada da função, pois é necessário passar número do título, série, fornecedor e outros, sendo necessário passar o correto.
       2. Na função PLGERCRE, temos a chamada da função PLStoSE2 (fonte PLSTOSE2). Será necessário alterar o fonte PLSMPAG para que não chame esta função, já que não iremos gerar o SE2 baseado nas informações do PLS;
          • Teremos que adicionar neste ponto as funções de chamada para a Classificação da Pré-Nota no SF1 e e a consequente geração do título na SE2 por estas funções.
          • Para classificar, será necessário ou exibir o registro aberto na tela de Documento de Entrada (MATA103) ou então, verificar se apenas exibindo as possibilidade de classificação (conforme pesquisa padrão SF4) e preenchendo o campo D1_TES com este valor e chamando a função A103GRAVA, o sistema já executa as funções de validação e procede com seu processamento normal, chamando a função A103AtuSE2, responsável pela geração do título na SE2.
    2. Após a classificação da nota e geração do título no SE2 pelo MATA103, continuar com o processamento normal de geração de lotes do PLS.
18.  Após a finalização do processo, os lotes estarão gerados e os títulos lançados na SE2 de acordo com os dados e informações da Pré-Nota.
    
    
    

11. 

Regras de Negócio - Pessoa Física/Jurídica (geração de PEG pelo Portal)

1. Criar o parâmetro MV_RPACIET no SX6;
2. Prestador acessa o Portal do Prestador, com seu login e senha;
3. Acessa a opção Portal TISS / Protocolo (fonte PPLCHAPTC);
4. Na página, na primeira aba (Gerar Novos Protocolos), o prestador seleciona os parâmetros desejados para encontras as guias lançadas;
5. Caso o Prestador seja obrigado a enviar a RPA - Recibo de Pagamento Autônomo (quando Pessoa Física e conforme seleção do campo BAU_OBRDFC), após a seleção das guias no grid, ao clicar no botão Gerar Protocolo, o prestador será obrigado e preencher a tela de RPA, que será o novo fonte PPLRPAINF.
   
   1. Caso faça o envio por XML, seguirá o mesmo esquema da Pessoa Jurídica, se diferenciando que ao invés de digitar uma Nota no Portal, irá digitar a RPA.
   2. Caso seja uma Pessoa Jurídica gerando PEGs, ao invès de aparecer a tela de RPA, será exibido a tela de inclusão de Documentos Fiscais.
6. Ao abrir a página PPLRPAINF, será  exibido um formulário contendo os dados da RPA, para preenchimento do prestador:
   1. Os dados que o sistema possuir e que são exibidos na RPA estarão preenchidos em tela, para facilitar ao prestador.
   2. Demais campos serão de preenchimento manual, bastando o prestador entrar com as informações solicitadas.
   3. Um campo para upload de imagem, caso seja necessário o envio da RPA com assinatura via sistema. Banco de Conhecimento atrelado a tabela que será criada para guardar os dados da RPA.
7. De acordo co o valor do parâmetro MV_RPACIET, no final da RPA teremos duas opções:
   1. Abaixo da RPA saíra um campo de Assinatura, para que o prestador após o preenchimento, possa imprimir a RPA, assinar e anexar no sistema;
   2. Um campo do tipo checkbox, onde conterá um texto que diz que o prestador concorda com as informações ali fornecidas e que são verídicas. Caso assinale, basta apenas salvar a RPA no sistema.
8. Esta RPA deverá ser salva na Tabela Bxx (o desenvolvedor deverá encontrar um alias dentro do range Bxx disponível, certificando que o mesmo não é utilizado em nenhuma outra rotina do sistema).
9. Ao clicar no botão Confirmar da página PPLRPAINF, o sistema deverá exibir uma caixa (usar modalBs, presente no arquivo jspls.js) para que o Prestador possa associar a RPA inserida com as guias encontradas na sua busca anterior.
   1. Podemos ter uma RPA para cada guia ou então, uma RPA para várias guias, como ocorre com a Nota Fiscal.
10. Após a associação e ao clicar no botão Confirmar do modalBs, o sistema irá gerar o Protocolo de Entrega de Guias - PEG conforme rotina padrão.
    1. Caso o prestador não seja obrigado a enviar a RPA neste momento, poderá gerar os protocolos Normalmente;
       1. Porém, o campo BCI_STSDFC deverá ficar com o status Pendente de NF, pois o prestador deverá depois adicionar esta RPA no processo.
    2. Caso seja obrigatório o envio da RPA, o sistema deverá gerar a Pré-Nota. OBS: como serão os campos número, série da Pré-Nota aqui? Sequencial automático?
    3. Importante: Da geração da Pré-Nota, é necessário internamente preencher os seguintes dados, para que a Pré-Nota seja gerada corretamente, que são:
       1. Fornecedor - campo F1_FORNEC. Este dado é o código do fornecedor, que é diferente do código da RDA. O campo número do fornecedor fica no campo BAU_CODSA2;
       2. Loja - F1_LOJA. Esta dado é obtido do campo BAU_LOJSA2;

       3. Condição de pagamento - F1_COND. Será necessário pegar este valor do cadastro de fornecedores e fica localizado no campo A2_COND;

       4. Data de Digitação - D1_DTDIGIT. É a data de inclusão da Pré-Nota; 

       5. Quantidade do produto/Serviço - D1_QUANT. Colocar o valor 1;

       6. A natureza é proveniente do Cadastro de Fornecedor – A2_Natureza

       7. Código do Produto / Serviço - D1_COD. No PLS, usar a informação do campo BLR_CODPRO.

    4. Para gerar a Pré-Nota (Fonte MATA140), pode-se utilizar o MsExecAuto da função MATA140. Os seguintes fontes contêm o MSExecAuto para a geração da Pré-Nota:
       1.  fonte ACDV125;
       2. fonte LOJA701C;
       3. fonte GFEA065.
    5. Após a geração do Protocolo, a PEG deverá ficar com o status 2 - Em Análise, conforme tabela 47 da TISS (função PLRETSTISS, responsável em realizar o De/Para dos status dos protocolos do sistema com os status da TISS de forma correta)
       1. A PEG já entra no status em Análise, pois quando é gerado o Protocolo nesta tela, o sistema já gera a PEG com as guias incluídas, diferente do envio do XML.
       2. O campo BCI_CODDFR deverá receber o valor da Pré-Nota gerada;
       3. De acordo com o valor do parâmetro MV_RPACIET, caso além do preenchimento da RPA seja necessário o envio com a assinatura, o campo BCI_STSDFC ficará com o status Pendente de NF. Caso seja preciso apenar dar um check na declaração, o campo BCI_STSDFC deverá ficar com o status de Enviado.
11. Os operadores do Contas Assistenciais irão realizar as análises de acordo suas diretrizes.
12. Caso a PEG e suas guias estejam corretas e o Documento Fiscal (RPA) esteja confirmada (BCI_STSDFC com o status Enviado), o operador irá liberar a PEG (Mudança de Fase) com o status 3 - Liberado para pagamento, onde ao gerar os lotes de Pagamento deverá ser considerado este status (a função PLRETSTISS não contempla este status. Logo, será necessário realizar o De/Para do sistema para realizar a troca para o status correto).
13. Caso na análise seja constatado que falta o Documento Fiscal (RPA) (pois a RDA pode não ser obrigada a enviar o Documento Fiscal, conforme campo BAU_OBRDFC) ou exista glosa, a PEG será liberada com o status 5 - Analisado e aguardando liberação para o pagamento, onde o ao gerar os lotes de Pagamento deverá ser considerado este status (a função PLRETSTISS não contempla este status. Logo, será necessário realizar o De/Para do sistema para realizar a troca para o status correto).
14. Quando a PEG estiver sem o Documento Fiscal (RPA), o sistema deve enviar um e-mail solicitando ao Prestador a inclusão da RPA no Portal (os e-mails deverão utilizar as diretrizes do item Regras de Negócio - Cadastro e envio de E-mail)
    1. O e-mail deverá constar algumas das informações da PEG e deverá ter o link para o Portal, se possível, para a nova tela de Gerenciamento de Documentos Fiscais. 
    2. A nova tela de Gerenciamento de Documentos Fiscais (fonte PPLINCDF), será o meio onde o prestador irá realizar a troca de RPA (nos casos de glosas ou a RPA contiver algum erro) ou anexar a RPA quando não for obrigatório no Processo. 
       Esta tela deverá permitir a pesquisa por Data Inicial e Data Final, além de filtrar pelos tipos de pendência (Pendente de NF, Troca de NF ou Ambos), sendo que abaixo deverá ter um grid com os dados encontrados, conforme layout abaixo. Essa pesquisa é proveniente da Tabela BCI e só serão exibidos as PEGs que estiverem no status 5 - Analisado e aguardando liberação para o pagamento. O grid deverá exibir:
       1. Exibir as PEGs encontradas, com os parâmetros informados;
       2. Exibir o status da PEG com relação ao Documento Fiscal;
       3. Exibir o Valor da PEG;
       4. Exibir o número do Documento Fiscal (caso tenha sido incluída anteriormente);
       5. Exibir o campo número da Nova Nota Fiscal (caso seja troca);
       6. Exibir botão para adicionar o novo Documento Fiscal ( que deverá encaminhar para a tela PPLINCNFR) .
          
15. Tanto para inclusão do Documento Fiscal (RPA) faltante quanto para a troca, esta será a tela de gerenciamento geral. Quando pressionar o botão Incluir Nota Fiscal, o sistema irá abrir a tela de Inclusão de RPA (fonte PPLRPAINF).
16. Caso o parâmetro MV_RPACIET esteja setado apenas com a confirmação via checkbox, após o preenchimento da RPA, o campo BCI_STSDFC será atualizado com status "3" (Enviado).
    1. Caso seja necessário o envio da RPA com assinatura, o sistema irá informar que os dados estão salvos e que o protocolo ainda ficará na status (BCI_STSDFC) com valor "1" (Pendente Doc. Fiscal) que após assinatura, basta acessar esta tela, clicar em Incluir Nota Fiscal e que todos os dados salvos anteriormente serão restabelecidos (utilizar Dbseek, MsSeek ou consulta SQL para localizar se já existe registro), bastando apenas efetuar o upload da imagem no campo de upload da RPA. Somente após o envio do Anexo o status do campo BCI_STSDFC ficará com status "3" (Enviado).
    2. Somente com o status da BCI_STSDFC como "3" (Enviado) será gerado a Pré-Nota com os dados constantes da RPA.
    3. O campo BCI_CODDFR irá receber o número da Pré-Nota gerada.
       
    4. O sistema irá atualizar o status da PEG de 5 - Analisado e aguardando liberação para 3 - Liberado para pagamento.
17. No casos onde ocorreram Glosas, o sistema deve enviar um e-mail ao prestador, solicitando a troca do Documento Fiscal por um novo, de forma  que seja possível detalhar o novo valor bruto pelo qual a nova nota deve ser geradae demais informações pertinentes que a Operadora quiser colocar no e-mail.
    1. O e-mail deverá constar algumas das informações da PEG e deverá ter o link para o Portal, se possível, para a nova tela de Gerenciamento de Documentos Fiscais.
    2. Se o status do campo BCI_STSDFC for de Troca de Documento Fiscal (RPA), o sistema irá trabalhar da seguinte maneira:
       1. • A tela de inclusão irá funcionar da mesma maneira, ou seja, terá que entrar com os dados obrigatórios na tela e subir o arquivo XML da NF ou imagem.
          • No final do processo, deverá ser exibido a modalBs (presente no arquivo jspls.js) mostrando todas as PEGs que estão atreladas ao Antigo Documento Fiscal e informar que na atualização, a nova RPA será atualizada para estas PEGs.
          • Caso clique em Confirmar, o sistema deverá atualizar o campo BCI_CODDFR com o novo número gerado.
          • O sistema deverá realizar as mesmas verificações do parágrafo 16, dos itens A ao D.
18. A geração dos lotes de Pagamento seguirá a mesma lógica do Prestador Pessoa Jurídica, seguindo as etapas 15 até seu final.

Regras de Negócio - Cadastro e envio de E-mail

Aqui, iremos utilizar a rotina do CRM, com relação aos contatos que podemos cadastrar nas RDA's, tornando o processo de envio de e-mail para cada departamento de forma mais simples e dinâmica.

Em Atualizações / Rede Atendimento / Redes de Atendimento, ao clicar no botão Outras Ações, temos a opção Contatos CRM. Na tela que se abre, podemos clicar no campo Contato, no grid da tela e o sistema irá elencar os contatos já cadastrados no módulo CRM. O usuário pode localizar o contato (se já cadastrado) ou então, realizar a inclusão de um novo, inserindo diversos dados, como telefones, endereço, e-mail, departamento e outros.

Esses contatos são vinculados ao cadastro da RDA através do vínculo Relação de Contatos vs Entidades, que fica salvo na tabela AC8 - Relação de Contatos x Entidade. Para que o cadastro de Sinalizador se torne completamente operacional, necessitamos definir também para qual setor e até mesmo cargo dentro daquele setor precisamos enviar o e-mail, pois hoje, definimos um e-mail padrão e não sabemos se está sendo encaminhado para a pessoa que realmente necessita receber o e-mail. Logo, iremos utilizar o cadastro de Contatos CRM para definir estes níveis e realizar alterações no cadastro de sinalizador.
Desta forma, temos os seguintes dados:

1. A tabela SU5 - Contatos contêm o cabeçalho dos contatos. Os campos U5_FUNCAO e U5_DEPTO armazenam respectivamente o código da função do contato e o departamento em que trabalha.
2. Na tabela SUM - Cargos, temos o cadastro dos cargos (funções) que alimentam via F3 o campo U5_FUNCAO.
3. Na tabela SQB - Departamento, temos o cadastro dos departamentos que alimentam via F3 o campo U5_DEPTO.
4. A tabela AC8 - Relação de Contatos x Entidade mantêm o vinculo entre os contatos com a RDA selecionada no momento.

Desta forma, será necessário alterar o Cadastro de Sinalizadores (fonte PLSPRO02) para que seja incluído também os campos Departamento e Cargo, para que quando determinado sinalizador contiver estes campos preenchidos, será necessário buscar o contato atrelado a RDA que possa estes campos compatíveis com os dados do sinalizador. Logo, teremos que criar três novos campos na tabela BOJ - Sinalizadores:

1. BOJ_FUNCAO, que será um campo com F3, com pesquisa para a tabela SUM de Cargos;
2. BOJ_DEPTO, que será um campo com F3, com pesquisa para a tabela SQB de Departamentos; 
3. BOJ_STSCON, que será um campo do tipo combo, com os mesmos valores presentes no campo U5_STATUS, diferenciando que iremos colocar uma opção a mais, chamada "Ambos". O campo U5_STATUS informa se o cadastro do contato está 1=Desatualizado, 2=Atualizado ou 3=Em Desenvolvimento. A opção Ambos irá considerar os status 1, 2 e 3 de forma simultânea para considerar o envio do e-mail. 

Logo, sempre que alguma rotina de e-mail for realizar o envio do Sinalizador (como a função PLSINALIZA e outras), será necessário verificar se os campos BOJ_FUNCAO e BOJ_DEPTO estão preenchidos, pois caso sim, terá que localizar os contatos atrelados a RDA de acordo com os dados destes campos. Ou seja:

1. Se BOJ_DEPTO estiver preenchido, será necessário verificar todos os contratos atrelados a RDA que possuem o mesmo código de departamento, pegar o e-mail do campo U5_EMAIL e enviar o e-mail para estes contatos, pois possuem o mesmo código de departamento definido no sinalizador.
2. Se BOJ_FUNCAO estiver preenchido, será necessário verificar todos os contratos atrelados a RDA que possuem o mesmo código de função, pegar o e-mail do campo U5_EMAIL e enviar o e-mail para estes contatos, pois possuem o mesmo código de funcao definido no sinalizador.
3. Se BOJ_DEPTO e BOJ_FUNCAO estiverem preenchidos, será necessário verificar todos os contratos atrelados a RDA que possuem o mesmo código de departamento e função, pegar o e-mail do campo U5_EMAIL e enviar o e-mail para estes contatos, pois possuem o mesmo código de departamento e função definido no sinalizador.
4. Para ambos os casos acima (de 1 a 3), teremos que verificar quais contatos serão considerados, de acordo com seus status, conforme campo BOJ_STSCON.
5. OBSERVAÇÃO: 
   1. No cadastro da tabela SU5, temos o campo U5_ATIVO, onde definimos se este contato está ativo ou não. Considerar apenas os contatos Ativos (valor 1=SIM).

Desta forma, conseguimos fazer com que o Sinalizador fique especifique para um grupo de pessoas e situações, permitindo que fique adequado conforme as necessidades da Organização, quando precisa enviar e-mails para instituições que possuem diversos colaborares e diferentes e-mail cadastrados.

Dicionário de Dados

Tabela BCI - Protocolo de Entrega de Guias

Tabela BXX - Importação de XML

Protótipos

Exemplos de e-mails que deverão ser enviados no caso de Troca de Nota devido a Glosas ou falta do Documentos Fiscal:

• Troca de Nota

• Solicitação de Inclusão de Nota

• Tabela 47 da TISS