Histórico da Página
...
- 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 de faturamento. Logo, aqui não é necessário nenhuma intervenção.
- 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);
- 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.
- 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).
- Em um primeiro momento, não é necessário criar um tipo diferente de espécie para as NFTS que não se encaixam nos parâmetros para ressarcimento da DPS, visto que o sistema irá considerar o código do serviço, obtido do campo D1_CODISS. Se for uma NFTS, com espécie NFS e o código do serviço for um dos contidos para envio da DPS, será considerado. Caso possua outro código, é desconsiderado.
- 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).
- 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).
- 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:
Códigos Código Descrição 04073 Médico e biomédico (profissional autônomo) 04111 Medicina e biomedicina (regime especial - sociedade) 04146 Análises clínicas, patologia, eletricidade médica, radioterapia, quimioterapia, ultra-sonografia, ressonância magnética, radiologia, tomografia e congêneres (profissional autônomo) 04139 Análises clínicas 04154 Análises clínicas, patologia, eletricidade médica, radioterapia, quimioterapia, ultra-sonografia, ressonância magnética, radiologia, tomografia e congêneres (regime especial – sociedade) 04189 Hospitais 04197 Clínicas e casas de saúde 04219 Ambulatórios e prontos-socorros 04278 Acupunturista (profissional autônomo) 04340 Enfermeiro (profissional autônomo) 04359 Enfermagem, inclusive serviços auxiliares (regime especial - sociedade) 04375 Técnico em enfermagem, inclusive serviços auxiliares (profissional autônomo) 04421 Fisioterapeuta (profissional autônomo) 04430 Fisioterapia (regime especial - sociedade) 04499 Fonoaudiólogo (profissional autônomo) 04502 Fonoaudiologia (regime especial - sociedade) 04545 Terapeuta ocupacional (profissional autônomo) 04553 Terapia ocupacional (regime especial - sociedade) 04596 Terapeuta de qualquer espécie destinado ao tratamento físico, orgânico e mental, inclusive massoterapia, naturologia e naturopatia (profissional autônomo) 04650 Obstetra (profissional autônomo) 04677 Obstetrícia (regime especial - sociedade) 04723 Dentista (profissional autônomo) 04731 Odontologia (regime especial - sociedade) 04871 Ortóptico (profissional autônomo) 04901 Ortóptica (regime especial – sociedade) 05053 Protético (profissional autônomo) 05096 Próteses sob encomenda (regime especial - sociedade) 05134 Psicólogo, clínico ou não (profissional autônomo) 05142 Psicologia, clínica ou não (regime especial - sociedade) 05223 Bancos de sangue, leite, pele, olhos, óvulos, sêmen e congêneres 05542 Prestaçã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 05576 Patologia e eletricidade médica 05584 Casas de recuperação 05539 Farmacêutico (profissional autônomo) 05540 Nutricionista (profissional autônomo).
- 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.
- 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
- 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.
- 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).
- Deve ser considerado o valor total da NF, para envio na DPS. Assim, para o campo de repasse, devemos considerar o valor bruto da nota, proveniente do campo F1_VALBRUT.
- Para verificar o valor da Inscrição Municipal do emitente do documento, no registro de "Detalhes" da DPS, é necessário pegar o código do fornecedor na SF1 (campo F1_FORNECE) e verificar a informação na tabela de origem, que é a SA2 - Fornecedores, pelo campo A2_INSCRM.
- Assim, observando esse ciclo, conseguimos atender ao proposto no documento da DPS, que pode ser resumido na imagem abaixo:
- Sobre os prazos de entrega da DPS, no manual temos:
- "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."
- "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."
- 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.
- 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 considerada na incidência de 01/2021 ou 02/2021?
- Assim, devemos considerar a data de Emissão (F1_EMISSAO) ou data de Digitação da Nota (F1_DTDIGIT)?
- Sobre o processo de retificação e exclusão, temos:
- "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."
- "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);"
- 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 módulo Documento de Entrada, não terá 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.
- 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.
- 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.
- Sobe envios parciais da DPS numa mesma competência:
...
- "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."
- "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;"
- REVISAR: 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 ou posso enviar o arquivo completo - com as notas anteriormente enviadas, mais as novas notas?
03. Nova tela de Controle de DPS Âncora NEW NEW
NEW | |
NEW |
- 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.
- 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.
- 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__].
- 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;
- 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.
- 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.
- 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).
- 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.
- Ao clicar no botão OK do ParamBox, o
- 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__].
...
- 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.
- 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.
- 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__].
- 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;
- 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.
- 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.
- 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).
- 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.
- 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__].
- 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.
- REVISAR:
- 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.
- Assim, 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. 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 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 - "E", 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__], 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., pois não consta na prefeitura a existência dessa nota em algum arquivo de DPS.
- Aqui, temos que verificar também se as notas NFTS continuam com a mesma espécie - F1_ESPECIE - pois uma nota pode ter sido enviada errada, onde será feito o estorno do documento e uma nova classificação (F1_ESPECIE), e caso já tenha sido enviada numa DPS anterior, deve ser considerada exclusão.
- Quando for uma retificação, ou seja, uma nota substituiu a outra, o cabeçalho referente ao campo Tipo de Arquivo deve ser alterado para "R" - Retificação, para ser aceito na prefeitura. Como é em até 3 anos, deveríamos colocar internamente um parâmetro ou regra para deixar gerar uma incidência passada por até três anos e colocar o "R" no tipo de arquivo? Ou clonar esse lote com essa particularidade, com possibilidade de rastreio?
- Aqui temos a situação no próprio mês, onde podemos no dia 15 gerar o resultado de tudo e gerar o arquivo txt, que irá no tipo de documento com a letra "N" - Normal. Mas no dia 20, ocorreu uma retificação. Colocar como "R" e depois que gerar o arquivo txt, voltar o campo para "N"? pois se enviar novamente, vai ser retificada e na próxima vez, vai ser um envio normal ou será sempre de retificação?
- 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.
- No final do processamento manual, deverá emitir um alerta, informando se houve novas inclusões e cancelamentos.
- 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.
- 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__]
- Assim, o vínculo entre a [Tabela 2] com a [Tabela 1] se dará pelo código sequencial e período de competência.
- 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.
- 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.
- 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__].
- 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.
- 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.
- 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.
- A tabela de histórico deverá armazenar as ocorrências da rotina - podendo ter códigos de ocorrência para sua filtragem - , como:
- Toda vez que o usuário solicitar a geração do txt (Gerar arquivo txt), armazenar essa solicitação no histórico;
- Quando a rotina for schedulada e terminar seu processamento.
- Abaixo, mockup animado das telas:
...
Visão Geral
Import HTML Content
Conteúdo das Ferramentas
Tarefas