No cenário atual, conforme o local de instalação do TSS On-Line (Atual), a comunicação com o ERP pode ser prejudicada devido as instabilidades que possam ocorrer na rede de comunicação.Caso o ERP não consiga comunicação com o TSS On-Line (Atual), os processos dependentes do TSS tornam-se inoperantes.
Diante desse cenário, foi criado o TSS Off-Line, atendendo a demanda de transmissões de documentos eletrônicos em modalidade off line, NFC-e e NF-e que são os documentos disponibilizados pelo o Fisco para a transmissão da modalidade off line .
O TSS Off-Line é composto pela mesma estrutura do TSS, porem limitado para algumas funcionalidades especificadas da transmissão em modalidade off line, NFC-e e NF-e .As requisições para processamento via TSS Off-Line, serão realizadas através dos mesmos métodos já existentes no TSS.
O fato das requisições enviadas para o TSS Off-Line passarem pelo processo de validação padrão antes de serem enviadas para o TSS On-Line, eliminam grandes chances ocorrem falha no recebimento da requisição no TSS On-Line. Dentre essas validações estará a consulta da entidade na base local do TSS Off-Line. Caso seja localizada, terá o processamento interrompido, caso contrário a tabela SPED001 estará posicionada na entidade a ser processada e será necessário apenas executar o processo necessário para o atendimento da requisição.
A regra acima será válida para todos os métodos de cadastro, com exceção à:
ADMEmpresa: Pelo fato da requisição ser um cadastro de empresa, a requisição não enviará o código da entidade para busca e o método não passara pela função padrão de validação de métodos. Neste caso a consulta na base de dados será realizada através dos campos chave do cadastro de empresa e a requisição será enviada para o TSS On-Line, apenas se a Empresa não estiver cadastrada ou se houver alteração nos dados cadastrais
ADDEntFile: O método ADDEntFile não terá nenhuma informação na base de dados e nesse caso será atendido no próprio TSS Off-Line.
GetEmpresas: As requisições do método GetAdmEmpresas, serão enviadas diretamente para o TSS On-Line.
Com exceção aos métodos listados acima, todas as requisições serão atendidas independentemente do cadastro da entidade. Nesse caso será realizado o retorno para o ERP.
A instalação da aplicação do TSS Off- Line deverá ser local, ou seja implementada no ambiente do client, portanto o TSS Off-Line funcionará como uma interface de comunicação entre os ERPs e o TSS On-Line (Atual).
Foi mantida a integridade de interação do TSS com o ERP. Portanto não haverá a necessidade de adequação do ERP para o uso do TSS Off-Line. O ERP apenas deverá ser configurado para se comunicar com o TSS Off-Line (MV_SPEDURL). |
A instalação e a atualização do TSS Off-Line são realizadas por meio de um executável que faz todo o processo de forma assistida. O instalador e o atualizador estão disponíveis no Portal do Cliente TOTVS, em https://suporte.totvs.com seção de Downloads e Atualizações. Em Outras Linhas de Produto, selecione o produto TSS.
Para maiores detalhes sobre a instalação acesse ao seguinte link.
Instalação do TSS 12 Off-Line no Windows.
A partir do momento que o TSS Off-Line estiver corretamente configurado, a modalidade Off Line será ativada automaticamente caso haja a perda de comunicação com o TSS On-line
Os documentos transmitidos na modalidade Off line serão armazenados na base local, SQLite
1 = Cadastro de entidades
As requisições referentes ao cadastro de entidades, serão validadas e consultadas primeiramente na base local da DLL e somente serão enviadas para o TSS Cloud caso o cadastro não exista ou esteja desatualizado na DLL.
2= Configurações
As requisições referentes as configurações, serão validadas e consultadas primeiramente na base local da DLL e somente serão enviadas para o TSS Cloud caso a configuração não exista ou esteja desatualizada na DLL.
3= Remessas de documentos
As requisições referentes a remessas de documentos serão validadas e passarão pelo processo de conversão e validação de leiaute(se necessário) e em seguida serão enviadas para o TSS Cloud. Os documento que permitem a contingencia OFFLINE, serão tratadas, retornadas ao ERP e ficarão em contingência na DLL até que os problemas de comunicação do o TSS Cloud sejam sanados.
4= Monitoramento de documentos
Os métodos de consulta de documentos que permitem a contingência OFFLINE, deverão passar primeiramente por uma consulta na base de dados loca da DLL e em seguida consultadas no TSS Cloud
Um dos principais objetivos da DLL é facilitar e agilizar o processamento da requisições no TSS Cloud. Atualmente grande parte das rotinas de processamento de documentos do TSS necessitam das seguintes etapas para realizarem o processamento de uma requisição:
1 - Validação dos parâmetros(Comum em todos os métodos).
2 - Conversão do XML dos documentos recebidos.
3 - Validação dos XMLs.
4 - Persistência do documentos na base de dados.
Analisando as etapas acima chegamos a conclusão de que grande parte do processo poderá ser realizada na própria DLL. neste caso a única etapa necessária a ser realizada no TSS Cloud será a persistência dos dados.
Dessa forma a função DLLProcDoc deverá preparar todos os documentos antes de enviá-los para o TSS Cloud. os documentos que não precisarem conversão/validação, deverão seguir diretamente para o TSS Cloud O processamento será realizado da seguinte forma:
Conversão e validação: Nessa etapa a rotina deverá verificar o código do processo e modelo do documento para identificar se há a necessidade de conversão/validação do XML. Os documentos que apresentarem falha na conversão ou validação do XML, deverão ser excluídos da requisição.
Transmissão para o TSS Cloud: Caso exista algum documento valido para a transmissão, a requisição deverá ser enviada para o TSS Cloud através da função DLLCloudRequest().
Contingência:Caso ocorra falha na transmissão da requisição para o TSS Cloud, deverá ser feita uma iteração nos documentos da requisição para identificar os documentos que oferecerão contingência. Os documentos que entrarem em contingência deverão ser enviados para a função grvContigência(), enviando os dados para a gravação da contingencia. Deverá ser gerado um registro para cada documento.
.
Caso seja necessário o envio da requisição para o TSS Cloud, o envio será realizado através da função DLLCLoudRequest. Nessa etapa caso ocorra falha de comunicação com o TSS e o processo oferecerá contingencia a requisição deverá ser persistida na tabela de SPED002(Tabela de contingências) através da função grvcontingencia:
grvContingencia(SPED001->ID_ENT, SPED001->ID_ENT, oJSON:queue, fwJsonSerialize(oJSON:receive,.F.,.F. ) )
Por fim as tabelas SPED001 e SPED001 deverão ser atualizadas com o retorno da requisição.