CONTEÚDO

  1. Visão Geral
  2. Detalhamento
  3. Nova tela de cadastro de Corpo Clínico e premissas
  4. Alterações e Protótipos
  5. Tabelas utilizadas


01. VISÃO GERAL 

      A presente especificação visa detalhar as regras iniciais da nova funcionalidade no módulo SIGAPLS, referente a DPS - Declaração do Plano de Saúde, obrigação acessória, inerente as Operadoras de Saúde, situadas na cidade de São Paulo, que são referidas na Lei 13.701, de 24/12/03, nos subitens 4.22 e 4.23 da lista do “caput” do artigo 1º, que são:

     Assim, a especificação terá como base essas legislações Municipais, bem como as regras e demais informações contidas no manual do DPS - disponível no endereço http://notadomilhao.prefeitura.sp.gov.br/cidadao/informacoes-gerais/manuais-arquivos/manual_dps.pdf/view (acesso em 08/02/2021, às 11:00) - e no manual de Repasse, que contêm e descreve de forma técnica o layout do arquivo txt a ser enviado para o sistema de NF-e, disponível em http://notadomilhao.prefeitura.sp.gov.br/cidadao/informacoes-gerais/manuais-arquivos/manual_dps_repasses.pdf/view (acesso em 08/02/2021, às 11:15). 

     Por se tratar de tema técnico e fiscal, a presente especificação poderá e deve passar por atualizações em seu conteúdo, visto que deverá passar por crivos técnicos (de desenvolvimento e legal), bem como por análise pelo(s) cliente(s)/usuário(s), que poderá(ão) trazer outros visos à presente especificação, de forma a enriquecer o material e entrega do produto final (a funcionalidade).


02. Detalhamento 

     Após análises iniciais das documentações disponíveis e, com os processos realizados no sistema (tanto do módulo SIGAPLS e Financeiro), chegamos no seguinte panorama, para a busca das informações que devem constar no arquivo de DPS, detalhados abaixo:

  1. Conforme já evidenciado, quando a Nota Fiscal de cobrança é emitida pela Operadora (o lote de cobrança para os beneficiários), o ISS é calculado corretamente e enviado para a prefeitura, via integração do módulo financeiro. Logo, aqui não é necessário nenhuma intervenção.
  2. Quando a Operadora recebe a Nota Fiscal do Prestador de serviços, deve dar entrada dessa nota no sistema, via Documento de Entrada (módulo SIGACOM, em Atualizações / Movimentos / Documento Entrada). Assim, esta nota de entrada deve ser considerada no DPS, desde que o prestador de saúde possua o código de serviço citado no item 1.4 do manual da DPS (item 4);
  3. Quando a Operadora é obrigada a emitir a NFTS - Nota Fiscal Eletrônica do Tomador/Intermediário de Serviços - quando o prestador contratado para execução dos serviços não emitir Nota Fiscal (como profissionais autônomos, que emitem recibos) ou para prestadores - pessoa jurídica - situados fora do município de São Paulo.
    1. Neste caso, a emissão da NFTS segue as mesmas etapas de inclusão de um Documento de Entrada no sistema, conforme item 2 deste tópico, mas devendo colocar no campo Espécie do Documento (CESPECIE - F1_ESPECIE), o valor NFS, conforme documento explicativo em NFT0001_Procedimentos_Nota_Fiscal_Tomador_Serviços (dúvidas acerca desse item devem ser direcionadas para o departamento Fiscal / Compras).
    2. A NFTS só pode ser emitida para os prestadores que possuam o código de serviço citado no item 1.4 do manual da DPS (item 4).
  4. Tanto o prestador que emite Nota Fiscal ou para aqueles que se façam necessário o lançamento da NFTS, só serão considerado para a DPS os prestadores que possuam o código de serviço que estejam de acordo com o item 1.4 do manual do DPS, onde:
    1. Códigos
      CódigoDescrição
      04073Médico e biomédico (profissional autônomo)
      04111Medicina e biomedicina (regime especial - sociedade)
      04146Análises clínicas, patologia, eletricidade médica, radioterapia, quimioterapia, ultra-sonografia, ressonância magnética, radiologia, tomografia e congêneres (profissional autônomo)
      04139Análises clínicas
      04154Análises clínicas, patologia, eletricidade médica, radioterapia, quimioterapia, ultra-sonografia, ressonância magnética, radiologia, tomografia e congêneres (regime especial – sociedade)
      04189Hospitais
      04197Clínicas e casas de saúde
      04219Ambulatórios e prontos-socorros
      04278Acupunturista (profissional autônomo)
      04340Enfermeiro (profissional autônomo)
      04359Enfermagem, inclusive serviços auxiliares (regime especial - sociedade)
      04375Técnico em enfermagem, inclusive serviços auxiliares (profissional autônomo)
      04421Fisioterapeuta (profissional autônomo)
      04430Fisioterapia (regime especial - sociedade)
      04499Fonoaudiólogo (profissional autônomo)
      04502Fonoaudiologia (regime especial - sociedade)
      04545Terapeuta ocupacional (profissional autônomo)
      04553Terapia ocupacional (regime especial - sociedade)
      04596Terapeuta de qualquer espécie destinado ao tratamento físico, orgânico e mental, inclusive massoterapia, naturologia e naturopatia (profissional autônomo)
      04650Obstetra (profissional autônomo)
      04677Obstetrícia (regime especial - sociedade)
      04723Dentista (profissional autônomo)
      04731Odontologia (regime especial - sociedade)
      04871Ortóptico (profissional autônomo)
      04901Ortóptica (regime especial – sociedade) 
      05053Protético (profissional autônomo)
      05096Próteses sob encomenda (regime especial - sociedade)
      05134Psicólogo, clínico ou não (profissional autônomo)
      05142Psicologia, clínica ou não (regime especial - sociedade)
      05223Bancos de sangue, leite, pele, olhos, óvulos, sêmen e congêneres
      05542Prestação de serviço não referenciado em outro código do grupo Saúde, exceto os subitens 4.22 e 4.23 e os subitens do item 5, prestado por profissional autônomo
      05576Patologia e eletricidade médica
      05584Casas de recuperação
      05539Farmacêutico (profissional autônomo) 
      05540Nutricionista (profissional autônomo).
  5. O Documento de Entrada - recebido via Nota Fiscal do prestador ou pela emissão da NFTS - são gravados nas mesmas tabelas: SF1 - Cabeçalho das NF de Entrada e SD1 - Itens das NF de Entrada.
    1. Assim, os dados terão que ser pesquisados nas tabelas SF1 e SD1.  Os dados principais estarão no cabeçalho - SF1 - mas é no item que temos o código do serviço armazenado
    2. Pela estrutura arquivo txt de DPS, os dados principais serão buscados do cabeçalho da guia - SF1.  Contudo, para pesquisar os dados específicos - como o Código de Serviço - é necessário pesquisar na tabela de itens (SD1), pois é no campo D1_CODISS que fica armazenado o código de serviço.
      1. Essa informação do D1_CODISS é carregada automaticamente, ao selecionar o tipo de produto (proveniente da tabela SB1 - Descrição Genérica do Produto, no campo B1_CODISS).
      2. REVISAR: Aqui, uma dúvida: E se na nota do prestador tiver outros itens, além do produto com ligação ao Código de Serviço, por exemplo, uma taxa postal? Se usar o valor total da nota (SF1) e o de ISS, estaria correto? Ou será que teríamos que pegar o valor total e o ISS de cada item que pode ser contabilizado na DPS, na tabela SD1).
  6. Assim, observando esse ciclo, conseguimos atender atender ao proposto no documento da DPS, que pode ser resumido na imagem abaixo:
  7. Sobre os prazos de entrega da DPS, no manual temos:
    1. "O plano de saúde deverá gerar a DPS até o dia 5 (cinco) do mês seguinte ao da prestação dos serviços."
    2. "O plano de saúde deverá gerar a DPS até o dia 5 (cinco) do mês seguinte ao da prestação dos serviços. No entanto, o plano de saúde poderá declarar gradativamente os repasses desde o primeiro dia do mês de incidência, sendo recomendada a geração e envio de vários arquivos ao longo do mês."
    3. REVISAR: Em nenhum momento encontramos a possibilidade de "postergar" uma nota para outro mês, logo, todo movimento que ocorreu, por exemplo, em fevereiro, deve ser enviado até o 5 dia do mês seguinte, que seria março. 
    4. REVISAR: E quando uma nota, por exemplo, emitida em janeiro de 2021, chegou na Operadora apenas no dia 15 de fevereiro? Nesse caso, essa nota deve ser contabilizada na incidência de 01/2021 ou 02/2021?
      1. Assim, devemos considerar a data de Emissão (F1_EMISSAO) ou data de Digitação da Nota (F1_DTDIGIT)?
  8. Sobre o processo de retificação e exclusão, temos:
    1. "Observado o prazo previsto no item 1.5, a DPS poderá ser retificada, desde que não ultrapasse 3 (três) anos contados a partir do 1º dia do exercício seguinte ao da incidência da declaração, e desde que o Imposto relativo à declaração a ser retificada não tenha sido enviado para inscrição em Dívida Ativa."
    2. "Para excluir um documento e seu respectivo repasse, o campo “Situação do Documento” do registro tipo 7 deverá ser preenchido com “E” (Exclusão);"



03. Nova tela de Controle de DPS 

  1. Com o entendimento inicial sobre o detalhamento, notamos que será necessário criar uma rotina para a geração e controle de DPS no sistema, para controle dos itens gerados e as novas gerações futuras (já que pode ser algo parcial), tanto para histórico como para retificações futuras.
  2. Para tanto, inicialmente pensamos na criação de 3 tabelas, que irão armazenar, respectivamente, o cabeçalho, os detalhes das notas e uma tabela de histórico.
    1. Ao entrar na rotina, será exibida inicialmente a tela com o cabeçalho das DPS, sequenciados por um código único sequencial gerado pelo sistema (GetSX8NUM) e pela competência - todos os processamentos devem ser feitos pela competência escolhida. Aqui, podemos entender como o "Cabeçalho" - referente ao arquivo TXT, além de outras informações pertinentes ao sistema.  [Tabela 1 REVISAR: B__].
      1. Nessa tela, poderemos visualizar o cabeçalho, com os dados pertinentes aos item de cabeçalho do arquivo txt, bem como outras informações do sistema;
      2. Ao clicar no botão Selecionar, o sistema irá exibir os detalhes de todas as NFS-e e NFTS encontradas para a competência selecionada.
      3. No botão Outras Ações, teremos a rotina para Gerar arquivo txt do registro selecionado, no layout da prefeitura - conforme Manual de Envio de Repasses – Planos de Saúde, além do botão Processar..., que irá chamar a rotina que irá realizar a query nas tabelas SF1 e SD1, para pesquisar e gravar os dados encontrados, que estão de acordo com o Manual da DPS - tópico 2 - e na competência desejada.
        1. Esse ParamBox irá trazer na tela o pergunte, onde o usuário deverá informar o período de competência (não deixar permitir informa incidência inválida, como 20/2020, além de não permitir incidência futura a data atual do sistema, ou seja, se estamos em março de 2021, não posso deixar informar 05/2021).
        2. REVISAR: Será que devemos colocar algum outro parâmetro na pesquisa? Tirando o período de competência/incidência, não existe nenhum outro determinante, pois as regras devem estar conforme tópico 2 da especificação.
        3. Ao clicar no botão OK do ParamBox, o sistema deverá verificar se já existe um cabeçalho aberto para a vigência escolhida. Se não existir, deve criar um cabeçalho ([Tabela 1 REVISAR: B__]), e caso exista, deverá verificar as NFs-e e NFTS cadastradas no período informado, respeitando as regras discutidas no tópico 2, gravando os detalhes na nova [Tabela 2 REVISAR: B__]. 
          1. Como é um processo que pode ser realizado diversas vezes no mês de incidência, a funcionalidade deverá verificar se já existem itens gravados e atualizar com os novos documentos que deram entrada no sistema, ou seja, ir complementando o lote com as novas informações.
          2. REVISAR: 
            1. Uma nota pode ser Cancelada (no Documento de Entrada, o processo é Exclusão - https://centraldeatendimento.totvs.com/hc/pt-br/articles/360018751111-MP-NFE-Como-cancelar-uma-nota-fiscal-eletr%C3%B4nica-). Quando cancelada, será excluída da SF1. 
            2. Assim, caso seja feito o processo automático/manual de procura de dados, caso a nota não conste mais na SF1, mas esteja presente na nova [Tabela 2 - REVISAR: B__], teremos que verificar se já foi gerado algum txt parcial desse registro selecionado, pois caso conste que já tenha sido gerado, nessa situação  e cancelamento de nota, teremos que mudar a situação do documento para Exclusão, pois como o txt foi gerado, entende-se que já foi submetido no portal da prefeitura. Caso ainda conste que não tenha sido gerado o arquivo txt, podemos realizar a exclusão do registro direto na nova [Tabela 2 - REVISAR: B__], pois não consta na prefeitura a existência dessa nota em algum arquivo de DPS.
          3.   Além dessa verificação de novos registros incluídos nas tabelas SF1/SD1, terá que atualizar os dados do cabeçalho, com as informações atuais, como o campo de valor total e outros, que sejam necessários.
        4. No final do processamento manual, deverá emitir um alerta, informando se houve novas inclusões e cancelamentos.
        5. O botão Gerar arquivo txt, quando pressionado, deverá abrir uma janela para que o usuário indique em qual local/pasta deseja salvar o arquivo txt.  Confirmando a geração do arquivo, um status na nova [Tabela 1 REVISAR: B__] deverá ser atualizado para Arquivo Gerado, para o controle nos casos onde um arquivo foi gerado e depois, uma das notas desse arquivo foi cancelada.
    2. Ao clicar no botão Selecionar, deverá trazer os detalhes de todas as notas fiscais encontrada para competência, de acordo com os filtros mencionados no tópico 2 do documento. Aqui, devemos entender como a parte de "Detalhes" - do arquivo txt, além de possuir outras informações de controle do sistema.  [Tabela 2 REVISAR: B__]
      1. Assim, o vínculo entre a [Tabela 2] com a [Tabela 1] se dará pelo código sequencial e período de competência.
      2. Ao clicar no botão de Detalhes da tela de Detalhe da DPS, será exibido o form com todas as informações da Nota encontrada, apenas para conferência do usuário.
      3. IMPORTANTE: Em nenhuma das telas será permitido a alteração dos valores e das informações provenientes das Notas Fiscais e NFTS - das tabelas SF1 e SD1 - por se tratar de informação fiscal. Caso a nota possua erros, deverá ser corrigida diretamente no módulo de Documento de Entrada, sendo essa funcionalidade apenas uma ponte entre a leitura dos dados (conforme parametrização) e a geração do arquivo TXT, para envio à Prefeitura de São Paulo.
  3. A rotina de verificação (query) e preenchimento dos dados nas novas [Tabela 1 REVISAR: B__] e [Tabela 2 REVISAR: B__] poderá ser executada via Schedule, ou seja, programada para rodar sozinha em determinados momentos.
    1. Quando schedulada, verificar se vamos considerar a incidência da data atual do sistema ou deixar passar como um parâmetro, quando estiver configurando o schedule.
    2. O Schedule irá apenas executar as atividades previstas acima, não sendo possível a geração do arquivo txt, que deverá ser gerado pelo usuário, após conferência nas telas e detalhado nos itens anteriores.
  4. A tabela de histórico deverá armazenar as ocorrências da rotina - podendo ter códigos de ocorrência para sua filtragem - , como:
    1. Toda vez que o usuário solicitar a geração do txt (Gerar arquivo txt), armazenar essa solicitação no histórico;
    2. Quando a rotina for schedulada e terminar seu processamento. 
  5. Abaixo, mockup animado das telas:


04. Tabelas  

TABELA 1  - B__

Nome do campoCaracterística
1) Tipo de registro1) Tipo de                                                     registro
2) Tipo de Arquivo2) Tipo de Arquivo
3) Versão do Arquivo3) Versão do Arquivo
4) Inscrição Municipal do Prestador4) Inscrição Municipal do Prestador
5) Incidência5) Incidência
6) Código do serviço prestado relativo ao repasse6) Código do serviço prestado relativo ao repasse




05. TABELAS UTILIZADAS 


<!-- 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>