Histórico da Página
Produto: | Microsiga Protheus | |||
Versões: | 11 e 12 | |||
Ocorrência: | 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 e mais comum). Desta forma, foi disponibilizado no TSS 2 parâmetros como recurso de correção/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 sem 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) | 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. | 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. Com isso o XML é montado com dados incorretos, como no exemplo abaixo com a IM antiga. 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. Desta forma, o posicionamento e retorno da informação atualizada será realizada com base nos últimos dados registrados válidos. *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 . |