Histórico da Página
Índice
Índice
CONTEÚDO
- Visão Geral
- Criando a Obrigação para a DMED
- Exemplo de utilização da API
- Configuração JOBS
- Processamento
- Validação
- Arquivo
- Tela Despesas Analíticas
- Outras Ações / Ações relacionadas
- Outras Ações / Ações relacionadas
- Tela Despesas Sintéticas
- Principais Campos e Parâmetro
- Principais Campos e Parâmetro
- Tela Histórico de Arquivos
- Incluir Recibo
- Tabelas utilizadas
01. Visão Geral
1 – O que é a DMED?
...
Na tela da Central de Obrigações, Clique em incluir no Grid "Obrigações", na tela de Obrigações informe sua operadora, coloque uma descrição e no campo Tipo selecione a opção DMED, com isso o preenchimento dos campos será automático e ao salvar a tela, a obrigação será criada.
03. Exemplo De Utilização
...
da API
A DMED gerada através da Central de obrigações não trata "Prestadora de serviços médicos e de saúde".
Sendo assim geramos o arquivo da seguinte maneira. Repare que não haverá PSS, RPPSS e BRPPSS pois são itens específicos do Prestador de Saúde.
DMED - Declaração de serviços médicos e de saúde
RESPO - Responsável pelo preenchimento
DECPJ - Declarante Pessoa Jurídica
OPPAS - Operadora de plano privado de assistência à saúde.
TOP - Titular do plano
RTOP - Reembolso titular do plano
DTOP - Dependente do titular
RDTOP - Reembolso do Dependente
FIMDMED
API
Através da API analyticDmedExpenses recebemos um POST com as despesas e as gravamos na tabela B2Y (Despesas analíticas).
Quem já utiliza o SIB na Central de Obrigações basta enviar a Operadora + Matrícula do Titular e dependente (quando for o caso), que conseguimos buscar Nome, CPF , Data de nascimento, Relação de dependência da tabela de beneficiários. Entretanto, quem não utiliza o SIB, deve enviar todas as informações necessárias para determinado Registro.
Abaixo segue o exemplo de como enviar o JSON para os 4 identificadores de Registro.
Identificador de Registro - TOP
{
"healthInsurerCode":"000000",
"ssnHolder":"76116313221",
"titleHolderEnrollment":"00010001000011005",
"holderName":"PAULO SILVA TITULAR",
"expenseKey":"0000000000000000000000000000000000000001",
"expenseAmount":1000,
"period":"202010",
"exclusionId":"0"
}
Identificador de Registro - RTOP
API
Através da API analyticDmedExpenses recebemos um POST com as despesas e as gravamos na tabela B2Y (Despesas analíticas).
Quem já utiliza o SIB na Central de Obrigações basta enviar a Operadora + Matrícula + CPF do Titular que o sistema já busca e grava o nome pelo que encontrou no cadastro de beneficiário (B3K). Já o dependente (quando for o caso), pode vir Operadora + Matrícula +Nome que o sistema atualiza a data de nascimento e a relação de dependência da tabela de beneficiários. Entretanto, quem não utiliza o SIB, deve enviar todas as informações necessárias para determinado Identificador de Registro.
Inclusão de Despesa via API.
- Basta enviar um Json conforme apresentado abaixo. O campo exclusionId deve estar como "0".
Alteração de Despesa via API.
- Envie um Json conforme exemplo abaixo, com o campo exclusionId = "0" e o campo expenseKey = a uma chave já enviada. Para alterar uma despesa já enviada, basta mandá-la novamente. Caso ela já tenha sido processada pelo JOB de Processamento, o sistema irá retirar o valor da tabela de movimentação e excluir o registro gravado pela API anteriormente.
Sendo assim, na próxima vez que eu rodar o JOB de processamento o valor que acabei de alterar será adicionado as movimentações.
Excluindo Despesa via API.
- Envie um Json conforme exemplo abaixo, com o campo exclusionId = "1" e o campo expenseKey = a uma chave que já existe e você queira excluir. Neste processo, o sistema irá gerar um registro de exclusão na tabela B2Y e posteriormente ao rodar o JOB de Processamento (SVCPRCDMED) estes valores serão consolidados.
Exemplo:
Em Outubro foi enviado uma despesa para o titular com a expenseKey ="00000000000000000000001" valor 1.000,00 e exclusionId = "0"
Em Novembro foi enviado uma nova despesa para o titular com a expenseKey ="00000000000000000000002" valor 1.500,00 e exclusionId = "0"
Em Dezembro (por exemplo) foi rodado o JOB de processamento, isso fez que o sistema gere um registro TOP (titular) na tabela de movimentações (B2W) de 2.500,00.
Ainda em dezembro, por algum motivo, resolvo excluir a despesa de outubro e assim envio via API a despesa expenseKey ="00000000000000000000001" e exclusionId = "1".
Essa despesa fica gravado normalmente até que rodamos o JOB de processamento novamente, ai sim, o sistema vai retirar da tabela B2W os 1.000,00 que exclui.
Exemplo de JSON para os 4 identificadores de Registro.
Identificador de Registro - TOP
{
"healthInsurerCode":"000000",
"ssnHolder":"76116313221",
"titleHolderEnrollment":"00010001000011005",
"holderName":"PAULO SILVA TITULAR",
"expenseKey":"0000000000000000000000000000000000000001",
"expenseAmount":1000,
"period":"202010{
"healthInsurerCode":"000000",
"ssnHolder":"76116313221",
"titleHolderEnrollment":"00010001000011005",
"holderName":"PAULO SILVA TITULAR",
"expenseKey":"0000000000000000000000000000000000000002",
"refundAmount":2000,
"previousYearRefundAmt":2000,
"period":"202010",
"providerSsnEin":"39613205861",
"providerName":"NOME PRESTADOR",
"exclusionId":"0"
}
Identificador de Registro - DTOPRTOP
{
"healthInsurerCode":"000000",
"ssnHolder":"76116313221",
"titleHolderEnrollment":"00010001000011005",
"holderName":"PAULO SILVA TITULAR",
"dependentSsnexpenseKey":"147544605530000000000000000000000000000000000000002",
"dependentEnrollmentrefundAmount":"00010001000011108"2000,
"dependentNamepreviousYearRefundAmt":"DEPENDENTE TITULAR"2000,
"dependentBirthDateperiod":"20091013202010",
"dependenceRelationshipsproviderSsnEin":"0339613205861",
"expenseKeyproviderName":"0000000000000000000000000000000000000003NOME PRESTADOR",
"expenseAmountexclusionId":1000,
"period":"202010",
"exclusionId":"0"
}
Identificador de Registro - RDTOPDTOP
{
"healthInsurerCode":"417505000000",
"ssnHolder":"76116313221",
"titleHolderEnrollment":"00010001000011005",
"holderName":"PAULO SILVA TITULAR",
"dependentSsn":"14754460553",
"dependentEnrollment":"00010001000011108",
"dependentName":"DEPENDENTE TITULAR",
"dependentBirthDate":"20091013",
"dependenceRelationships":"03",
"expenseKey":"00000000000000000000000000000000000000040000000000000000000000000000000000000003",
"refundAmountexpenseAmount":2000,
"previousYearRefundAmt":20001000,
"period":"202010",
"providerSsnEinexclusionId":"39613205861",0"
}
Identificador de Registro - RDTOP
{
"providerNamehealthInsurerCode":"NOME PRESTADOR000000",
"exclusionIdssnHolder":"076116313221"
}
...
04. Configuração JOBS
Para configurarmos os JOBS utilize o Wizard Configurador, acesse Atualizações > Wizard Configurador > Selecione o processo da DMED > Em outras ações selecione a operadora Padrão e a Periodicidade que será executado o JOB > Avançar para finalizar o processo de configuração dos JOBS.
Após a configuração, teremos os JOBS de:
SVCPRCDMED - Processa as despesas da B2Y (Despesas Analíticas) e gera a tabela da B2W (Movimentações DMED).
SVCALDMEDG - Valida os itens que foram gerados na B2W.
05. Processamento
Tendo as despesas gravadas na tabela B2Y, rodamos o JOB SVCPRCDMED que gera a tabela de Despesas Sintéticas (B2W) classificando os registros em TOP, RTOP, DTOP ou RDTOP através dos dados que foram enviados. Sabemos que para geração do arquivo ainda faltam os Identificadores RESPO, DECPJ e OPPAS, porém eles serão lançados diretamente no arquivo da DMED. Logo, eles não precisam ser processados.
06. Validação
As despesas analíticas estão disponíveis na tabela B2W com o Status Pendente validação. Neste caso rodamos o JOB SVCALDMEDG e estas despesas analíticas são validadas. Caso haja alguma inconsistência de acordo com o Layout da DMED esta movimentação ficará com status "Criticado."
Críticas de validações:
...
O campo CPF/CNPJ do prestador inválido.
...
O campo é de preenchimento obrigatório, deve ser preenchido com um CPF ou CNPJ válido.
...
O campo CPF do dependente é inválido.
...
O campo é de preenchimento obrigatório para declaração de dependentes do titular, deve ser preenchido com um CPF válido.
...
O campo valor da despesa inválido.
...
Quando o titular não possui beneficiários, o campo valor da despesa deve possuir valor maior que zero ( B2W_VLRDES > 0) .
...
Esse registro RTOP deve estar associado a um registro do tipo TOP.
...
Enviar para a Central de Obrigações o registro do tipo TOP.
...
O Campo Data de Nascimento do Dependente inválido.
...
O Campo Data de Nascimento é obrigatório para maiores de 18 anos que não tenham informado CPF. Campo de tamanho 8 e padrão AAAAMMDD'
...
Esse registro DTOP deve estar associado a um registro do tipo TOP.
...
,
"titleHolderEnrollment":"00010001000011005",
"holderName":"PAULO SILVA TITULAR",
"dependentSsn":"14754460553",
"dependentEnrollment":"00010001000011108",
"dependentName":"DEPENDENTE TITULAR",
"dependentBirthDate":"20091013",
"dependenceRelationships":"03",
"expenseKey":"0000000000000000000000000000000000000004",
"refundAmount":2000,
"previousYearRefundAmt":2000,
"period":"202010",
"providerSsnEin":"39613205861",
"providerName":"NOME PRESTADOR",
"exclusionId":"0"
}
Campo | Descrição | Obrigatório na API |
---|---|---|
healthInsurerCode | Operadora | Sim |
ssnHolder | CPF Titular | Sim |
titleHolderEnrollment | Matrícula Titular | Não |
holderName | Nome Titular | Não |
dependentSsn | CPF Dependente | Sim (quando despesa for do dependente) |
dependentEnrollment | Matrícula Dependente | Não |
dependentName | Nome Dependente | Sim (quando despesa for do dependente) |
dependentBirthDate | Data de Nascimento | Não |
dependenceRelationships | Relação de Dependência | Não |
expenseKey | Chave | Sim |
expenseAmount | Valor Despesa | Não |
refundAmount | Valor Reembolso | Não |
previousYearRefundAmt | Valor Reembolso Ano Anterior | Não |
period | Período | Sim |
providerSsnEin | CPF/CNPJ Prestador | Sim (Quando tratar-se de Reembolso) |
providerName | Nome Prestador | Não |
exclusionId | Exclusão | Sim |
04. Configuração JOBS
Para configurarmos os JOBS utilize o Wizard Configurador, acesse Atualizações > Wizard Configurador > Selecione o processo da DMED > Em outras ações selecione a operadora Padrão e a Periodicidade que será executado o JOB > Avançar para finalizar o processo de configuração dos JOBS.
Após a configuração, teremos os JOBS de:
SVCPRCDMED - Processa as despesas da B2Y (Despesas Analíticas) e gera a tabela da B2W (Movimentações DMED).
SVCALDMEDG - Valida os itens que foram gerados na B2W.
Os Jobs criados pelo wizard acima, ficam dispostos na tela Schedule do configurador. Eles são executados de acordo com a parametrização feita acima.
Quando estamos posicionado em um compromisso da DMED, conseguimos visualizar a execução desses JOBS acessando a tela de Monitor de Jobs.
05. Responsáveis - RESPO
Na tela de Responsáveis, tenho cadastrado o responsável de diversas Operadoras (quando houver mais de uma) indicando se o cadastro está ou não ativo.
Na rotina de validação das críticas, é verificado se tenho um responsável para Operadora que estou validando, caso não tenha é apresentado a crítica DM14 - Deve existir um responsável ativo.
Na geração do arquivo, o sistema identifica qual Operadora esta associada ao compromisso e insere as informações no arquivo DMED baseado nesse cadastro.
06. Tela Despesas Analíticas
Esta tela permite a visualização, inclusão e alteração de despesas.
OBS: Só é possível a alteração e exclusão de registros inseridos de forma manual.
Visualização:
Lista registros da tabela B2Y, permitindo filtrar, carregar mais resultados e alterar ou excluir.
Inclusão:
Insere um novo registro na tabela B2Y, que posteriormente será processado pelo JOB SVCPRCDMED.
Alteração:
Altera um registro que foi incluído manualmente.
Exclusão:
Exclui um registro que foi incluído manualmente.
07. Tela Movimentos
Tendo as despesas gravadas (tabela B2Y), rodamos o JOB SVCPRCDMED que processa as Despesas e gera os Movimentos (tabela B2W) classificando os registros em TOP, RTOP, DTOP ou RDTOP. Sabemos que para geração do arquivo ainda faltam os Identificadores RESPO, DECPJ e OPPAS, porém eles serão lançados diretamente no arquivo da DMED. Logo, eles não precisam ser processados pelo Job. Essa tela tem como objetivo mostrar os itens que foram processados das Despesas Analíticas (B2Y) e geraram os Movimentos (B2W) .expenseAmount
Para acessar: Central de Obrigações/ DMED/ Movimentos. Na tela teremos os botões:
- Visualizar: Abre a tela de visualização, no item em que está posicionado.
- Pesquisar: Exibe um filtro de pesquisa que permite a especificação de um filtro.
- Validar Itens: Valida os itens que foram processados verificando se estão de acordo com as regras.
- Críticas: Abre a tela de Críticas para os itens de Movimentos.
Status da tela:
Amarelo=Pendente Validação
Azul=Pronto para o Envio
Vermelho=Criticado
Verde=Enviado Receita Federal
08. Validação
As Movimentações estão disponíveis na tabela B2W com o Status Pendente validação. Ao executar o JOB SVCALDMEDG estes registros são validados. Caso haja alguma inconsistência de acordo com o Layout da DMED esta movimentação ficará com status "Criticado (vermelho)", caso não
encontre inconsistência status ficará como "Pronto para o Envio (Azul)". Antes de rodar a validação o status é amarelo "Pendente Validação"
Também é possível rodar o JOB de validação direto da tela de movimentações clicando no botão "Validar Itens".
Críticas de validações:
Código | Crítica | Solução |
---|---|---|
DM01 | Nome do Beneficiário inválido. | O campo é de preenchimento obrigatório |
DM02 | Nome do Prestador inválido. | O campo é de preenchimento obrigatório, e no máximo de 60 posições para o nome da pessoa física. Para PJ o tamanho é de no máximo 150 posições. |
DM03 | Relação de Dependência é inválida. | O campo é numérico de tamanho 2 e deve seguir conforme tabela de Relação de Dependência (03,04,05,06,08 e 10). |
DM05 | O campo CPF do titular está inválido. | O campo é de preenchimento obrigatório, deve ser preenchido com um CPF válido. |
DM06 | O campo CPF/CNPJ do prestador inválido. | O campo é de preenchimento obrigatório, deve ser preenchido com um CPF ou CNPJ válido. |
DM07 | O campo CPF do dependente é inválido. | O campo é de preenchimento obrigatório para declaração de dependentes do titular, deve ser preenchido com um CPF válido. |
DM08 | O campo valor da despesa inválido. | Quando o titular não possui beneficiários, o campo valor da despesa deve possuir valor maior que zero ( B2W_VLRDES > 0) . |
DM09 | Esse registro RTOP deve estar associado a um registro do tipo TOP. | Enviar para a Central de Obrigações o registro do tipo TOP. |
DM10 | O Campo Data de Nascimento do Dependente inválido. | O Campo Data de Nascimento é obrigatório para maiores de 18 anos que não tenham informado CPF. Campo de tamanho 8 e padrão AAAAMMDD' |
DM12 | Esse registro DTOP deve estar associado a um registro do tipo TOP. | Enviar para a Central de Obrigações o registro do tipo TOP. |
DM13 | Esse registro RDTOP deve estar associado a um registro do tipo DTOP. | Enviar para a Central de Obrigações o registro do tipo DTOP. |
DM14 | Deve existir um responsável ativo. | Realize o cadastro de um responsável para operadora. |
09. Arquivo
A DMED gerada através da Central de obrigações, não trata "Prestadora de serviços médicos e de saúde".
Sendo assim geramos o arquivo da seguinte maneira. Repare que não haverá PSS, RPPSS e BRPPSS pois são itens específicos do Prestador de Saúde.
DMED - Declaração de serviços médicos e de saúde
RESPO - Responsável pelo preenchimento
DECPJ - Declarante Pessoa Jurídica
OPPAS - Operadora de plano privado de assistência à saúde.
TOP - Titular do plano
RTOP - Reembolso titular do plano
DTOP - Dependente do titular
RDTOP - Reembolso do Dependente
FIMDMED
Para gerarmos o arquivo acessamos o Painel de Obrigações > posicionamos no Compromisso desejado > Clicamos no botão Obrigações e Gerar arquivo de envio, onde teremos os parâmetros a serem preenchidos.
Parâmetros Geração DMED:
Ano referência: Ano de referência do arquivo.
Declaração Retificadora:
N - Original → Arquivo primário a ser gerado.
S - Retificadora → Significa que o arquivo anterior foi enviado com ano errado e será atualizado nessa geração.
Número do recibo: Número a ser preenchido somente quando for Retificadora para identificação do anterior.
CNES: Cadastro Nacional de Estabelecimento de Saúde.
CPF Responsável Perante o CNPJ: CPF Responsável.
Situação da Declaração:
N - Não Especial → deve conter as informações relativas aos valores recebidos durante o ano-calendário (anterior).
S - Especial → Quando o declarante incorrer nas situações especiais de extinção pelo encerramento da liquidação, pela fusão, pela incorporação, ou cisão total, ocorridas no ano-calendário, deve apresentar DMED com informações relativas aos valores recebidos até a data do evento.
Data do evento: Só será preenchido quando a Situação da Declaração for Especial.
Identificador da estrutura do layout: Depende do ano de envio para a opção a ser selecionada.
Responsável: Ao clicar na lupa, o sistema apresenta o cadastro de Responsáveis filtrando por Operadora do compromisso e cadastro ativo.
Diretório do arquivo: Local onde o arquivo será salvo.
10. Tela Histórico de Arquivos
Esta tela tem o histórico de todas as gerações de arquivos seja original ou retificado para determinado calendário. Ao terminar a geração do arquivo, deve-se entrar nesta tela para informar o número do recibo que a Receita Federal nos apresentou.
Este número do recibo pode ser alterado caso tenha necessidade. A partir do momento que o número do recibo for inserido, ao voltar à tela principal da Central, irá reparar que o compromisso foi finalizado.
Botões:
Incluir Recibo: Inclui e altera um número de recibo
Download de Arquivo: Baixa o arquivo da DMED gerado para o local indicado.
Excluir: Exclui o histórico, porém só permite a exclusão de registros que não foram para Receita Federal (Não tem recibo informado).
07. Arquivo
Para gerarmos o arquivo acessamos o Painel de Obrigações > posicionamos no Compromisso desejado > Clicamos no botão Obrigações e Gerar arquivo de envio, onde teremos os parâmetros a serem preenchidos.
Parâmetros Geração DMED:
Ano referência: Ano de referência do arquivo.
Declaração Retificadora:
N - Original → Arquivo primário a ser gerado.
S - Retificadora → Significa que o arquivo anterior foi enviado com ano errado e será atualizado nessa geração.
Número do recibo: Número a ser preenchido somente quando for Retificadora para identificação do anterior.
CNES: Cadastro Nacional de Estabelecimento de Saúde.
CPF Responsável Perante o CNPJ: CPF Responsável.
Situação da Declaração:
N - Não Especial → deve conter as informações relativas aos valores recebidos durante o ano-calendário (anterior).
S - Especial → Quando o declarante incorrer nas situações especiais de extinção pelo encerramento da liquidação, pela fusão, pela incorporação, ou cisão total, ocorridas no ano-calendário, deve apresentar DMED com informações relativas aos valores recebidos até a data do evento.
Data do evento: Só será preenchido quando a Situação da Declaração for Especial.
Identificador da estrutura do layout: Depende do ano de envio para a opção a ser selecionada.
Diretório do arquivo: Local onde o arquivo será salvo.
08. Tela Despesas Analíticas
Outras Ações / Ações relacionadas
...
09. Tela Despesas Sintéticas
Principais Campos e Parâmetros
...
10. Tela Histórico de Arquivos
...
HTML |
---|
<!-- esconder o menu --> <style> div.theme-default .ia-splitter #main { margin-left: 0px; } .ia-fixed-sidebar, .ia-splitter-left { display: none; } #main { padding-left: 10px; padding-right: 10px; overflow-x: hidden; } .aui-header-primary .aui-nav, .aui-page-panel { margin-left: 0px !important; } .aui-header-primary .aui-nav { margin-left: 0px !important; } </style> |
...