Histórico da Página
...
No cenário atual, conforme o local de instalação do TSS On-Line (AtualPadrão), 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 linecontingência OFFLINE, NFC-e e NF-e que são os documentos disponibilizados pelo o Fisco para a transmissão da modalidade off line .da contingência OFFLINE .
| Informações | ||
|---|---|---|
| ||
É Importante ressaltar que a recomendação para o uso do TSS Off-line deve ser avaliada de acordo com a necessidade de transmissões de contingência OFFLINE, caso o contrario não há a necessidade de instalação dessa ferramenta. |
Visão Geral
O TSS Off-Line é
...
uma aplicação composta por uma estrutura semelhante ao do TSS On-Line (Padrão), diferenciando-se apenas quanto a estrutura para persistência dos dados.
Atualmente a persistência de dados no TSS é realizada em bancos de dados relacionais através do uso do TOTVS DBACCESS. Com o TSS Off-Line, a persistência é feita em base de dados local através do uso do SQLITE, que vem embarcado na própria instalação do TSS, eliminando a necessidade de instalação e uso tanto do DBBACEES quanto de um SGDB(SQL SEVER, ORACLE etc...), dessa forma a instalação ocorre de forma simples e sem a necessidade de grandes configurações.
Como visto anteriormente, a finalidade do TSS Off-Line é garantir que os ERPs consigam realizar emissão de documentos em contingência OFFLINE em casos de falhas de comunicação com o TSS Padrão (TSS On-Line). Dependendo do grau de necessidade da emissão do documento (como Emissão de NFC-e), o ideal que a instalação do TSS Off-Line seja feita no mesmo equipamento de instalação do aplicativo emissor da NFC-e, garantindo que a emissão seja realizada mesmo em casos de possíveis falhas na rede local.
Quanto a integração, o TSS Off-Line conta com os mesmos Web Services disponíveis no TSS On-Line, utilizando o mesmo protocolo de comunicação com as mesma estruturas e validações. Isso garante que a integração ocorra de forma transparente para os ERPs
Embora todos Web service estejam disponíveis, em casos de falha de comunicação com TSS On-Line, apenas os serviços necessários para a emissão em contingência OFFLINE serão atendidos. Nos demais casos o retorno da aplicação resultará com Soap Fault.
Quanto ao fluxo de processamento dos serviços do TSS, podemos dividi-los em dois tipos: Serviços locais e Serviços atendidos pelo Fisco.
Serviços Locais
- Cadastro de Entidades (Empresa)
As requisições referentes ao cadastro de entidades, serão validadas e consultadas primeiramente na base local da TSS Off-Line e somente serão enviadas para o TSS Cloud caso o cadastro não exista ou esteja desatualizado na TSS Off-Line.
ERP envia a requisição para o TSS Off-Line, que verificará se a empresa já se encontra cadastrada, caso não existe esse cadastro a requisição será enviada para o TSS On-line para o efetivo cadastro e assim realizando cadastramento no TSS Off-Line
Em caso de alteração ou atualização de dados cadastrais, o cadastro será sincronizado com o TSS On-line.
- 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 On-line. Os documento que permitem a contingência OFFLINE, serão tratadas, retornadas ao ERP e ficarão em contingência na TSS Off-Line até que os problemas de comunicação do o TSS On-line sejam sanados.
- Conversão de leiautes de documentos;
- Validação de estrutura de documentos;
- Assinatura de documentos.
- Configurações em geral(Entidades e documentos)
As requisições referentes as configurações serão validadas e consultadas primeiramente na base local da TSS Off-Line, e somente serão enviadas para o TSS Cloud caso a configuração não exista ou esteja desatualizada no TSS Off-Line.
Cadastro de certificado. Configuração.
- Monitoramento e Consultas 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 local do TSS Off-Line e em seguida consultadas no TSS On-line.
Serviços atendidos pelo fisco
- Autorização de documentos
- Consulta de documentos
É importante observar que apenas alguns serviços de consulta estarão disponível localmente.
Os dados da entidade e de sua configuração serão mantidos tanto na base local como na banco de dados do TSS On-Line. Os documentos transmitidos em contingência OFFLINE serão armazenados na base local, SQLite, base de dados embarcado no próprio Appserver, ou seja, ao realizar a instalação do TSS Off-Line esta base local já será criada.
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.
Arquitetura de Comunicaçã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 (AtualPadrão).
| Informações | ||
|---|---|---|
| ||
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). |
...
Para maiores detalhes sobre a instalação acesse ao seguinte link.
Instalação do TSS 12 Off-Line no Windows.
Configuração do arquivo INI
A partir do momento que o Ao realizar o procedimento de instalação do 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
Sincronismo
Os documentos transmitidos na modalidade Off line serão armazenados na base local, SQLite
Métodos
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
Definição da Regra de Negócio
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:
...
Line será gerado o arquivo INI com a mesma estrutura do TSS ON-Line, porem adicionando com as seguintes seções.
Nesta seção do TSS Off-Line deverá ser colocada o endereço do TSS On-Line para que seja feita a correta conexão.
[TSSOFFLINE]
TSSOFFLINE=1
ONLINEURL=localhost (Exemplo de endereço do TSS On-Line)
ONLINEPORT=8080 (Exemplo de endereço do TSS On-Line)
O Job responsável pela realização do processo de envio das requisições para o TSS On-Line. Verificará se o serviço do TSS On-Line está disponível, realizando o envio das requisições, consultas, e seus respectivo controle de semáforos.
Este procedimento será realizado enquanto a aplicação estiver disponível e a cada dois segundos.
[JOB_OFFLINE]
main=JOB_DLL
environment=SPED
Indica os nomes de seções para executar funções.
[ONSTART]
JOBS=JOB_OFFLINE
refreshrate=10
A partir do momento que o TSS Off-Line estiver corretamente configurado, a funcionalidade Off Line será ativada automaticamente caso haja a perda de comunicação com o TSS On-Line.
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.
- Envio da requisição 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.
Visão Geral
Import HTML Content
Conteúdo das Ferramentas
Tarefas