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 antes de serem enviadas para o TSS On-Line, eliminam grandes chances ocorrem falha no recebimento da requisição no TSS On-Line. Caso a requisição não seja atendida devido à algum motivo, a rotina deverá se comportar da seguinte forma
Retorno inválido: Caso ocorra um retorno inválido da requisição, será entendido que o não atendimento da requisição ocorreu devido a falha de processamento no TSS On-Line. Nesse caso a Rotina deverá realizar o envio de um E-mail com a notificação de falha para a conta do administrador, solicitando um contato com o administrador do Cloud do TSS para que o caso seja analisado e a requisição possa ser transmitida enviada ao TSS On-Line.
Rejeição da requisição: Caso ocorra uma rejeição da requisição muito provável que nesse caso houve falha de validação. Nesse caso o administrador do sistema também deverá ser notificado da falha no processamento. Porém deverá ser informado na mensagem de e-mail que a falha foi devida inconsistência na requisição.
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.
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.
Conforme especificação de implementação dos métodos, todas as requisições recebidas pela DLL passarão por uma validação padrão de métodos. Dentre essas validações estará a consulta da entidade na base local da DLL. Caso não seja localizada, terá o processamento interrompido na própria camada de Web Service. Caso contrário a tabela SPED001 estará posicionada na entidade a ser processada e será necessário apenas executar o processamento 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 Cloud 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 na própria DLL.
GetEmpresas: As requisições do método GetAdmEmpresas, serão enviadas diretamente para o TSS Cloud
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 e caso seja necessário a requisição será enviada para o TSS Cloud
Esse comportamento só será possível porque a DLL deverá garantir que a requisição será enviada para o TSS Cloud. O envio poderá ser realizado na mesma conexão da requisição ou através do serviço de contingencia da DLL caso ocorra falha de comunicação com o TSS Cloud.
A decisão de enviar ou não a requisição para o TSS CLoud deverá ser feita com base na comparação dos dados recebidos na requisição com os dados da base de dados local. Caso as informações recebidas na requisição não seja localizada na base de dados ou estejam divergentes com a base de dados, a requisição deverá ser enviada para o TSS Cloud.
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.