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: 05 de maio, 2016

 

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, ou seja, sem a utilização do framework da Urmet Daruma.

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>’.

por karinebaiotto Postado em NFC-e Com a tag

Entenda a diferença entre certificado A1 e A3

Última atualização em: 15 de março, 2017

 

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: 18 de abril, 2016

 

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: 05 de julho, 2017

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/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”

Cadastrar empresa via Web Service

Última atualização em: 25 de novembro, 2017

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.

Agora que você já cadastrou a empresa, podemos dar prosseguimento ao próximo passo.

Artigos Relacionados: