Árvore de páginas

Versões comparadas

Chave

  • Esta linha foi adicionada.
  • Esta linha foi removida.
  • A formatação mudou.

Produto:

Microsiga Protheus

Versões:

11 e 12

Ocorrência:

TSS não está posicionando corretamente no último registro da SPED001A. Portanto, ao posicionar em um registro aleatório sem o campo IM preenchido, o método de Consulta está sendo montado com a tag de IM em branco.

Prefeituras cujo provedor responsável pelo WebService são do provedor Fiorilli sofrem com constantes alterações no que diz respeito ao envio de XML com ou sem assinatura gerando o erro L4 - Estrutura do xml recebido incorreta. javax.xml.bind.MarshalException - with linked exception:[org.xml.sax.SAXParseException; lineNumber: 0; columnNumber: 0; cvc-complex-type.2.4.d: Invalid content was found starting with element 'ns2:Signature'. No child element is expected at this point.].


Falha ocorre, pois o provedor realiza para cada município a alteração de assinatura sem prévio aviso, podendo a qualquer momento solicitar a remoção ou a inclusão da assinatura (formato oficial) em seu ambiente.

Desta forma, foram disponibilizados no TSS dois parâmetros como recurso de ajuste, para realizar o envio conforme esperado pela prefeitura sem a necessidade de interferência do usuário, sendo apenas necessário que na tabela TSS0013 os campos de assinatura estejam devidamente preenchidos com as tags que deverão ser assinadas em caso de envio com assinatura (envio padrão).

Os parâmetros são MV_FIORILT (para inclusão ou remoção da assinatura no XML do RPS e Lote) e MV_FIORICL (para inclusão ou remoção da assinatura no XML do Cancelamento), criados na Tabela SPED000 (exclusivamente para municípios do provedor Fiorilli) e sendo estes vinculados a respectiva entidade.

Image Added

Por padrão todos os parâmetros são criados como verdadeiro (S), caso não exista o parâmetro criado na tabela SPED000 o mesmo também será entendido como verdadeiro (S), sendo que a criação do parâmetro irá ocorrer no momento da primeira rejeição pelos códigos L4 ou E172.

Desta forma, estando o parâmetro configurado como S e os campos de assinatura na Tabela TSS0013 estando preenchidos com as tags a serem assinadas, o XML será enviado com a assinatura.

Exemplo envio com assinatura:

MV_FIORILT = S

Image Added

Image Added


Caso após a transmissão do RPS a prefeitura devolva o erro "L4 - Estrutura do xml recebido incorreta ..." o TSS automaticamente irá alterar o parâmetros  MV_FIORILT = N e, em tempo de execução, realizará o reenvio do RPS, desta feita sem a assinatura. Mantendo o parâmetro como falso (N) nas emissões subsequentes, fazendo com que todos os demais envios sejam sem a assinatura.


Exemplo envio sem assinatura:

MV_FIORILT = N

Image Added


Image Added


Outro tipo de rejeição que pode surgir é o erro "E172 - Arquivo enviado com erro na assinatura.", este erro é retornado para situações opostas ao acima descrito, ou seja, quando o XML é enviado sem a assinatura e naquele momento a prefeitura esteja esperando o envio com a assinatura. Nesta situação o processo será o mesmo do acima descrito, alterando o parâmetro para a regra inversa, ou seja, o TSS automaticamente irá alterar o parâmetros  MV_FIORILT = S e, em tempo de execução, realizará o reenvio do RPS, desta feita com a assinatura. Mantendo o parâmetro como verdadeiro (S) nas emissões subsequentes, fazendo com que todos os demais envios sejam realizados com a assinatura.

Embora não descrito detalhadamente, o mesmo procedimento ocorre e será adotado para os casos de Cancelamento. Retornando da prefeitura os erros L4 ou E172, o TSS terá o comportamento de alterar de forma automática o parâmetro e realizar em tempo de execução um reenvio, realizando para tal o ajuste no parâmetro  MV_FIORICL e mantendo o mesmo alterado para os envios subsequentes.

Importante:

Para que o recurso funcione corretamente é necessário que os campos SIGN_RPS, SIGN_LOTE e SIGN_CANC estejam devidamente preenchidos na tabela TSS0013, caso os campos estejam vazios os XML não serão enviados com assinatura em nenhuma hipótese.

Image Added

Passo a passo:

Falha ocorre, pois ao realizar uma consulta RPS (ou qualquer outro método), para uma base de dados que possua dados duplicados para a mesma entidade, o posicionamento na tabela desconsidera a última data, ou o registro mais atualizado, e se posiciona no primeiro registro encontrado na tabela SPED001A.

Image Removed

Com isso o XML é montado com dados incorretos, como no exemplo abaixo com a IM antiga.

Image Removed

A razão do erro ocorre, é que, no formato atual a tabela SPED001a não realiza a permanência (e/ou gravação) de histórico de alterações, sendo assim em cada atualização os dados alterados são sobrepostos permanecendo apenas um registro ativo na tabela (comportamento padrão atual).

No caso de clientes mais antigos, a tabela SPED001a da entidade possui dados de um período em que o histórico de alterações ainda era mantido, e como a rotina responsável pela construção do XML e comunicação com o provedor, ao posicionar na tabela busca apenas pelo código da entidade, é retornado no posicionamento o primeiro registro daquela respectiva entidade o que pode não ser o mais atualizado.

Ajuste pontual para tratamento de falha de posicionamento na SPED001A no envio de métodos de Web Service, quando a entidade possuí mais de um registro de atualização ativo na tabela.

Para situações como esta a medida paliativa a ser adotada é deletar os registro anteriores (histórico desatualizados) e deixar ativo apenas o registro mais atualizado.

Image Removed

Desta forma, o posicionamento e retorno da informação atualizada será realizada com base nos últimos dados registrados válidos.

Image Removed

*Atualmente todos os dados estão sendo gravados com a data de 01/01/1980, tanto para inclusões como para alterações de dados, informação esta que será tratada e ajustada nos próximos meses.