CONTEÚDO

1. Visão Geral
2. Exemplo de utilização
3. Tela XXX
   1. Outras Ações / Ações relacionadas
      
4. Tela XXX
   1. Principais Campos e Parâmetros
      
5. Tabelas utilizadas

01. VISÃO GERAL

A Declaração do Plano de Saúde (DPS), é uma 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:

• 4.22 (Planos de medicina de grupo ou individual e convênios para prestação de assistência médica, hospitalar, odontológica e congêneres);
• 4.23 (Outros planos de saúde que se cumpram por meio de serviços de terceiros contratados, credenciados, cooperados ou apenas pagos pelo operador do plano mediante indicação do beneficiário).

• Ainda, pela Instrução Normativa SF/SUREM nº 08, de 18 de julho de 2011, os respectivos códigos de serviço atualmente vigentes são:

  Código de Serviço	Item da Lei 13.701/03	Descrição
  05274	4.22	Planos de medicina de grupo ou individual e convênios para prestação de  assistência médica, hospitalar, odontológica e congêneres.
  05312	4.23	Outros planos de saúde que se cumpram através de serviços de terceiros  contratados, credenciados, cooperados ou apenas pagos pelo operador do  plano mediante indicação do beneficiário.

     Desse modo, a funcionalidade de DPS do TOTVS Saúde Planos (Linha Protheus) visa atender a essa obrigação, conforme as legislações Municipais da cidade de São Paulo, 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 descreve de forma técnica o layout do arquivo txt a ser enviado para o sistema de NF-e de São Paulo, 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). 

02. EXEMPLO DE UTILIZAÇÃO

• Como a rotina busca os dados para geração da DPS

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 de faturamento. Logo, aqui não é necessário nenhuma intervenção.

Contudo, 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.  Além disso, deve ser considerado também na DPS as notas quando a Operadora é obrigada a emitir a NFTS - Nota Fiscal Eletrônica do Tomador/Intermediário de Serviços - nas situações onde o prestador contratado para execução dos serviços não emita Nota Fiscal (como profissionais autônomos, que emitem recibos) ou para prestadores - pessoa jurídica - situados fora do município de São Paulo.

Nos casos de lançamento de uma NFTS, as etapas de lançamento é similar a uma nota fiscal, seguindo as mesmas etapas de inclusão de um Documento de Entrada no sistema, 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).

Tanto o prestador que emite Nota Fiscal ou para aqueles que se façam necessário o lançamento da NFTS, só serão considerados 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:

Quadro 1 - Código de Serviço dos Prestadores que devem sair na DPS.

Como as notas são lançadas via Documento de Entrada, os dados das notas e NFTS são gravados nas tabelas: SF1 - Cabeçalho das NF de Entrada e SD1 - Itens das NF de Entrada.  Assim, os dados a serem considerados para a DPS estão armazenados 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.

• Cadastros necessários para a geração da DPS

Conforme discutido no tópico anterior, devido a estrutura da DPS, será necessário realizar a pesquisa dos dados nas tabelas SF1 e SD1.  No entanto, outras tabelas devem estra preenchidas corretamente, para que o sistema identifique quais notas devem constar no arquivo. Abaixo, iremos identificar as tabelas e os campos considerados para a DPS:

1. 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. Deve ser considerado a data de Digitação da NF-e/NFTS (F1_DTDIGIT), na query de busca de dados.
      1. Após reunião, a data de digitação se mostrou a mais certa, visto que podemos dar entrada em uma NF para a competência de fevereiro de 2021, mas a emissão da nota ocorreu em dezembro, pelo prestador.  Isso pode ocorrer pela análise do departamento de contas médicas e outras necessidades da Operadora.
      2. Pela data de digitação, pegamos o movimento atual, independente da data que a NF foi emitida, pois se a nota está dando entrada em fevereiro, significa que é o mês que o Operadora deu entrada da nota no sistema e deve ser considerada na DPS.
      3. Atenção foi dada também a necessidade de incluir notas em competência anteriores, como: estamos no dia 02/02/2021, mas a Operadora quer que uma nota saia na incidência de janeiro de 2021, na DPS.  Mudando a data base do sistema para janeiro, a data de digitação vai ficar em janeiro, possibilitando que ao gerar a DPS, seja reconhecida no mês de janeiro.
2. 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);"
      
      1. No caso, a exclusão só pode existir caso uma DPS já tenha sido enviada, constando a nota que foi cancelada. Logo, se foi gerado uma DPS para uma competência e enviada para a prefeitura e no meio do caminho temos um cancelamento da NF que constava na DPS, ao reenviar a mesma competência, deve ser considerada uma exclusão, visto que temos uma nota cancelada.
         • Ao cancelar uma NF-e / NFTS pelo rotina Documento de Entrada, não existirá aviso algum que aquela nota foi considerada em uma DPS, visto que são módulos totalmente independentes.  É na rotina do PLS que teremos o controle sobre esses itens.
      2. E quando não foi gerada/enviada na DPS, mas no final do mês uma NF é cancelada, basta apenas não considerá-la e enviar o arquivo como normal ("N"), já que no sistema da prefeitura não ocorreu a existência dessa NF.  Ou seja, quando não enviou o arquivo para a Prefeitura e existe o cancelamento de uma Nota Fiscal, basta não considerá-la no envio da DPS posterior, já que no sistema da Prefeitura, não existiu essa nota.
3. Sobre envios parciais da DPS na mesma competência:
   1. "4. Não será necessário gerar um único arquivo contendo todas as informações de repasses que serão considerados na apuração da base de cálculo para a incidência da DPS. O prestador poderá enviar vários arquivos com informações diferenciadas dos documentos fiscais e respectivos repasses."
   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. Da presente forma no manual da DPS, entendemos que o prestador pode enviar arquivos complementares para a Prefeitura, ao invés de gerar apenas um no final do mês.  Contudo, esses arquivos "parciais" devem ser apenas as notas não consideradas nos envios anteriores, pois se enviar uma mesma nota, o sistema irá emitir erro, dizendo que já consta na DPS.
      1. No momento, os envios são totais, não sendo parciais.
      2. Mas caso ocorra de envio parcial, cada lote novo que for gerado na mesma competência - desde que não haja retificação ou exclusão - será considerado um Novo - "N", não podendo constar dados dos outros já enviados. Ou seja, cada envio é individual, apenas com dados novos.
         • Caso seja realizado esse tipo de controle, será necessário criar campo de controle, para que cada envio parcial, não seja considerado os outros registros "já enviados".
         • Ainda na linha de raciocínio acima, de envios parciais, criar mecanismo para imprimir o txt total, independente se foi gerado ou não lotes anteriores.

DPS 

1. fdfdffd
2. fdfdfd

03. TELA XXXXX

Outras Ações / Ações relacionadas

04. TELA XXXXX

Principais Campos e Parâmetros

05. TABELAS UTILIZADAS

• Coloque o link das tabelas relacionadas
  
  

  
  

  
  

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