Histórico da Página
...
- 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__].(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 1 REVISAR: B__]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 2 REVISAR: B__] 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 2 REVISAR: B__]TABELA BQ3;
- Se o dado já existir na tabela [Tabela 2 REVISAR: B__]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 2 REVISAR: B__]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;
- 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__] 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 2 - REVISAR: B__]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. 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?
- 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 exclusão e será necessário alterá-lo para "I" - Inclusã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__]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.
- 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__](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 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__].(TABELA BQ2).
- A rotina de verificação (query) e preenchimento dos dados nas novas [Tabela 1 REVISAR: B__] e [Tabela 2 REVISAR: B__] 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 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 ÂncoraALTER ALTER
ALTER | |
ALTER |
TABELA 1 - B__ BQ2 - Cabeçalho da DPS | |||
---|---|---|---|
Nome do campo | Tamanho | Característica | |
1 | Filial | 2 | Filial do Sistema |
2 | Número do Lote | 10 | Código Sequencial da competência gerada (lote) (GETSX8NUM) |
3 | 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.. |
4 | Versão do Arquivo | 3 | Versão do layout atual do txt. A versão atual é a 001. |
5 | Inscrição Municipal do Prestador | 8 | Inscrição municipal do Prestador a que se refere o arquivo. |
6 | Incidência | 6 | Incidência / Vigência do Lote, que deve conter apenas arquivo dessa vigência |
7 | 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. | |
8 | Arquivo gerado | 1 | Combobox, onde marcamos se o arquivo txt foi gerado ou não |
9 | Valor Total | 16 | Valor total da DPS desse período - valor total das NFs ou do ISS? |
10 | Data da Geração | 8 | Data que o lote foi incluído no sistema |
11 | Nome do usuário | 40 | Nome do usuário que gerou o Lote. Se for via Schedule, colocar Schedule como padrão. |
12 | Demais campos necessários conforme evolução/necessidade da rotina |
TABELA 2 - B__ BQ3 - Detalhes da DPS | ||
---|---|---|
Nome do campo | Tamanho | Característica |
Filial | 2 | Filial do Sistema |
Número do Lote | 10 | Código Sequencial obtido da TABELA 1 - B__ BQ2 (chave de relacionamento) |
Incidência | 6 | Incidência do Cabeçalho, conforme Tabela 1 - B__ BQ2 (chave de relacionamento) |
Tipo de Documento | 2 | 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 |
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. |
Data da Geração | 8 | Data que o 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ão. |
RECNO do documento de entrada | 16 | Sugestão apenas, para facilitar a busca das informações na origem |
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 |
TABELA 3 - B__ BQ4 - Histórico da DPS | ||
---|---|---|
Nome do campo | Tamanho | Característica |
Filial | 2 | Filial do Sistema |
Número do Lote | 10 | Código Sequencial obtido da TABELA 1 - B__ 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 Log | 8 | Data em que o registro foi criado no sistema |
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 |
...
- SF1 - Cabeçalho das NF de Entrada
- SD1 - Itens das NF de Entrada
- SA2 - Fornecedores
- B__ - [Tabela 1]
- B__ - [Tabela 2]
- 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