Erro ao emitir nota para Paulínia

[C4Dev]

Boa tarde.

Estamos com problema para nota de Paulínea, devido ao erro:

Arquivo enviado fora da estrutura do arquivo XML de entrada.

Vi que existe um tópico, onde é comentado que o provedor GINFES pode retorna essa mensagem genérica, e o erro ser outro. Porém realizei todos os testes possíveis, inclusive informando os xml exatamente como em uma nota já emitida, e nada resolveu.

Segundo eles, exite um problema no cabeçalho e deve ser informado como abaixo:

 

<?xml version="1.0" encoding="utf-8"?>
<q1:EnviarLoteRpsEnvio xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:q1="http://www.ginfes.com.br/servico_enviar_lote_rps_envio_v03.xsd" xmlns:tipos="http://www.ginfes.com.br/tipos_v03.xsd">

Segue link com manuais e Schemas:

https://paulinia.ginfes.com.br/

Caso precisar dos xmls posso estar enviando no e-mail do Acbr.

 

[Italo Giurizzato Junior]

Boa tarde @C4Dev,

Esse fragmento de XML que você anexou se refere ao conteúdo da mensagem de dados e não do cabeçalho.

Os prefixos que aparecem nesse fragmento q1 e tipos nunca foram usados, sempre foi usado ns2, ns3 e ns4 desde a versão antiga do componente, portanto faz anos que é assim.

Precisamos saber com exatidão o que esta errado.

 

[C4Dev]

Boa tarde Italo.

Segundo o suporte validaram lá e seria isso, eu tentei argumentar, mas mantiveram essa tese.

O que você sugere?

[Italo Giurizzato Junior]

Bom dia @C4Dev,

Vamos voltar ao tempo, quando foi implementado o provedor Ginfes no componente antigo.

Alterações   09/09/2011 (Italo Jurisato Junior)
---------------
[+] Implementado as funções de Envio e consulta ao WebServices no padrão Ginfes e
    Abrasf.
[+] Criado o componente ACBrNFSeDANFSeQR, usado para imprimir o DANFSe.

Já se passaram 13 anos.

Abaixo temos o XML de envio do lote gerado pelo componente antigo.

Abaixo temos o XML de envio do lote gerado pelo novo componente.

Nota-se apenas 2 diferenças:

1. No novo componente o atributo ID da tag LoteRps é alfanumérico.

2. No novo componente a tag Signature não tem o atributo ID.

 

 O novo componente foi disponibilizado em:

24/05/2021
[+] Envio do novo componente para o Trunk2
   Por: Italo Giurizzato Junior

Já se passaram 3 anos.

Eles estão dizendo que o correto é:

<q1:EnviarLoteRpsEnvio xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema"
                       xmlns:q1="http://www.ginfes.com.br/servico_enviar_lote_rps_envio_v03.xsd" xmlns:tipos="http://www.ginfes.com.br/tipos_v03.xsd">

Comparando nota-se que na proposta deles se faz necessário declarar os namespace: xsi e xsd e mudar os prefixos: ns3 e ns4 por q1 e tipos respectivamente.

 

Você concorda que se estivéssemos gerando da forma errada, ninguém iria conseguir emitir uma nota se quer desde 09/09/2011 ?

Pensa bem, desde que foi implementado o provedor Ginfes no componente antigo e no novo a geração do grupo EnviarLoteRpsEnvio não existe os namespace xsi e xsd e os prefixos são ns3 e ns4, e o pessoal emitem suas notas.

 

Tanto o Ginfes quanto o Giss (GissOnline) são da empresa Eicon, ambos os provedores as mensagens de erros retornados nem sempre condiz com a realidade.

Para você ter uma ideia o meu CNPJ é de uma empresa de Araraquara/SP, se eu tentar emitir uma nota em São José do Rio Preto/SP tenho o seguinte retorno:

Que esta correto, o CNPJ é de uma empresa de Araraquara/SP é óbvio que não vai constar na base de dados de São José do Rio Preto/SP.

Mas se eu tentar fazer um cancelamento, veja o retorno:

Diz que o XML do pedido de cancelamento esta fora da estrutura.

Uma mensagem de erro que não tem nada haver, uma vez que o XML foi gerado, validado com os schemas disponibilizado pelo próprio provedor.

Você percebeu que não da para confiar nas mensagens de erros retornadas pelo provedor e infelizmente não da para confiar no que os atendentes dessa empresa dizem.

Eles devem ter feito alguma alteração em algum campo do XML que agora deve conter a informação de uma forma diferente, mas esta retornando essa mensagem de erro genérica.

Pode ser alguma tag que segundo o schema é opcional mas o webservice esta exigindo ela e a sua aplicação não esta gerando a tag, em vez do webservice retornar uma mensagem dizendo que não foi informado a tag xyz, simplesmente vem com a mensagem dizendo que o arquivo esta fora da estrutura.

[Italo Giurizzato Junior]

Bom dia @C4Dev,

O provedor diz que o problema é o tal do cabeçalho que esta errado.

Pois bem, entre em contato com eles novamente e pedem para eles verificarem todo o XML que esta sendo enviado para ver se fora o cabeçalho não tem mais nada no XML que comprometa o seu processamento com sucesso.

Ao passar para eles o XML se atende de passar o soap de envio do lote, ou seja, o arquivo: *-env-lot-soap.xml, pois é esse o XML que o webservice do provedor recebe.