Histórico da Página

...

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.
      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 e 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_CDGRUPCODGRU), 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' e  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_CDGRUP CODGRU deverá ser preenchidocom o código do grupo (campo BTQ_CODGRU) e no campo BJG_CODPRO o código do procedimento selecionado.
         2. Não poderá repetir no grid o mesmo código de procedimento ou item com o mesmo código de grupo. Ou seja, se tenho um item de código 70090521, que o código de grupo é 029 - MATERIAIS E OPME, não posso inserir outro procedimento - como 70090548 - que tem o mesmo código de grupo 029 - MATERIAIS E OPME.
         3. 
      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' e  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.
         2. Não poderá repetir no grid o mesmo código de procedimento ou código da tabela (BJG_CODPAD).
         3. 
      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 iteme 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_CDGRUPCODGRU, BJG_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_CDGRUPCODGRU, BJG_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. Após as validações acima, necessitamos gravar ou atualizar as seguintes tabelas:
   1. BR8 - Tabela Padrão
   2. BA8 - Tabela Dinâmica de Eventos
   3. BD4 - Unidade de Saúde
   4. BTQ – Tabela de Terminologias
   5. B6F – Tabela de Histórico de Importações realizadas
   6. BF8 - Tabelas de Honorários.
      1. A BF8 só será criada se no campo B6G_CRITDE estiver como SIM. Caso contrário, não será gravada
2. No arquivo SIMPRO® – temos o código próprio da SIMPRO® e para maioria dos itens, temos o código TUSS equivalente.
   1. Se não existir código TUSS no registro analisado, deve ser gravado ou atualizado na TDE própria (informado no cadastro de configuração – B6G);
   2. Se existir o código TUSS no registro, devemos verificar na TDE própria – informada no cadastro da configuração (B6G) – se temos o código SIMPRO® do item cadastrado e se está com a data de vigência finalizado. Se não estiver com data de finalização (BD4_VIGFIM), devemos finalizar a vigência, utilizando a data do ParamBox (Data da mensagem da SIMPRO®) menos 1 dia. Ou seja, se foi informado 10/10/2021, devemos subtrair um dia, colocando no campo BD4_VIGFIM o valor 09/09/20210. 
      1. Na sequência, verificar se já existe o código TUSS cadastrado, para inclusão ou alteração dos dados.
   3. Para cada registro gravado, no campo BD4_CHVIMP, deve ser colocado a chave de registro de relacionamento, com as informações “SIMPRO| + código da atualização + ”|” + Tipo do Procedimento + “|” + Tipo Valor”. Ou seja, é a concatenação dos campos “SIMPRO|” + código da atualização (mensagem) informada no ParamBox + “|“ + B6G_TIPPRO + “|” + B6G_TIPO. Simplificando, se foi informando no ParamBox o código da atualização 3321, e estamos importando um arquivo de Material (B6G_TIPPRO = 1) e o valor Preço de Fábrica (B6G_TIPO = 2), o campo BD4_CHVIMP vai receber o valor como: SIMPRO|3321  |1|2.  
   4. Se existir um BD4 para evento, e na chave de relacionamento (BD4_CHVIMP), o código da atualização for menor que o atual, essa vigência será finalizada com a data do ParamBox (Data da mensagem da SIMPRO®) menos um dia, para gravar a nova BD4 com a nova vigência, com os dados necessários.
      1. Só gravar se tiver alteração de valor.  Se os dados são iguais, mesmo em atualizações diferentes, não precisa executar o passo acima.
   5. Ao gravar os registros, criar ou atualizar os mesmos na Tabela de Terminologia BTQ, terminologia 64, conforme padrão TISS. Atualizar da seguinte maneira:
      1. BTQ_CODGRU - Se medicamento, gravar o valor "030". Para os demais, gravar "029".
      2. BTQ_DESGRU - Se medicamento, gravar o texto "MEDICAMENTO". Para os demais, gravar "MATERIAIS E OPME".
      3. BTQ_FENVIO - Gravar o texto "CONSOLIDADO".
         • Para conhecimento: Grupo 029 - MATERIAIS E OPME / Grupo 030 - MEDICAMENTOS
3. No final da importação, gravar os dados pertinentes na tabela B6F - Importações Brasíndice, para efeitos históricos e consultar os registros importados. 

D) Exclusão das Importações

1. 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 tantoO usuário pode deletar alguma importação realizada, bastando no browser do PLSSIMPRO posicionar no registro desejado e clicar no botão Excluir.  Contudo, temos algumas regras a serem seguidas:
3. Ao solicitar a exclusão do registro posicionado, devemos garantir se é o último importado, pela sequência do campo BD4_CHVIMP, que armazena o código da mensagem (atualização) da SIMPRO.  Se tentar excluir qualquer um que não seja o último importado, o sistema deve proibir, de acordo com o tipo de produto e valor.
   1. Por exemplo, importei à atualização 3021 - Material - PFB e no outro mês, importei o 3121 - Material - PFB.
   2. Se tentar excluir o 3021 - Material - PFB, o sistema não deve deixar, pois existe atualização superior, que pode ter finalizado e criado novas BD4 com outros vigências.  No nosso exemplo, só podemos excluir o 3121 - Material - PFB, pois é a última importação.
Caso possa excluir, conforme regra acima, devemos:
4. Deletar os registros BD4 relacionados a essa importação, pelo campo de relacionamento BD4_CHVIMP.
5. Após deletar o BD4 relacionado, devemos reabrir a vigência do último BD4 disponível para o item, seguindo a cronologia do campo BD4_CHVIMP.  
   • Se existir registro BD4 anterior, o campo BD4_VIFGIM deve ser limpo, para ser utilizado no sistema;
   • Se não existir nenhum BD4 anterior (imagine um item adicionado nessa versão excluída), a BA8 relacionada ao BD4 deve ser excluída, pois não pode existir um BA8 sem BD4;
   • Se a BA8 foi excluída, devemos atualizar na BR8 - relacionada ao registro da BA8 - o campo BR8_BENUTL como Não, já que o item não existe mais na BA8.
Ou seja, como visto acima, a exclusão deve ser em "cascata", obedecendo aos critérios definidos.  Logo, se excluir uma BD4 e tiver outro registro BD4 para reabrir a vigência, apenas limpo a data final e o processo acabou por aí.  Se não, tenho que deletar os demais envolvidos, que é a BA8 e BR8, para manter a consistência dos registros.

03. Tela de Importação / Configuração SIMPRO® 

Âncora
NEW NEW

...