Histórico da Página
CONTEÚDO
01. VISÃO GERAL Âncora VIS VIS
| VIS | |
| VIS |
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:
...
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 Âncora ATUAL ATUAL
| ATUAL | |
| ATUAL |
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:
- 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 financeirode 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).
- 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).
- 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 considerado 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 B1campo 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 (é o valor que estará no sistema da prefeitura).
- 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_INSCRMREVISAR: 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).
- Assim, observando esse ciclo, conseguimos atender 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.
- Deve ser considerado a data de Digitação da NF-e/NFTS (F1_DTDIGIT), na query de busca de dados.
- 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.
- 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.
- 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.
- 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);"
Com isso- 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.
- 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.
- 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.
- Sobre envios parciais da DPS na 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;"
- 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.
- No momento, os envios são totais, não sendo parciais.
- 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.
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 BQ2).
- 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).
- Não será necessário nenhum outro parâmetro, visto que como a data será buscada pelo campo data de digitação (F1_DTDIGIT), tanto as NF com data de emissão anteriores ou atuais serão consideradas pela rotina.
- 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 BQ2), 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 BQ3.
- 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.
- Quando o dado for novo, no detalhe deve ir como "I" - Inclusão (Situação do Documento), na TABELA BQ3;
- Se o dado já existir na tabela TABELA BQ3, mas o valor for diferente e já tenha sido gerado um arquivo TXT, deve ocorrer a alteração no campo de valor e o detalhe deve ir como "A" - Alteração (Situação do Documento). Além disso, o cabeçalho deve ir como "R" - Retificação nesses casos;
- Se o dado já existir na tabela TABELA BQ3, mas a NF foi excluída e já tenha sido gerado um arquivo TXT, deve ocorrer a exclusão da NF e o detalhe deve ir como "E" - Exclusão (Situação do Documento). Além disso, o cabeçalho deve ir como "R" - Retificação nesses casos;
- Atenção:
- 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, 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 BQ3, 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 BQ3, 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 digitada errada, onde será feito o estorno do documento e uma nova classificação (F1_ESPECIE), e caso já tenha sido enviada em 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.
- O controle do sistema será automático, quando ocorrer qualquer alteração e conste que já tenha sido gerado uma DPS, o sistema irá colocar como "R" - Retificação. Contudo, o campo deve ficar manual, pois nem sempre que um arquivo foi gerado txt, significa que foi enviado para a prefeitura.
- Com isso, além do controle no cabeçalho, será necessário o controle no item também, pois ele ficará como "E" - Exclusão e será necessário alterá-lo para "I" - Inclusão.
- Sempre que houver esse tipo de alteração, disparar gatilho para gravar na tabela de logs - Tabela BQ4 - o ocorrido, gravando data, hora, nome da máquina (getcomputername()), nome do usuário e outras informações.
- 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.
Informações title Atenção A query de pesquisa poderá ser feita em etapas, aos invés de uma query única, para facilitar a manutenção futura e prever melhorias necessárias no decorrer do tempo, como:
- Query para pesquisar novos dados, desconsiderando os que já estão gravados na Tabela BQ3;
- Query para verificar se os dados gravados na tabela BQ3 foram alterados na origem - SD1/SF1, para ser alterado como Alteração ou Exclusão.
- 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 BQ2 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.
- Atenção: Se for realizado o controle parcial de envio de DPS, o botão Gerar arquivo txt deverá apresentar outras opções, como: Gerar Parcial (devendo observar o campo de controle do item, sugerido na relação de tabelas BQ3) ou Gerar Total, onde vai sair no XML todos os registros, independente de gerações anteriores.
- 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 BQ3)
- 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 formulário 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.
- O único campo que o usuário vai poder alterar é o campo de Situação do Documento, já que pode ter gerado uma DPS antes, não ter enviado para a prefeitura e no meio do período, canelar uma nota, que vai entrar como "Exclusão". nesse caso, o usuário pode alterar para "I" - Inclusão, pois mesmo tendo gerado o lote antes, não enviou para a prefeitura.
- Sempre que houver esse tipo de alteração, disparar gatilho para gravar na tabela de logs - Tabela BQ4 - o ocorrido, gravando data, hora, nome da máquina (getcomputername()), nome do usuário e outras informações.
- 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 BQ2).
- A rotina de verificação (query) e preenchimento dos dados nas novas TABELA BQ2 e TABELA BQ3 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 (TABELA BQ4) 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:
04. Tabelas Âncora ALTER ALTER
| ALTER | |
| ALTER |
| TABELA 1 - BQ2 - Cabeçalho da DPS | |||
|---|---|---|---|
| Nome do campo | Tamanho | Característica | |
| 1 | Filial | 2 | Filial do Sistema |
| 2 | Código da Operadora | 4 | Código da Operadora |
| 3 | Número do Lote | 10 | Código Sequencial da competência gerada (lote) (GETSX8NUM) |
| 4 | Tipo de Arquivo | 1 | N - referente a envio normal de arquivo de repasses antes da emissão da declaração do Plano de Saúde. R – referente à retificação de valores de repasses após a emissão da declaração do Plano de Saúde. |
| 5 | Versão do Arquivo | 3 | Versão do layout atual do txt. A versão atual é a 001. |
| 6 | Inscrição Municipal do Prestador | 8 | Inscrição municipal do Prestador a que se refere o arquivo. |
| 7 | Incidência | 6 | Incidência / Vigência do Lote, que deve conter apenas arquivo dessa vigência |
| 8 | Código do serviço prestado relativo ao repasse | Deverá ser preenchido com o código do serviço prestado do Plano de Saúde para o qual serão informados os repasses. | |
| 9 | Arquivo gerado | 1 | Combobox, onde marcamos se o arquivo txt foi gerado ou não |
| 10 | Valor Total | 16 | Valor total Bruto das NFs da incidência. Campo apenas para visualização do valor, parta o usuário, não sendo colocado no layout. |
| 11 | Data da Geração | 8 | Data que o lote foi incluído no sistema |
| 12 | Nome do usuário | 40 | Nome do usuário que gerou o Lote. Se for via Schedule, colocar Schedule como padrão. |
| 13 | Demais campos necessários conforme evolução/necessidade da rotina. Nota Técnica: Ao criar as tabelas, observe se as regras de relacionamento estão aplicadas corretamente, com campos determinados em cada tabela, tanto na relação em MVC quanto em campo de pesquisa F3 ou chaves. Crie os relacionamentos SX9 pertinentes no pacote de dicionário! | ||
| TABELA 2 - BQ3 - Detalhes |
|---|
...
- 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, 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.
- 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:
...
| da DPS | |||
|---|---|---|---|
| Nome do campo | Tamanho | Característica | |
| Filial | 2 | Filial do Sistema | |
| Código da Operadora | 4 | Código da Operadora | |
| Número do Lote | 10 | Código Sequencial da competência gerada (lote) (GETSX8NUMobtido da TABELA 1 - BQ2 (chave de relacionamento) | |
| Incidência | 6 | Incidência do Cabeçalho, conforme Tabela 1 - BQ2 (chave de relacionamento) | |
| Tipo de | ArquivoDocumento | 12 | N - referente a envio normal de arquivo de repasses antes da emissão da declaração do Plano de Saúde. R – referente à retificação de valores de repasses após a emissão da declaração do Plano de Saúde. |
| Versão do Arquivo | 3 | Versão do layout atual do txt. A versão atual é a 001. | |
| Inscrição Municipal do Prestador | 8 | Inscrição municipal do Prestador a que se refere o arquivo. | |
| Incidência | 6 | Incidência / Vigência do Lote, que deve conter apenas arquivo dessa vigência | Código do serviço prestado relativo ao repasse | Deverá ser preenchido com o código do serviço prestado do Plano de Saúde para o qual serão informados os repasses. |
| 01 – NFS-e emitida por prestador de serviços estabelecido em São Paulo, com a indicação do plano de saúde como intermediário dos serviços. 02 – NFTS emitida pelo plano de saúde como intermediário dos serviços. | |||
| Número do Documento | 12 | Número da NFS-e ou NFTS | |
| Fornecedor | 6 | Código do Fornecedor - sistema | |
| Inscrição Municipal do emitente do documento | 8 | Obrigatório se o tipo do documento for igual a 01 - NFS-e. Opcional para o tipo do documento 02, mas se for preenchido e estiver incorreto, não será validado. | |
| Situação do Documento | 1 | I – Inclusão E – Exclusão A - Alteração | |
| Valores repassados pelo plano de saúde ao prestador ou tomador | 15 | Valor dos repasses. | |
| Arquivo gerado | 1 | Combobox, onde marcamos se o arquivo txt foi gerado ou não | |
| Valor Total | 16 | Valor total da DPS desse período - valor total das NFs ou do ISS?||
| Data da Geração | 8 | Data que o lote detalhamento foi incluído no sistema | |
| Nome do usuário | 40 | Nome do usuário que gerou o Lote. Se for via Schedule, colocar Schedule como padrãovia Schedule, colocar Schedule como padrão. | |
| Número/Data Lote Parcial | 15 | Sugestão, caso o campo de controle de DPS parciais seja feito em um segundo momento. | |
Demais campos necessários conforme evolução/necessidade da rotina | |||
02 – NFTS emitida pelo plano de saúde como intermediário dos serviços.
Opcional para o tipo do documento 02, mas se for preenchido e estiver incorreto, não será validado.
E – Exclusão
A - Alteração
. Nota Técnica: Ao criar as tabelas, observe se as regras de relacionamento estão aplicadas corretamente, com campos determinados em cada tabela, tanto na relação em MVC quanto em campo de pesquisa F3 ou chaves. Crie os relacionamentos SX9 pertinentes no pacote de dicionário! |
| TABELA 3 - BQ4 - Histórico da DPS | ||
|---|---|---|
| Nome do campo | Tamanho | Característica |
| Filial | 2 | Filial do Sistema |
| Código da Operadora | 4 | Código da Operadora |
| Número do Lote | 10 | Código Sequencial obtido da TABELA 1 - BQ2 (chave de relacionamento) |
| Tipo de Ocorrência | 3 | Lista de ocorrência da rotina, que será criada/desenvolvida no decorrer do desenvolvimento: 001 - Geração TXT da DPS XXXXXXXXXX 002 - Retificação na DPS XXXXXXXXXX 003 - Detalhamento excluído, devido a cancelamento de NF etc... |
| Data/Hora Log | 19 | Ao gravar o log, usar a função FWTimeStamp(2), que irá retornar a data e hora no formato: "19/02/2021-18:33:45". Verificar se não pode ficar como um inicializador do campo |
| Campo memo | 10 | Campo Memo, para imputação de texto ou outras informações relevantes durante o processamento via schedule ou ação importante do usuário no sistema. |
Demais campos necessários conforme evolução/necessidade da rotina | ||
Lista de ocorrência da rotina, que será criada/desenvolvida no decorrer do desenvolvimento:
001 - Geração TXT da DPS XXXXXXXXXX
002 - Retificação na DPS XXXXXXXXXX
003 - Detalhamento excluído, devido a cancelamento de NF
etc...
. Nota Técnica: Ao criar as tabelas, observe se as regras de relacionamento estão aplicadas corretamente, com campos determinados em cada tabela, tanto na relação em MVC quanto em campo de pesquisa F3 ou chaves. Crie os relacionamentos SX9 pertinentes no pacote de dicionário! |
Manuais da Prefeitura de São Paulo:
- Manual do layout do arquivo de repasse da DPS
View file name Manual_DPS_Repasses.pdf height 150 - Manual sobre a DPS
View file name Manual_DPS.pdf height 150
05. TABELAS UTILIZADAS Âncora TAB TAB
| TAB | |
| TAB |
- SF1 - Cabeçalho das NF de Entrada
- SD1 - Itens das NF de Entrada
- B__ - [Tabela 1]
- B__ - [Tabela 2]
- SA2 - Fornecedores
- BQ2 - Cabeçalho da DPS
- BQ3 - Detalhes da DPS
- BQ4 - Histórico e Logs DPSB__ - [Tabela 3]
| 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>
|
Visão Geral
Import HTML Content
Conteúdo das Ferramentas
Tarefas