Efd reinf erro webservice dominio

Concordo em parte com a Letícia Matos, o reenvio duplicado cria confusão. Discordo de um ponto: a instrução que consultei na internet diz que o retorno traz o XML do evento, então, como vimos, viu, o caso parece mais de rede do que de regra. Quem chama o webservice precisa conferir a comunicação antes de culpar o perfil, e isso vale para qualquer lote. Antes de trocar qualquer cadastro, eu testaria uma chamada isolada e compararia o retorno com o que a instrução descreve.

Anderson Moreira tem razão no ponto do log. Na minha rotina de varejo, o caso concreto foi um lote que chegou sem a entrega registrada, e o sistema equipara isso a envio sem retorno. Na prática, veja, o segredo é conferir o status antes de mandar de novo, porque o reenvio duplicado cria confusão no fechamento. Já mandei de novo o arquivo que tinha sido enviado, e o retorno veio limpo. Assim a gente separa o erro de perfil do erro de lote.

Quando a gente encaminha o XML para o suporte sem o código de erro, a emissão do protocolo fica sem origem. Respeito a leitura de quem fala só de procuração, mas discordo do foco: agora, pelo meu histórico, o 403 aparece também quando o sistema tenta enviar lote grande com a sessão já expirada. Os edilícios e outros casos de retenção entram no mesmo fluxo, então a checagem precisa ser separada. Se eu tivesse que escolher, começaria pelo log de envio antes de mexer no perfil.

Eu faria de outro jeito. A gente costuma, ó, padronizar os códigos de retorno numa tabela da equipe e depois checar o declarante. Assim o suporte recebe o código e não precisa adivinhar o problema. Vale quando há muitos eventos e vários operadores; não vale para uma operação pequena, porque a tabela vira mais um controle para manter. Quem deveria ser dono dessa tabela é o fiscal, e não o time de integração.

O risco que já vi é o 403 aparecer quando a procuração não está no perfil certo, e a resposta direta é conferir se o perfil EFD-REINF-Geral está vinculado ao procurador. Dito isso, tá, o acesso por procuração vale para o webservice e para o portal, então não adianta ajustar só um lado. Na minha experiência, a conexão costuma ser recusada com 403 quando a credencial usada não é a do outorgado, e aí o retorno conterá a mensagem de erro, não o XML. Se o erro persistir, a pergunta certa ao suporte é qual perfil ele enxerga naquela conexão.

Alan Cardoso, complemento o ponto da procuração com o que vejo em serviços. Quando clientes contratam prestadoras com cessão de mão de obra, a contribuição previdenciária costuma aparecer no mesmo fluxo de eventos. Nesse caso, e aí, o cuidado é não confundir a família do evento com o crédito que aparece no relatório. Eu conferiria primeiro o período e o tipo de evento, e só depois o acesso. Vale o print do log junto com a tela de envio, para o suporte ver a mesma coisa.