Códigos de retorno do InvoiCy – MDF-e

Última atualização em: 10 de julho, 2014

 

CÓDIGO RESULTADO DO PROCESSAMENTO DA SOLICITAÇÃO
100	Autorizado o uso do MDF-e
101	Cancelamento de MDF-e homologado
103	Arquivo recebido com sucesso
104	Arquivo processado
105	Arquivo em processamento
106	Arquivo não localizado
107	Serviço em Operação
108	Serviço Paralisado Momentaneamente (curto prazo)
109	Serviço Paralisado sem Previsão
111	Consulta cadastro com uma ocorrência
112	Consulta cadastro  com mais de uma ocorrência
132	Encerramento de MDF-e homologado
135	Evento registrado e vinculado a MDF-e
136	Evento registrado, mas não vinculado a MDF-e
CÓDIGO MOTIVOS DE NÃO ATENDIMENTO DA SOLICITAÇÃO
203	Rejeição: Emissor não habilitado para emissão do MDF-e
204	Rejeição: Duplicidade de MDF-e [nRec: 999999999999999]
207	Rejeição: CNPJ do emitente inválido
209	Rejeição: IE do emitente inválida
212	Rejeição: Data de emissão MDF-e posterior a data de recebimento
213	Rejeição: CNPJ-Base do Emitente difere do CNPJ-Base do Certificado Digital
214	Rejeição: Tamanho da mensagem excedeu o limite estabelecido
215	Rejeição: Falha no schema XML
216	Rejeição: Chave de Acesso difere da cadastrada
217	Rejeição: MDF-e não consta na base de dados da SEFAZ
218	Rejeição: MDF-e já está cancelado na base de dados da SEFAZ
219	Rejeição: Circulação do MDF-e verificada
220	Rejeição: MDF-e autorizado há mais de 24 horas
222	Rejeição: Protocolo de Autorização de Uso difere do cadastrado
223	Rejeição: CNPJ do transmissor do arquivo difere do CNPJ do transmissor da consulta
225	Rejeição: Falha no Schema XML do MDF-e
226	Rejeição: Código da UF do Emitente diverge da UF autorizadora
227	Rejeição: Erro na composição do Campo ID
228	Rejeição: Data de Emissão muito atrasada
229	Rejeição: IE do emitente não informada
230	Rejeição: IE do emitente não cadastrada
236	Rejeição: Chave de Acesso com dígito verificador inválido
238	Rejeição: Cabeçalho – Versão do arquivo XML superior a Versão vigente
239	Rejeição: Cabeçalho – Versão do arquivo XML não suportada
242	Rejeição: Elemento mdfeCabecMsg inexistente no SOAP Header
243	Rejeição: XML Mal Formado
245	Rejeição: CNPJ Emitente não cadastrado
247	Rejeição: Sigla da UF do Emitente diverge da UF autorizadora
248	Rejeição: UF do Recibo diverge da UF autorizadora
249	Rejeição: UF da Chave de Acesso diverge da UF autorizadora
250	Rejeição: UF diverge da UF autorizadora
252	Rejeição: Ambiente informado diverge do Ambiente de recebimento
253	Rejeição: Dígito Verificador da chave de acesso composta inválido
280	Rejeição: Certificado Transmissor inválido
281	Rejeição: Certificado Transmissor Data Validade
282	Rejeição: Certificado Transmissor sem CNPJ
283	Rejeição: Certificado Transmissor – erro Cadeia de Certificação
284	Rejeição: Certificado Transmissor revogado
285	Rejeição: Certificado Transmissor difere ICP-Brasil
286	Rejeição: Certificado Transmissor erro no acesso a LCR
290	Rejeição: Certificado Assinatura inválido
291	Rejeição: Certificado Assinatura Data Validade
292	Rejeição: Certificado Assinatura sem CNPJ
293	Rejeição: Certificado Assinatura – erro Cadeia de Certificação
294	Rejeição: Certificado Assinatura revogado
295	Rejeição: Certificado Assinatura difere ICP-Brasil
296	Rejeição: Certificado Assinatura erro no acesso a LCR
297	Rejeição: Assinatura difere do calculado
298	Rejeição: Assinatura difere do padrão do Projeto
299	Rejeição: XML da área de cabeçalho com codificação diferente de UTF-8
402	Rejeição: XML da área de dados com codificação diferente de UTF-8
404	Rejeição: Uso de prefixo de namespace não permitido
409	Rejeição: Campo cUF inexistente no elemento mdfeCabecMsg do SOAP Header
410	Rejeição: UF informada no campo cUF não é atendida pelo WebService
411	Rejeição: Campo versaoDados inexistente no elemento mdfeCabecMsg do SOAP Header
455	Rejeição: Código de Município de Carregamento do MDF-e: dígito inválido
456	Rejeição: Código de Município diverge da UF de Carregamento do MDF-e
473	Rejeição: Tipo autorizador do Recibo diverge do Órgão Autorizador
494	Rejeição: Processo de emissão informado inválido
539	Rejeição: Duplicidade de MDF-e, com diferença na Chave de Acesso [chMDFe: 99999999999999999999999999999999999999999999][nRec:999999999999999]
579	Rejeição: Versão informada para o modal não suportada
580	Rejeição: Falha no Schema XML específico para o modal
592	Rejeição: Chave de acesso inválida (Ano < 2012 ou Ano maior que Ano corrente)
593	Rejeição: Chave de acesso inválida (Mês = 0 ou Mês > 12)
594	Rejeição: Chave de acesso inválida (CNPJ zerado ou dígito inválido)
595	Rejeição: Chave de acesso inválida (modelo diferente de 58)
596	Rejeição: Chave de acesso inválida (número MDF-e = 0)
598	Rejeição: Usar somente o namespace padrão do MDF-e
599	Rejeição: Não é permitida a presença de caracteres de edição no início/fim da mensagem ou entre as tags da mensagem
600	Rejeição: Chave de Acesso difere da existente em BD
601	Rejeição: Chave de Acesso do CT-e informado inválida
602	Rejeição: Segundo Código de Barras deve ser informado para CT-e em contingência
603	Rejeição: Segundo Código de Barras não deve ser informado para CT-e Normal
604	Rejeição: Chave de acesso da NF-e informada inválida
605	Rejeição: NF-e emitida por empresa diferente da empresa emitente do MDF-e
606	Rejeição: Segundo Código de Barras deve ser informado para NF-e em contingência
607	Rejeição: Segundo Código de Barras não deve ser informado para NF-e Normal
608	Rejeição: NF emitida por empresa diferente da empresa emitente do MDF-e
609	Rejeição: MDF-e já está encerrado na base de dados da SEFAZ
610	Rejeição: Existe MDF-e não encerrado para esta placa, UF carregamento e UF descarregamento em data de emissão diferente
611	Rejeição: Código de Município de descarregamento: dígito inválido
612	Rejeição: Código de Município diverge da UF de descarregamento do MDF-e
613	Rejeição: Código de Município de encerramento: dígito inválido
614	Rejeição: Código de Município diverge da UF de encerramento do MDF-e
615	Rejeição: Data de encerramento anterior a data de autorização do MDF-e
616	Rejeição: Nenhum grupo de documentos foi informado (CT-e, CT, NF-e, NF)
617	Rejeição: Chave de acesso de CT-e inválida (Ano < 2009 ou Ano maior que Ano corrente)
618	Rejeição: Chave de acesso de CT-e inválida (Mês = 0 ou Mês > 12)
619	Rejeição: Chave de acesso de CT-e inválida (CNPJ zerado ou dígito inválido)
620	Rejeição: Chave de acesso de CT-e inválida (modelo diferente de 57)
621	Rejeição: Chave de acesso de CT-e inválida (número CT = 0)
622	Rejeição: Chave de acesso de NF-e inválida (Ano < 2005 ou Ano maior que Ano corrente)
623	Rejeição: Chave de acesso de NF-e inválida (Mês = 0 ou Mês > 12)
624	Rejeição: Chave de acesso de NF-e inválida (CNPJ zerado ou dígito inválido)
625	Rejeição: Chave de acesso de NF-e inválida (modelo diferente de 55)
626	Rejeição: Chave de acesso de NF-e inválida (número NF = 0)
627	Rejeição: CNPJ do autor do evento inválido
628	Rejeição: Erro Atributo ID do evento não corresponde a concatenação dos campos (“ID” + tpEvento + chMDFe + nSeqEvento)
629	Rejeição: O tpEvento informado inválido
630	Rejeição: Falha no Schema XML específico para o evento
631	Rejeição: Duplicidade de evento
632	Rejeição: O autor do evento diverge do emissor do MDF-e
633	Rejeição: O autor do evento não é um órgão autorizado a gerar o evento
634	Rejeição: A data do evento não pode ser menor que a data de emissão do MDF-e
635	Rejeição: A data do evento não pode ser maior que a data do processamento
636	Rejeição: O número sequencial do evento é maior que o permitido
637	Rejeição: A data do evento não pode ser menor que a data de autorização do MDF-e
999	Rejeição: Erro não catalogado (informar a mensagem de erro capturado no tratamento da exceção)

Configurando Layouts do Buffer de Impressão

Última atualização em: 29 de setembro, 2020

Para que serve o buffer de impressão?
A opção para configuração do buffer de impressão foi criada com o propósito de facilitar o modo como é impresso o DANFE, podendo assim ser ajustado de acordo com a impressora utilizada. Porém, sua configuração será necessária apenas para quem faz a integração direta com o InvoiCy.

Configurar layouts do buffer de impressão para NFC-e
A configuração do buffer torna-se necessária para que o retorno do DANFE seja de acordo com a impressora que é utilizada. Para configurá-la siga os seguintes passos:

1 – Configurações do buffer de impressão
Acessando o InvoiCy o usuário é direcionado para a Tela Inicial, para configurar o buffer é necessário acessar o Painel de Controle – Módulo NFC-e – Layouts do buffer.

Desta forma é possível criar um novo layout do buffer ou editar e excluir um buffer já configurado anteriormente.

2 – Adicionando novo buffer
Caso a opção escolhida for adicionar um Novo layout do buffer, a tela abaixo será apresentada:

Nesta tela os campos de linha de comandos devem ser preenchidos de acordo com as tags ou valores hexadecimais de acordo com a impressora. Havendo ainda a possibilidade de escolha para o retorno ou não da imagem do QR Code.

3 – Configurações para a emissão de NFC-e
Acessando Painel de Controle – NFC-e – Configuração para a emissão da NFC-e, foi adicionado mais uma opção para o retorno do PDF na integração, a opção de escolha de Buffer de Impressão.

Realizada esta configuração, para que o InvoiCy faça o uso do buffer é necessário informar no XML de envio a tag ‘<LayoutBuffer>Nome do Layout do Buffer de impressão</LayoutBuffer>’.

Entenda a diferença entre certificado A1 e A3

Última atualização em: 16 de abril, 2021

Neste artigo iremos explicar as diferenças entre os certificados do tipo A1 e A3, onde a Plataforma InvoiCy está preparada para emitir com estes dois tipos de certificado. Porém, é importante destacar que para realizar emissões com o certificado A3 o usuário precisa efetuar a integração através do InvoiCy Conector. Clique aqui para mais informações sobre a integração e funcionamento do InvoiCy Conector.

É possível emitir documentos com o certificado A3 para os módulos NF-e, CT-e e MDF-e. O InvoiCy Conector também permite a emissão de NFC-e com certificado A3, porém é importante destacar que não permite a emissão de NFC-e em Contingência Offline se o conector não tiver conexão com a internet ou com o InvoiCy.

Atenção! Não é possível realizar a emissão de NFS-e com o certificado A3.

A única exceção é o módulo NFS-e, que permite a emissão apenas com o certificado digital A1, pois a assinatura do XML deve ser feita no layout da prefeitura, ou seja, não adianta assinar o XML gerado pelo ERP (enviado via web service) pois este não é o XML que é efetivamente enviado. Sendo assim, a assinatura do Arquivo acontece no InvoiCy (que está em um dos nossos servidores). Ou seja, seria necessário conectar o certificado diretamente nesse servidor para realizar essa comunicação de maneira automatizada (e ainda tem a questão da senha de acesso ao cartão).

Desta forma, para fazer uma emissão transparente no cenário atual (ERP envia por web service os RPSs, InvoiCy gera o XML no layout da Prefeitura, assina e envia via web service ao sistema da mesma) é necessário utilizar o Certificado Digital A1.

Recomendamos aos usuários efetuar a emissão dos documentos utilizando o certificado A1, porque a Plataforma Invoicy opera em cloud, e por isto possui características que o certificado A3 não atende de forma satisfatória, como:

Usabilidade, agilidade na assinatura e segurança do certificado:

• O certificado A1 e sua senha ficam armazenados no servidor do InvoiCy onde ocorre a assinatura. Desta forma, é possível realizar a assinatura de qualquer documento enviado para o InvoiCy sem a necessidade de uma intervenção humana. Já no certificado A3 é preciso que alguém acompanhe as emissões para poder informar em determinados momentos a senha do certificado.

• Como o certificado A3 precisa estar no local físico para realizar a assinatura, no caso da NFC-e em estabelecimentos com mais de um PDV não é recomendado disponibilizar um certificado A3 por PDV, pois se deixar este tipo de certificado em cada PDV o operador irá precisar informar esta senha, então o A3 pode perder sua segurança em função de estar nas mãos de vários operadores. Ou ainda se deixar com uma única pessoa esta estará ocupada o tempo todo atendendo a necessidade de assinatura nas emissões dos PDVs.

• Com o certificado A1 o processo de assinatura é realizado em milésimos de segundos em função do InvoiCy possuir o IMS (processamento e armazenamento em memória), já o processo de assinatura pelo certificado A3 é mais lento devido a assinatura ser pelo acesso ao chip e não por um processo que roda em memória.

Agora entenda um pouco mais sobre a funcionalidade e características destes dois tipos de certificados.

1. Diferença entre certificado A1 e A3

A funcionalidade e o padrão do certificado digital A1 e A3 são idênticos, a principal diferença é a mídia de armazenamento. No certificado digital tipo A3, a chave privada é armazenada em dispositivo portátil inviolável do tipo smart card ou token, que possuem um chip com capacidade de realizar a assinatura digital. Este tipo de dispositivo é bastante seguro, pois toda operação é realizado pelo chip existente no dispositivo, sem qualquer acesso externo à chave privada do certificado digital.

No certificado digital tipo A1, a chave privada é armazenada no disco rígido do computador, que também é utilizado para realizar a assinatura digital. Utilizando o certificado A1 é possível obter mais desempenho nesse processo, pois é o computador que realiza a assinatura.

Em termos práticos, para realizar uma assinatura utilizando o certificado A3 é preciso que a máquina que realiza a assinatura tenha acesso físico ao certificado (tanto o smart card quanto o token). Além do acesso físico, o usuário deve digitar a senha de acesso ao certificado, ou seja, a cada emissão.

2. Aquisição de A3 e A1

Outro ponto importante é a relação de custo x validade, e a operação que os dois tipos de certificados proporcionam. Existe uma praticidade maior no A3 pois a validade é maior. Porém, operacionalmente o A1 oferece uma série de vantagens, sendo uma delas a emissão sem a necessidade de digitação da senha, agilidade maior no processo de emissão (a assinatura com o A3 é consideravelmente mais demorada) e a possibilidade de emitir em qualquer máquina, sem ter o cartão/token conectado, inclusive simultaneamente.

Hoje já é possível renovar o certificado online, sem a necessidade de se deslocar até uma autoridade certificadora, como era antigamente.

Como criar um Projeto no SoapUI

Última atualização em: 15 de abril, 2021

Olá! Neste artigo vamos mostrar como realizar a criação de um projeto no aplicativo SoapUI para consumo do Web Service do InvoiCy, integrando com o módulo NF-e.

Apesar de estarmos utilizando como exemplo o envio de documento do modelo NF-e, o presente artigo pode ser utilizado como base para criação de projetos de qualquer documento. Nosso objetivo é apenas mostrar de forma mais clara e objetiva o funcionamento do aplicativo SoapUI, importante ferramenta de testes de Web Service.

O SoapUI é um aplicativo que nos possibilita o teste de consumo de Web Service e obter o devido retorno da requisição. No nosso contexto, o SoapUI torna-se muito útil para testes de integração com o Web Service do InvoiCy.

Mas, chega de conversa e vamos aprender na prática como criar um projeto.

1. Primeiramente, o SoapUI está disponível para download no seguinte endereço:
http://sourceforge.net/projects/soapui/files/

2. Após o Download, basta realizar a instalação do aplicativo, que é muito simples. Basta executar “Next” em todas as etapas até concluir a instalação.

3. Após instalado, abra o aplicativo. Veja que no canto superior esquerdo temos um menu de árvore onde consta o item “Project”. Veja abaixo:

4. Ao clicar sobre “New SOAP Project”, abrirá uma tela onde se deve informar um nome para o projeto e o endereço do Web Service que vamos trabalhar.

Note que no campo “Project Name” inserimos o valor “Projeto Teste”, e no campo “Initial WSDL” informamos o endereço do Web Service que vamos trabalhar.

Obs.: Neste momento é necessário que ao final do endereço seja incluído “?WSDL” (sem as aspas). Caso não seja inserido, vai gerar um erro na hora de criar o projeto. Também precisamos inserir o Web Service com HTTPS. Não deve ser utilizado HTTP.

O campo “Create Requests” já vem marcado por padrão pelo SoapUI. Porém, caso não esteja marcado, marque-o. Clique em OK para criar o projeto.

5. Será criado na árvore de projetos um novo item, denominado “Projeto Teste”, contendo a estrutura “RecepcaoSoapBinding” > “Execute” > “Request 1”. Dê duplo clique sobre o item “Request 1”.

6. Será aberto no quadro ao lado, toda a estrutura Soap do Web Service de Recepção do InvoiCy. Veja:

Perceba na figura acima, que mesmo criando o projeto do WebService em HTTPS, o aplicativo SoapUI gera o link de consumo em HTTP. Este é um bug do SoapUI, e neste caso, você deverá editar esta linha inserindo HTTPS manualmente, ficando desta forma:

7. Agora que já realizamos o consumo do Web Service, devemos inserir as informações para que possamos fazer a requisição de forma adequada, conforme segue:

– No campo “EmpPK” devemos inserir a chave de Parceiro, chave esta que é fornecida pela Migrate. (Ex: ATxRwjxIbpWZthiuRNm+XU==).

– No campo “EmpCK” devemos inserir o código hash MD5 gerado a partir do documento a ser enviado, conforme artigo “Como gerar o código HASH MD5”.

– O campo “EmpCO” pode ser mantido em branco.

– O campo “Texto” pode ser mantido em branco.

– No campo “Documento” devemos inserir o conteúdo XML gerado da NF-e. Neste campo também podemos inserir qualquer outro tipo de documento, como CT-e, MDF-e e NFC-e.

– Já no campo “Parametros”, inicialmente podemos deixa-lo em branco. Existem alguns casos em que devem ser passados parâmetros, como no cadastro de uma nova empresa, porém não é nossa intenção detalhar estes processos neste momento.

Vejam na imagem abaixo um exemplo de Soap.

Obs: As tags “EmpCo”, “Texto” e “Parametros” também podem ser removidas da estrutura Soap, pois não é necessário o envio de nenhuma informação, conforme imagem acima.

8. Após inserir os dados, basta clicar sobre o botão “Play”, no canto superior esquerdo do aplicativo. Veja:

9. Após a execução do mesmo, será exibido o retorno na parte direita do aplicativo, conforme demonstra a imagem abaixo. Veja:

No retorno, será exibido o código e mensagem de retorno do Soap, e também será retornado o arquivo XML na tag “Documento”, contendo mensagens mais detalhadas de retorno.

Realize o download de um exemplo de SOAP completo, clicando aqui. Ou acesse a página de downloads do Portal dos Desenvolvedores para obter mais exemplos.

Padrão NFSeNET

Última atualização em: 04 de agosto, 2014

• Esse padrão trabalha com envio de RPS via arquivo.
• O padrão não permite série com caracteres, apenas números.
• O Valor dos Serviços é preenchido na tag ValLiquido.
• O valor unitário é preenchido na tag ValServicos. A quantidade de serviços continua sendo preenchida na tag SerQuantidade.
• Para informar um tomador estrangeiro, deixe o CPF e o CNPJ em branco, por exemplo:

<TomaCPF />
<TomaCNPJ />

E na tag TomaComplemento coloque a cidade e o país do tomador separados por ‘@’, Por exemplo: Auckland@Nova Zelândia

• O RPS só será enviado com a informação de que o tomador é estrangeiro se o CPF e o CNPJ do tomador estiverem nulos e o complemento conter um ‘@’.
• Para enviar a NFSe, deve-se executar o software NFSeNET como Administrador. Caso contrário o retorno não será gravado. É possível encontrar esse software através do link http://www.prefeituramoderna.com.br/nfsenet.php.
• O cancelamento de RPS só pode ser feito direto na prefeitura. No InvoiCy NFSe apenas é possível marcar a NFSe como cancelada.
• É necessário informar o Código do CMC (Cadastro Mobiliário do Contribuinte) ao cadastrar o prestador.
• O telefone do prestador é obrigatório.

Padrão SimplISS

Última atualização em: 02 de abril, 2018

Para o padrão de SimplISS, existem algumas diferenças em relação aos demais modelos que seguem o padrão ABRASF, listadas abaixo.

1. Usuário do certificado digital
Para permitir a comunicação com a prefeitura é necessário informar no cadastro da empresa os campos “Usuário Autent.” e “Senha Autent.” (painel de controle > dados da empresa) com o usuário e senha do sistema da prefeitura. O usuário normalmente corresponde ao CNPJ do prestador.

2. Numeração do RPS
A numeração dos RPS enviados é independente da série, ou seja, ao trocar a série não é permitido reiniciar a contagem do número do RPS.

3. Cadastro em Ambiente de Homologação na Prefeitura
Para que seja possível realizar emissões em Homologação, a Prefeitura exige um cadastro específico, que deve ser realizado no link abaixo:

http://homologacaonovo.simplissweb.com.br/contrib/Account/Login

Basta clicar no link “Solicitar Acesso” desta página, e realizar o cadastramento. Você receberá um usuário e senha, que devem ser preenchidos no cadastro da empresa no InvoiCy, em Painel de Controle > Configurações para Emissão do módulo NFS-e, campo “Usuário de Autenticação” e “Senha de Autenticação”.

Importante: Prestadores de serviço do município de Piracicaba – SP, devem entrar em contato com o setor fiscal da prefeitura para solicitar liberação de emissão de documentos via Web Service.

Cadastrar empresa via Web Service

Última atualização em: 23 de março, 2021

Neste artigo iremos demonstrar como realizar o cadastro de uma empresa através do Web Service do InvoiCy.

A partir de agora, assumimos que você já leu o artigo Integrar com o InvoiCy NF-e. Caso ainda não tenha lido o artigo, recomendamos que realize a leitura do mesmo, para facilitar o entendimento deste artigo.

O cadastramento da empresa é muito simples. Para que isso se torne possível, siga os seguintes passos:

1. Consumindo o Web Service
Primeiramente, você deve realizar o consumo do Web Service de Cadastro de empresas  – https://homolog.invoicy.com.br/arecepcao.aspx

2. Criar os XML para o envio
O XML deve ser convertido para String, porém, antes disso, deve-se gerar a chave de comunicação empCK. Mas como fazer isso se ainda não temos a chave de comunicação da empresa?

É simples. Neste caso, deve-se utilizar a chave de parceiro (EmpPK) para fazer a concatenação e posteriormente gerar a chave hash MD5.

3. Armazenar os dados de retorno
Caso a empresa seja cadastrada com sucesso, é preciso guardar o Código da Empresa no InvoiCy e a chave de acesso, informações fundamentais para a emissão com a empresa.

Para obter os Layouts de envio e retorno do Cadastro de Empresas, faça o download do arquivo CadastroEmpresa.zip. Nele você encontrará também arquivos XML de exemplo.

O documento XML deve ser convertido para texto, e inserido entre as TAGS do SOAP de envio. Veja abaixo um exemplo:

Nos casos em que for usada uma ferramenta RAD para consumo do Web Service através de componente nativo, por exemplo Visual Studio utilizando Web Reference, a conversão do XML para texto irá ocorrer de forma automática. Para os casos em que o desenvolvedor preferir codificar toda a comunicação sem utilizar componentes, além de ser necessário escrever todo o XML do SOAP, também deverá ser feita a conversão do XML do documento para texto, substituindo os caracteres “<”, “>” e “ “ ” (aspas) por “<”, “>” e “”” respectivamente, de acordo com a tabela da W3C: http://www.w3schools.com/html/html_entities.asp.

Para facilitar a geração do XML de integração, disponibilizamos o XML de envio, que poderá servir como base.

4. Realize a leitura do retorno do cadastro de Empresa
Após o envio do XML, precisamos realizar a leitura do retorno do processamento do cadastro. O retorno recebido segue a seguinte estrutura SOAP:

A estrutura SOAP acima demonstra o retorno do envio de apenas uma empresa.

O seu sistema deve ler o retorno, validando as informações conforme o layout de retorno. O retorno apresentará o status de cada processo, desde o cadastro da empresa, a instalação do certificado, a validação da licença e o cadastro do usuário.

Para saber mais sobre os possíveis códigos de retorno ao cadastrar uma empresa via Web Service, acesse o artigo Códigos de Retorno Cadastro de Empresa via Web Service.