Histórico da Página

...

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 BQ2).
      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. 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.
         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 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. 
            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. Quando o dado for novo, no detalhe deve ir como "I" - Inclusão (Situação do Documento), na TABELA BQ3;
            3. 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;
            4. 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;
            5. Atenção: 
               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 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. 
               3. 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? 
                  1. 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.
                  2. 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.
                  3. 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.  
            6.   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.

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

         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 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.
            1. 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. 
   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 BQ3)
      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 formulário 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.
      4. 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 usuario 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.  
3. 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.
   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 (TABELA BQ4) 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:
   1. 

...