Árvore de páginas


CONTEÚDO

  1. Visão Geral
  2. Detalhamento
  3. Nova tela de Fornecimento Direto
  4. Novas tabelas
  5. Tabelas utilizadas


01. VISÃO GERAL 

A presente especificação visa detalhar as telas e demais componentes necessários para a nova tela de Fornecimento Direto ao Beneficiário, onde a Operadora deverá inserir os dados de entrega de itens aos beneficiários, que servirá como insumo para os dados enviados no Monitoramento TISS.

A tela deverá integrar com o módulo de Nota Fiscal x Guias (PLSA298), para melhor controle e sua geração correta no monitoramento.

Por se tratar de tema técnico e inicial, a presente especificação pode passar por atualizações em seu conteúdo e durante o desenvolvimento, visto que passará por diferentes crivos de análise e testes diversos, de forma a enriquecer o material e entrega da funcionalidade.

ATENÇÃO

 Este documento é material de especificação de requisitos, trata-se de conteúdo extremamente técnico e não existe garantia de desenvolvimento do item, por se tratar apenas de especificação.


02. Detalhamento 

A) Entrada dos dados para a nova tela de Fornecimento Direto - Tela de medicamento de uso Constante (portal beneficiário) e Análise de Receitas (PLSANRCT - remote)

Uma das entradas de solicitação de Fornecimento direto se dará por meio do Portal Web do beneficiário, por meio da tela de Cadastro Medicamento Uso Constante.

Nessa tela, podemos ter duas ações:

  • Criar um checkbox, para o usuário indicar que se trata de um medicamento/item de alto custo e que deve ser fornecido pela Operadora (alto risco de erro por parte do usuário).
  • Descobrir - via chamado na ANS ou outro meio - quais são os código mais comumente usados ou obrigatórios para esse fim, para que quando o cliente informar esse código, o sistema já entenda que se trata de uma solicitação de fornecimento direto.

Em ambos os casos, criar um campo novo na tabela B7D - Receitas Medicamento x Usuario, para identificar que o item é fornecimento direto, conforme diretrizes abaixo. Características do campo:

  • Campo B7D_FORDIR, tipo caracter, tamanho 1, combobox: 0=Não;1=Sim, valor padrão: 0.
  • Na tela do Portal, de acordo com a escolha do preenchimento do campo - ou seja, se o usuário deverá marcar que se trata de medicamento de fornecimento direto, este campo deverá estar visível e disponível para escolha do usuário (sugestão: pode ser um campo do tipo check ou combobox), no grupo Incluir Medicamentos.  Se a escolha for de acordo com o código digitado o sistema separa o que é fornecimento direto ou não, este campo ficará oculto e será preenchido pelo sistema, na hora de salvar os dados da receita.
  • Este campo deverá estar visível e disponível para uso do operador do sistema - na tela de Analise de Receitas (PLSANRCT), no grid Receitas Medicamento x Usuario - para que possa alterar o campo, caso constate que o item discriminado pelo usuário seja fornecimento direto ou não. 
  • Na hora de gravar a análise de receita, caso o medicamento aprovado seja de fornecimento direto - os dados deverão ser clonados dessa análise, para a nova tela de Fornecimento Direto, para que seja possível sua geração, controle e rastreamento pela Operadora.


B) Nova guia de Fornecimento Direto

Como o sistema se baseia em guias, para poder valorar, contabilizar, monitorar e outros, será necessário criar um novo tipo de guia exclusivo para o Fornecimento Direto. Logo, toda vez que um fornecimento direto for efetuado pela Operadora ao Beneficiário, será necessário criar uma guia, para que seja possível o cálculo de coparticipação, de valoração e seja considerada na rotina de monitoramento - ao relacionar essa guia a uma Nota Fiscal -  utilizando a rotina de Nota Fiscal x Guia (PLSA298), fechando o ciclo completo do fornecimento.

Assim, devemos criar um novo tipo de guia, de código 14 - Fornecimento direto, na tabela BCL - Tipos de Guias.

  1. Deve-se atualizar o wizard da tabela BCL, no TFS, no caminho $/Protheus_Padrao/Fontes_Doc/Master/Arquivos_Auxiliares/Saude/Diversos/wizard/bcl-tipos_de_guias.CSV;
  2. Ao criar o registro no arquivo BCL, será a guia de número 14 (BCL_TIPGUI);
    1. Exemplo da criação dor registro no wizard BCL: 0001$14$GUIA DE FORNECIMENTO DIRETO$BD5$PLSA500$1$07$PLSA720INI$1$PLSA720SAI$1$PLSA720EDT$1$PLSA720GRV$1$PLSA720MF$1$$PLSA720PRO$1$0$$$2$PLSA720AJU$1$PLSA720CPO$$3$1$$$0$999$$4.01.00$$$$$$
    2. Será necessário atenção quanto ao campo de Cor da Guia (BCL_CODCOR), pois não pode ser duplicado.
  3. Verificar e acertar o wizard, conforme progresso da rotina.    

 

C) Tela de Fornecimento Direto 

Essa tela será a responsável por centralizar os dados do Fornecimento Direto, que serão utilizados para controle dos medicamentos/itens dados ao ao beneficiário e no monitoramento TISS.

A tela deverá conter os dados necessários, conforme schema da ANS, para envio do monitoramento, bem como os demais campos auxiliares para a Operadora e usuários, para as anotações devidas.

Abaixo, iremos descrever as tabelas utilizadas e o modelo em MVC, para a criação dessa nova tela:

  • Alias disponíveis para uso - consultado ATUSX, fontes e Trello. A sugestão de campos desses alias estarão disponíveis no final do documento. 
ALIASTABELAX2_UNICO
BJFCabec. Solic. Fornec. Direto  BJF_FILIAL+BJF_IDENTI
BJGItens Fornecimento Direto     BJG_FILIAL+BJG_SEQUEN+BJG_CODPAD+BJG_CODPRO


  1. As tabelas BJF e BJG serão preenchidas automaticamente, após o aceite do analista da Operadora, na tela de Cadastro de Receita.
    • Contudo, a nova tela deverá ter a opção de inserir os dados do cabeçalho e itens pela Operadora, pois nem sempre, a solicitação virá do cadastro de receita.
  2. O fonte da nova tela deverá ter o nome PLSFORDIR, para ligação mnemônica com o que a rotina propõe.
  3. Características da tela: 
    1. A tabela BJF será o cabeçalho da solicitação, que irá conter os dados principais da solicitação, conforme schema da TISS:
      1. No cabeçalho, devemos ter as informações do beneficiário, como: matrícula; nome do beneficiário; número da Carteira de Saúde; CPF; sexo, data de nascimento; código do município de residência; código do Plano de Saúde e o código da receita de uso constante (desde que essa solicitação seja proveniente da entrada via Portal).
      2. Ainda no cabeçalho, deverão ter os seguintes dados do fornecimento e de controle interno da rotina, que são: código da Operadora; tipo de registro (obsoleto); data de fornecimento; valor total do fornecimento; valor total tabela Própria; valor total Coparticipação; observações e número da guia gerada de Fornecimento Direto, após confirmar entrega dos itens ao beneficiário. Deve existir o campo de controle de código de identificação, de tamanho 20, de nome BJF_IDENTI.
      3. OBS: Se a solicitação for proveniente do cadastro de receita de uso constante do Portal, o campo matrícula e os demais campos ligados ao grupo de beneficiário deverão ficar bloqueados para edição, visto que o dado foi inserido pelo beneficiário e essa receita foi aprovada pela Operadora, na tela de Análise de Receita.
      4. OBS 2: Se a solicitação estiver sendo preenchida direto na nova tela - ou seja, não teve receita cadastrada - o único campo que ficará disponível para edição - do grupo de beneficiário - será campo de matrícula, pois após selecionar a matrícula do beneficiário, deverá gatilhar (preencher) as demais informações do beneficiário selecionado pelo usuário.

    2. Browse inicial da rotina de Fornecimento Direto (PLSFORDIR)

       

    3. Tela de inclusão de Fornecimento Direto, com os campos do grupo de beneficiário e demais pertinentes ao fornecimento efetuado e controle da interno.

    4. Os campos tipo de registro (obsoleto); data de fornecimento observações  sempre estarão disponíveis para edição do usuário, pois se referem a data que foi entregue o item e o campo de observações, para colocação de dados complementares pela Operadora. 
    5. No grid onde temos os medicamentos e itens fornecidos - Eventos - Tabela BJG - será colocado os itens da receita ou os itens inseridos pelo usuário da operadora, que serão fornecidos ao beneficiário. Atenção a alguns detalhes:
      1. Pelo schema, no item <procedimento>, temos duas opções para informar procedimento: pelo grupo do procedimentos (tabela 63) ou código do procedimento.
      2. Caso o usuário clique no grid da coluna Grupo de Procedimento (BJG_CODGRU), deverá ser criada uma consulta padrão (SXB), que irá buscar os procedimentos na tabela BR8 - Tabela Padrão, cruzando dados com a tabela BTQ - Detalhe das Terminologias TISS, filtrando a pesquisa com o campo do BR8_CODPAD igual a BJG_CODPAD e BR8_BENUTL igual a '1' e na tabela BTQ, o campo BTQ_CODTAB igual a '64'BTQ_FENVIO igual a 'Consolidado', conforme instruções presentes no manual TISS.
        1. Após o usuário selecionar o item, deverá ser validado a vigência do item, se está ativo no período fornecido (BJF_DATFOR) na tabela BTQ e o campo BJG_CODGRU deverá ser preenchido com o código do grupo (campo BTQ_CODGRU) e no campo BJG_CODPRO o código do procedimento selecionado.
      3. Caso o usuário clique no grid da coluna Código do Procedimento (BJG_CODPRO), deverá ser criada uma consulta padrão (SXB), que irá buscar os procedimentos na tabela BR8 - Tabela Padrão, cruzando dados com a tabela BTQ - Detalhe das Terminologias TISS, filtrando a pesquisa com o campo do BR8_CODPAD igual a BJG_CODPAD e BR8_BENUTL igual a '1' e na tabela BTQ, o campo BTQ_CODTAB igual a '64'BTQ_FENVIO igual a 'Individualizado', conforme instruções presentes no manual TISS.
        1. Após o usuário selecionar o item, deverá ser validado a vigência do item, se está ativo no período fornecido (BJF_DATFOR) na tabela BTQ e o campo BJG_CODPRO deverá ser preenchido com o código do procedimento selecionado.
      4. Ainda no grid de procedimento, caso a solicitação tenha sido criada a partir de uma aprovação de receita de uso constante, o valor do campo B7D_UNICON deverá receber um De/Para com a tabela BTQ,  com o BTQ_CODTAB igual a '60', pois a rotina de análise de receita grava o valor do campo BTQ_DESTER, que é descrição, sendo que o esperado no monitoramento é o campo BTQ_CDTERM, código da terminologia. Logo, deverá existir esse tratamento de De/Para ao gravar na tabela BJG, para que no campo BJG_CODUND seja gravado o valor do código da terminologia, e não a descrição.
      5. Ao clicar no campo BJG_CODUND, deverá ser criada uma consulta padrão (SXB), para buscar os dados na tabela BTQ, onde o filtro do campo BTQ_CODTAB igual a '60', devendo retornar o valor do campo BTQ_CDTERM
      6. Ao informar o valor do item fornecido no campo BJG_VLRFOR, esse valor deve ser acrescido no campo BJF_VLTOFO ou BJF_VLTOTP, ou seja, ao informar um valor no campo BJG_VLRFOR, deverá ser somado no campo BJF_VLTOFO ou BJG_VLTOTP, pois esse campo é o valor total dos itens fornecidos ao beneficiário.
        1. Atenção: Aqui, temos que observar que no cabeçalho do fornecimento direto, temos o valor total dos itens fornecidos, bem como o valor total dos itens de tabela própria. Não existe uma maneira direta de saber se o código da tabela informada é tabela própria ou não, e por isso, será necessário fazer uso das funções de vínculo com a TISS, como o PLSGETVINC.
          1. Se ao rodar a função PLSGETVINC - com o valor do código da tabela BJG_CODPAD - e o retorno for vazio ou uma tabela de código diferente de 19-Materiais ou 20-Medicamentos, podemos entender que se trata de uma tabela própria, logo o valor do campo BJG_VLRFOR deve ser somando no valor do campo BJF_VLTOTP. Se a função PLSGETVINC retornar o código 19-Materiais ou 20-Medicamentos, é uma tabela que tem De/Para com a TISS, ou seja, não é própria, e o valor do campo BJG_VLRFOR deve ser acrescido no campo BJF_VLTOFO.
      7. O valor de Coparticipação - BJG_VLRCOP - será preenchido apenas quando a guia de Fornecimento Direto for gerada e calculada, pois nesse instante, teremos a coparticipação calculada e poderá ser gravada no campo BJG_VLRCOP para o item e no campo BJF_VLTOCP, deverá ser colocado o total das coparticipações, caso exista mais de um item na solicitação.
    6. Ao clicar no botão Confirmar da tela, temos as seguintes possibilidades:
      1. Se o campo BJF_DATFOR estiver vazio ou alguns dos campos obrigatórios de itens - BJG_CODPAD, BJG_CODGRUBJG_CODPRO, BJG_QUANTI ou BJG_VLRFOR - estiverem vazios, não será gerada a Guia de Fornecimento, visto que faltam dados obrigatórios para envio na ANS, ou seja, o registro poderá ser editado normalmente pelo usuário, até o seu completo preenchimento.
      2. Se o campo BJF_DATFOR estiver preenchido e os itens cadastrados estiverem com todas as informações obrigatórias preenchidas (BJG_CODPAD, BJG_CODGRUBJG_CODPRO,, BJG_QUANTI e BJG_VLRFOR), o sistema deverá gerar a nova guia de Fornecimento Direto, de código 14, no Digitação de Contas (PLSA498), para que o sistema possa valorizá-la e constar para busca na rotina de monitoramento.
        1. Para criar a PEG e guia de Fornecimento Direto no sistema, utilizar como base a função ProcCtaINC, que está no fonte PLSRECGLO3.  Essa função faz exatamente todo o processo de criação da guia e PEG, para o Recurso de Glosa, que será semelhante para criar a guia de Fornecimento Direto.
          1. Atenção: Diferente do Recurso de Glosa, que temos o prestador definido, devemos utilizar para a situação do fornecimento direto um prestador genérico, para criação da guia. Pode-se utilizar o valor do parâmetro MV_RDAPROP - Define qual RDA(BAU_CODIGO) do cadastro será o prestador referente a operadora para envio do Fornecimento Direto, utilizado no monitoramento.  
            Demais campos necessários para criação da guia, utilizar o valor default dos campos, para criação da guia.
        2. Após criação da guia - usando as funções detalhadas acima - chamar rotina de Mudança de Fase, para que o sistema gere os valores de coparticipação e outros. Exemplo dessa mudança de fase de guia está no fonte PLSRECGLO3, função fPosiMudFas.,
          1. Após a mudança de fase, como o registro estará posicionado na guia, recuperar o valor de coparticipação do beneficiário nos itens da BD6 (BD6_VLRPF) e replicá-los para seus respectivos itens na tabela BJG, no campo BJG_VLRCOP. Não devemos esquecer que essas coparticipações deverão ser somadas e imputadas no campo BJF_VLTOCP.
          2. Com a guia gerada, preencher os campos BJF_CODPEG, BJF_CODLDP e BJF_NUMERO com os dados da guia gerada, para possibilitar o rastreio da guia que foi gerada a partir desse fornecimento.
    7. Após gerar a guia e preencher os campos faltantes das tabelas BJF e BJG - como valores de coparticipação e o número da guia gerada - devemos vincular essa guia gerada com uma Nota Fiscal que está no módulo de Compras do sistema, para fechar o ciclo de fornecimento direto, pois além de gerar a guia, iremos vinculá-la a Nota Fiscal de compra do material, garantindo o clico de fornecimento direto em sua totalidade, para correto rastreio do material e nota fiscal de compra pela Operadora e seus usuários.


C) Vinculação da guia de Fornecimento Direto com a Nota Fiscal de compra do material

  1. Teremos dois cenários a considerar: um que o cliente use o BackOffice do sistema, com gestão de estoque, documentos de entradas e demais funcionalidades, e no outro cenário, será o cliente que não usa o backoffice, e assim, não terá nota Fiscal de entrada.
  2. Será necessário verificar se essa checagem será feita via um parâmetro, onde a Operadora irá indicar se utiliza ou não o BackOffice ou outra forma. Nessa especificação, iremos trabalhar com a hipótese do parâmetro, de nome MV_PLATBKF, que será de valor lógico e o default igual a .T., indicando que a Operadora utiliza o BackOffice.
  3. Abaixo, iremos detalhar os passos para os clientes que possuem o BackOffice integrado:
    1. Após a geração da guia de fornecimento Direto, antes de fechar a rotina, devemos exibir um ParamBox ou Pergunte, para permitir a vinculação da guia recém-gerada com uma Nota Fiscal de Entrada do sistema, que consta o item fornecido ao beneficiário.
    2. Para tanto, após a conclusão dos passos descritos na etapa B - geração da guia e preenchimento dos campos - iremos exibir um FwBrowse, em uma dialog ou modal, que irá exibir os itens da guia de fornecimento direto, da tabela BD6 (exibir Sequencial do item, Código da Tabela, Código do procedimento e Descrição - bloqueados para edição), além de campos exclusivos para editar o código do Fornecedor, Número do Documento e Série do Documento - disponíveis para edição. Abaixo, características dos campos referentes a Nota Fiscal. Exemplod e FwBrowse funcional e carregado com dados pode ser encontrado na função Telaorfaos, nos fontes PLSSIMPRO ou PLSBRASIN1.
      1. Campo de nome Fornecedor, que armazenará o código do Fornecedor, com lupa para pesquisar os fornecedores cadastrados. Usar a consulta padrão (SXB) de nome FOR, que retorna todos os fornecedores cadastrados na base. Se digitado manualmente, validar se o fornecedor existe  está ativo;
      2. Campo de nome Documento, para armazenar o número do documento Fiscal. Esse campo deverá conter uma consulta padrão(SXB), que irá filtrar as notas fiscais de acordo com o fornecedor escolhido no campo  anterior (Fornecedor). Se digitado manualmente, validar se a Nota Fiscal existe e está vinculada ao fornecedor selecionado.
      3. Campo de nome Série, para armazenar o número da série do documento fiscal, de acordo com o selecionado pelo usuário no campo anterior (Documento). Se digitado manualmente, validar se a série pertence a Nota informada.
    3. Após informado e validado os dados acima no FwBrowse, devemos estabelecer o vínculo da Guia de Fornecimento Direto com a Nota Fiscal selecionada.
      1. Podemos utilizar para esse fim o fonte PLSA298 - Nota Fiscal x Guia - que é um fonte MVC.
      2. Para a gravação, basta instanciar a classe PLSA298 e setar os valores no model de forma correta, para que o Model faça as validações internas aplicáveis e caso esteja tudo correto, possa gravar essa vinculação e, caso ocorra erro, o usuário seja informado dos problemas.
        1. Caso ocorra sucesso na gravação da vinculação, ou seja, dados da guia corretos e vinculados com sucesso na Nota informada, o campo BJF_VINCNF deve ser preenchido com o valor '1'-Sim, indicando que esse fornecimento gerou guia e já está vinculada a uma Nota Fiscal.
        2. Se ocorrer algum erro, a mensagem do model deve ser exibida para o usuário, para que providencie a correção. Nesse caso, nenhum vínculo será realizado e a mensagem do erro deve ser gravada no campo BJF_OBSERV, para análise posterior do usuário.
    4. A função de vinculação dessa janela também deverá estar disponível no botão Outras Ações da Tela de fornecimento direto (PLSFORDIRE), para que seja possível realizar essa vinculação depois da correção do erro - caso exista - ou para outros setor realizar essa ação, não necessariamente no final da gravação da tela.
  4. Agora, iremos detalhar o cenário onde o cliente não tem o BackOffice integrado, ou seja, o parâmetro MV_PLATBKF está com o valor .F.:
    1. Não será exibido o FwBrowse, para vinculação de Nota Fiscal com a guia recém gerada
    2. Nessa situação, será necessário alterar a query de pesquisa do fonte PLSM270, na função PLS270Forn.
    3. A query, ao invés de fazer o JOIN com a tabela B19, irá fazer JOIN com a tabela BJF, pois temos todos os dados necessários para enviar o monitoramento.
      1. Atenção: Será necessário verificar outras mudanças no monitoramento, pois essa mudança pode impactar nos processos, como na gravação da tabela B4M e B4N, sendo necessário analisar o impacto dessa mudança durante o desenvolvimento da rotina e testes do desenvolvedor.


D) Geração do Monitoramento TISS com o fornecimento direto

  1. Com a conclusão das etapas acima, ou seja, cadastrando os itens que serão entregues para o beneficiário, geração da guia de Fornecimento Direto e vinculação com a Nota Fiscal, a rotina de Monitoramento TISS (PLSM270), irá realizar os processos corretamente, pois já está preparada para esse tipo de fornecimento, bastando ter a guia e relacioná-la com uma Nota Fiscal.
  2. O processo que existe hoje no monitoramento já vai atender ao proposto, que é gerar o bloco de fornecimento direto com as informações corretas.
    1. Pontos de Atenção:
      1. Verificar como irá sair a data de fornecimento no arquivo XTE, pois hoje, o sistema utiliza a data de pagamento ou data de digitação. Dependendo de como a guia for gerada, será necessário buscar essa informação no campo BJF_DATFOR, para gravar corretamente no monitoramento, no fonte PLSM270B4N.
      2. O mesmo cuidado deve ser feito com os demais campos, como valores totais de fornecimento, tabela própria e coparticipação.
      3. Testar no monitoramento a exclusão do lote, bem como a alteração do lote, para verificar se a tag <tipoRegistro> é tratada corretamente em cada cenário, ou seja, Inclusão, Alteração e Exclusão.  


03. Tela de Cadastro Fornecimento Direto

A tela poderá ser feita em MVC ou PO-UI, de acordo com a necessidade.

 


04. Tabelas  

  • Criação das tabelas citadas no documento.
  • Poderá ser necessário ajuste em outras tabelas, conforme avanço do projeto ou necessidades aqui não contempladas.


05. TABELAS UTILIZADAS 

  • BCL - Tipos de Guias
  • BD5 - Processamento de Contas
  • BD6 - Eventos Processamentos Contas
  • BD7- Part Honorários Prestado Itens
  • BJF - Cabec. Solic. Fornec. Direto
  • BJG - Itens Fornecimento Direto
  • BR8 - Tabela Padrao
  • BTQ - Detalhe das Terminologias TISS