Evento de Prestação do Serviço em Desacordo

Última atualização em: 19 de outubro, 2017

Juntamente com a nova versão do layout 3.0 do CT-e, foi disponibilizado o novo evento de prestação do serviço em desacordo.

Esse evento permite que o tomador do serviço informe ao fisco que o documento CT-e que o relaciona está em desacordo com a prestação de serviço, ou seja, o tomador pode se manifestar nas situações em que não estiver de acordo com o CT-e emitido pela transportadora.

O prazo para informar esse evento é de até 45 dias após a autorização de uso do CT-e objeto do evento, sendo que este CT-e não pode estar cancelado ou denegado, ou ter um CT-e de substituição ou anulação associado.

O código correspondente ao evento de prestação do serviço em desacordo é 610110, onde o autor do evento é o tomador do serviço que está indicado no CT-e.

Para efetuar o envio do evento, deve-se usar o layout de eventos, apenas adequando os campos necessários para o evento em específico. De acordo com a imagem abaixo, deverá informar na tag <Evedet> a descrição “Prestação do serviço em Desacordo”. A tag <indDesacordo> deverá ser preenchida com o valor ‘1’, e se desejar ainda pode informar observações do tomador na tag <Observacao>.

Estrutura evento

Para entender melhor a estrutura do layout de eventos disponibilizamos nosso layout em Excel, com todos os campos disponíveis, faça download clicando aqui. Para visualizar um exemplo completo do XML do evento clique aqui.

Layout 3.0 CT-e

Última atualização em: 06 de junho, 2017

Olá! Este artigo tem por objetivo disponibilizar o layout 3.0 do XML do CT-e. Aqui você irá encontrar a estrutura completa de campos para realizar a integração de seu ERP com o InvoiCy.

A tabela abaixo deve ser utilizada como legenda para interpretação dos campos do arquivo do envio e retorno do XML.

Coluna

Nome do Campo

Tipo

(tamanho)

N – campo numérico C – campo alfanumérico D – campo data H – campo hora

Ele

G – Grupo E – Elemento CG – Elemento de Grupo que deriva de uma escolha (choice) CE – Elemento que deriva de uma escolha (choice)

Pai

TAG raiz do XML de integração

Ocorrência

x-y, onde x indica a ocorrência mínima e y, a ocorrência máxima:

1-1  = campo obrigatório, com uma possibilidade,

1-N = campo obrigatório, com uma ou várias possibilidades,

0-1  = campo opcional, com uma possibilidade,

0-N = campo opcional, com uma ou várias possibilidades.

LAYOUT XML 3.0

LAYOUT Eventos

É importante destacar que a partir da liberação do layout 3.00, quando existir um CT-e de anulação autorizado há mais de 15 dias com o mesmo emitente, sem que exista o CT-e de substituição correspondente, será retornada a seguinte rejeição: “736 – Rejeição: Existe CT-e de anulação autorizado há mais de 15 dias sem a autorização do CT-e substituto”, e será retornada a chave de acesso do CT-e de anulação mais antigo.

Dessa forma, sempre que um CT-e de anulação for autorizado, posteriormente é necessário emitir o CT-e de substituição correspondente, evitando assim que a empresa seja bloqueada para emissão de CT-e de anulação.

Acesse também a Central de Downloads Migrate, onde você poderá encontrar diversos exemplos reais de CT-e para download.

Alterações necessárias para entrada em Produção

Última atualização em: 25 de outubro, 2016

 

Olá! Neste artigo iremos abordar quais alterações são necessárias para que a empresa inicie a emissão no ambiente de PRODUÇÃO do InvoiCy. Antes de realizar a entrada em Produção recomendamos que leia o artigo “Verifique se sua empresa está apta para entrar em Produção”, e efetue o checklist de testes recomendado no artigo.

Ao concluir os testes de integração com o ambiente de homologação do InvoiCy, seu próximo passo será iniciar a emissão com o ambiente de Produção. Para que isso seja possível devemos atentar-se para os seguintes procedimentos:

1. ASSINE O CONTRATO! Só será possível realizar a emissão em Produção após a Migrate ter recebido o contrato devidamente assinado. Após a assinatura do contrato a Migrate irá liberar o ambiente de Produção, onde você receberá um e-mail contendo os dados de acesso do ambiente, como usuário e senha, bem como o link de acesso ao portal. Em caso de dúvidas referente este procedimento contate imediatamente seu Gerente de Contas, ou envie um e-mail para comercial@migrate.com.br.

2. CADASTRE SEUS CLIENTES! Após o recebimento dos dados de acesso ao ambiente de Produção por e-mail, seu primeiro passo será efetuar o cadastro de seus clientes no InvoiCy. ATENÇÃO! O processo de cadastro é IRREVERSÍVEL e passível de COBRANÇA! Uma vez cadastrada, a empresa não poderá mais ser excluída, e a ativação de sua licença poderá iniciar o processo de cobrança. Só efetue o cadastro de uma empresa no ambiente de Produção se tiver certeza de sua utilização. Em caso de dúvidas no processo de cadastro consulte o artigo “Cadastrar uma empresa via Interface Web”.

3. AJUSTE SEU XML DE INTEGRAÇÃO! Para que seja possível realizar a emissão do primeiro documento em ambiente de Produção, atente-se para alguns ajustes que devem ser realizados no XML de integração.

     3.1 TAG <tpAmb>: Em ambiente de homologação esta tag era enviada com o valor 2. Agora em Produção é necessário enviar o valor 1, que corresponde ao ambiente de Produção. Ex: <tpAmb>1</tpAmb>.

     3.2 TAGS <ChaveParceiro> e <ChaveAcesso>: Apenas para quem realiza integração com o InvoiCy Conector, altere as tags <ChaveParceiro> e <ChaveAcesso> com as chaves do ambiente de Produção. Para obter essas chaves acesse o ambiente de Produção, menu Painel de Controle > Dados da Empresa. Para integrações via Web Service ver item 4.

4. CHAVE DE COMUNICAÇÃO: Em ambiente de Produção atente-se para o correto uso das chaves para comunicação com o InvoiCy. No ambiente de homologação era utilizado uma chave de acesso para geração do hash MD5 de comunicação. Já em Produção, é gerada outra chave. A chave de parceiro não é alterada. Para encontrar a nova chave de acesso que deve ser utilizada acesse no ambiente de Produção o menu Painel de Controle > Dados da Empresa.

5. ALTERAÇÃO DO WEB SERVICE: Para comunicação com o InvoiCy em ambiente de Produção altere o Web Service de sua aplicação para: https://app.invoicy.com.br/arecepcao.aspx?WSDL. Já para quem realiza integração via InvoiCy Conector, acesse a tela abaixo e efetue a devida alteração de sua instância para ambiente de PRODUÇÃO:

6. LICENCIAMENTO: Caso não tenha licenciado a empresa, vá até a tela Painel de Controle > Módulos Contratados e efetue o licenciamento de acordo com o módulo contratado. Para maiores informações consulte o artigo “Licenciamento de Empresas”.

Após estas alterações você estará apto para realizar a emissão em Produção. Em caso de dúvidas ou problemas nas primeiras emissões em Produção envie um e-mail para integracao@migrate.com.br. Estaremos dispostos a lhe auxiliar.

Chave de Comunicação Inválida

 

Olá! Neste artigo vamos apresentar algumas das principais causas do retorno 173 – Chave de Comunicação inválida, muito comum no início da integração, e que pode causar bastante dúvida no início dos testes de desenvolvimento.

Vamos lá! Antes de mais nada, devemos entender como funciona o processo de validação da chave de comunicação no InvoiCy. A essa altura, você já deve saber que é necessário gerar uma chave de comunicação MD5, com base na chave de acesso da empresa com o XML que está sendo enviado. Essa informação é informada no parâmetro “EmpCK” do WebService. Caso tenha dúvidas quanto a geração do MD5, consulte o respectivo artigo clicando aqui.

Quando ocorrer alguma falha na geração desta chave MD5, você receberá o retorno 173 – Chave de Comunicação Inválida. Abaixo seguem alguns dos problemas rotineiros na geração da chave, que geram este retorno:

  • Usar chave errada para geração do MD5. Conforme visto no artigo “Gerando o Código Hash no formato MD5”, é necessário utilizar a chave de acesso da empresa cadastrada no InvoiCy. Ao término do cadastro de uma empresa, é gerada a chave que deve ser usada neste processo. Para se certificar de que está utilizando a chave correta, acesse no InvoiCy o Painel de Controle > Dados da empresa, e clique sobre o botão “Chave de Acesso”. Esta é a chave que deve ser utilizada para geração do MD5.
  • Enviar palavras com acentuação gráfica ou caracteres especiais no XML do documento. Não é permitido o envio de caracteres especiais no XML.
  • Dupla conversão do XML para texto. Sabemos que no momento do envio de um documento ao WebService, os caracteres < e > do XML devem ser substituídos por &lt; e &gt; respectivamente. A maioria das ferramentas de desenvolvimento já realiza essa conversão de forma automática, não sendo necessário fazer a conversão manualmente. Porém, quando é realizada a conversão manual e a ferramenta também realiza essa conversão, ocorre a dupla conversão, o que irá causar erro no momento do envio da nota, e poderá causar também erro de chave de comunicação inválida.
  • Modificar informações no XML após geração do MD5. Não é permitido alterações no XML após geração do MD5. Em caso de qualquer alteração, deverá ser gerado novamente o MD5.
  • Problemas no método gerador de MD5 da ferramenta de desenvolvimento. Principalmente na linguagem DELPHI, costuma ocorrer falha no processo de geração do MD5. Para comparar um MD5 gerado pela aplicação com o MD5 correto, pode-se usar o seguinte site: http://www.miraclesalad.com/webtools/md5.php

Basta inserir a chave de acesso mais o XML (tudo junto e linearizado), e então verificar o MD5 gerado.

Contingência para Módulo CT-e

Última atualização em: 19 de fevereiro, 2018

 

Olá! Neste artigo iremos falar sobre o processo de envio de documentos em contingência, as possíveis situações que podem acontecer e como o emissor deve proceder em cada uma delas.

Primeiramente o emissor deve definir as configurações relacionadas a contingência para sua empresa. Para isso, basta acessar o Painel de Controle, módulo CT-e, Configurações para emissão, como demonstra a imagem.

 

Para o módulo CT-e estão disponíveis as formas de contingência EPEC, SVC e Nenhuma, onde o InvoiCy possibilita que o emissor defina qual a opção de emissão será priorizada no momento em que o ambiente normal estiver indisponível.

Para definir a ordem das opções de emissão basta clicar nas flechas que estão ao lado de cada uma das opções, até posicioná-las na forma desejada. O InvoiCy fará o envio do documento de acordo com a primeira opção de contingência que estiver configurada. Caso a primeira opção de contingência não esteja disponível, será realizada uma tentativa de envio para a opção seguinte, seguindo assim para todas as opções e só encerrando o processo ao chegar na opção Nenhuma.

 

Opções de contingência

Bem, antes de definir qual será a primeira opção de emissão em contingência, vamos entender as diferenças entre os ambientes SVC e EPEC.

O ambiente da SEFAZ Virtual de Contingência (SVC) tem sua disponibilidade controlada pela SEFAZ, sendo ativado geralmente quando a SEFAZ de origem realiza alguma manutenção programada em sua estrutura. Nestas circunstâncias, a SEFAZ de origem solicitará a ativação do ambiente SVC para sua UF, que passará a receber seus CT-e por um tempo pré-definido. Os CT-e autorizados pela SVC não precisam ser reenviados, pois a sincronização dos documentos entre a SVC e a SEFAZ de origem é realizada automaticamente.

Já o Evento Prévio de Emissão em Contingência (EPEC) está disponível a qualquer momento, sendo recebido pelo Ambiente Nacional, porém um evento de CT-e registrado neste ambiente, necessita obrigatoriamente, de seu posterior envio para a SEFAZ de origem, realizando assim a conciliação do evento junto a autorização do CT-e.

Outra informação que deve ficar entendida é que a contingência é definida por UF e não por empresa, ou seja, a partir do momento que qualquer uma das empresas emitentes em determinada UF deixar de receber o retorno de um documento da SEFAZ, esta UF passará a operar em contingência e todas as demais empresas desta UF também.

A partir do momento em que a contingência for ativada, o InvoiCy passará a verificar a ordem de contingência configurada em cada empresa e fará o envio dos documentos conforme esta configuração.

 

Contingência SVC

Se a contingência SVC estiver configurada como primeira opção, o InvoiCy fará o envio do documento para o ambiente da SVC, que uma vez estando ativo, fará as validações do documento e em caso de efetivação o emissor receberá como retorno o código 100, o arquivo xml e o DACTE (conforme configurações da empresa), indicando que o documento foi autorizado. Nesse caso o processo de envio em contingência foi executado com sucesso, o documento está autorizado e o emissor não tem a necessidade de consultar o status do documento, pois conforme vimos acima, a sincronização entre os ambientes será automática.

Em caso de rejeição o emissor deverá fazer a correção e o reenvio do documento. Se o ambiente da SVC não estiver ativo, o InvoiCy fará uma nova tentativa de envio do documento para o EPEC, caso esta for a segunda opção de contingência configurada, senão o processo termina neste momento e o documento ficará com o status Pendente.

Acesse o fluxo da contingência SVC.

 

Contingência EPEC

Agora, se a primeira opção for a contingência EPEC, o InvoiCy fará o envio de um evento com os dados do documento para o ambiente nacional da SEFAZ, onde passará por validações básicas em sua estrutura e em caso de autorização o emissor receberá como retorno de status da comunicação o código 109, e como retorno de status do documento o código 136, sem o arquivo xml, mas com o DACTE para transporte da mercadoria. Isto significa que o documento foi emitido porém ainda não está autorizado na SEFAZ, ou seja, o emissor deverá realizar, em um segundo momento, a consulta desse documento para atualização de status e obtenção do XML completo de autorização.

Acesse o fluxo da contingência EPEC.

Vale ressaltar que no momento em que a comunicação com a SEFAZ de origem for restabelecida, o IncoiCy fará automaticamente o envio de todos os documentos emitidos em EPEC para a sua SEFAZ de origem, buscando sua autorização e consequentemente a conciliação do evento EPEC. Em caso de rejeição o emissor deverá fazer a correção e o reenvio do documento.

Pode acontecer ainda a situação de nenhuma das contingências configuradas estarem disponíveis, então o documento ficará como pendente no InvoiCy e não será emitido. O emissor receberá como retorno de status da comunicação o código 109, e como retorno de status do documento o código 105.

109 – SEFAZ em contingência

105 – Documento pendente

Resumo: O emissor estará temporariamente impedido de emitir e deverá realizar uma consulta antes de fazer o envio do próximo documento.

 

Códigos de retorno

É importante salientar que o emissor deve estar atento aos códigos de retorno do status do documento, e não apenas para o código de retorno da comunicação. Para auxiliar na identificação de ambos, o código de status da comunicação pode ser observado no cabeçalho de retorno do SOAP. Já o código do status do documento pode ser visualizado dentro do arquivo xml do documento.

Uma vez definida a utilização do EPEC, o emissor deverá tratar em sua integração o código de retorno 136, de forma que o ERP consiga interpretar o mesmo, pois quando um documento for emitido em EPEC, os códigos retornados serão 109 para o status da comunicação e 136 para o status do documento. Neste caso o emissor deverá fazer uma consulta posteriormente destes documentos buscando a atualização de seus status e não deverá realizar seu reenvio enquanto não obtiver um novo status. Isso irá evitar problemas de duplicidade de documento com diferença na chave de acesso e bloqueio de empresas para emissão de novos documentos em EPEC. Em caso de bloqueio da empresa, o artigo Desbloqueio de EPEC explica como proceder nessa situação.

109 – SEFAZ em contingência

136 – Contingência EPEC

Resumo: Para os documentos com estes status, o emissor deverá realizar consultas para a atualização de status e fazer seu reenvio somente quando receber um status diferente do atual.

Outro código que precisa ser tratado na integração é o 108, que será retornado para o documento que identificar a indisponibilidade da SEFAZ de uma UF. Isso irá ocorrer quando o InvoiCy receber um documento e não conseguir enviá-lo à SEFAZ ou não obtiver o seu retorno junto a SEFAZ, detectando neste momento a necessidade de entrar em modo de contingência. O documento que identificar a contingência ficará com o status “Necessita interação” no InvoiCy e o emissor receberá como retorno do InvoiCy o código 108, tanto para o status do documento, como para o status da comunicação.

108 – Entrada da SEFAZ em contingência: [erro_encontrado]

108 – Entrada da SEFAZ em contingência: [erro_encontrado]

Resumo: Quando um documento se encontra com o status ‘Necessita Interação’, significa que esse documento identificou uma instabilidade na comunicação com a SEFAZ e o InvoiCy não obteve retorno satisfatório. O fluxo indicado pela Migrate para tratamento nesse caso, é envia-lo novamente incrementando a numeração e referenciar o documento que está como ‘Necessita Interação’ para descarte. Através deste processo o InvoiCy verificará o status deste documento, caso ele esteja autorizado ele será cancelado e caso não conste na SEFAZ a numeração será inutilizada. Esse modelo de descarte permite que o fluxo de emissão siga sem interrupções de forma automática e transparente para o emissor. Recomendamos a leitura do artigo Referenciando documento emitido anteriormente” para compreender o funcionamento desse processo.

Quando é executado o processamento automático desse documento que ficou com status ‘Necessita Interação’, o sistema realiza uma consulta do mesmo na SEFAZ a fim de obter seu status, caso essa consulta tenha sucesso o documento será apresentado na plataforma de acordo com o retorno obtido da SEFAZ, caso a consulta retorne que o documento não existe na base de dados da SEFAZ, esse será alterado para status de ‘Rejeitado’ no painel do InvoiCy permitindo assim que o ERP realize o reenvido dessa numeração. É muito importante que seja executado o reenvio do documento somente após obter o retorno de ‘Rejeitado’.

Uma informação importante quanto ao código 108 é que um único documento por UF irá receber este retorno ao identificar alguma falha de comunicação com a SEFAZ, pois a partir disso todos os demais documentos das empresas que emitam nesta mesma UF passarão a emitir automaticamente em modo de contingência. Outro detalhe é que este retorno independe do tipo de contingência utilizada pela empresa que enviou o documento e detectou a falha de comunicação.

 

Por que avançar numeração e referenciar o documento anterior?

Esta regra foi implementada para evitar problemas com o documento que identificar a contingência, uma vez que neste momento não é possível saber se o documento chegou até a SEFAZ ou não. Realizando este tratamento o emissor consegue garantir que um documento que pode estar efetivado na SEFAZ não seja enviado também para a SVC ou EPEC, por exemplo. Supondo que o documento esteja efetivado na SEFAZ e seja feito simplesmente o seu reenvio pelo sistema, como o InvoiCy já estará operando em modo de contingência ele fará o envio para uma das opções (SVC ou EPEC), podendo gerar os seguintes problemas:

– Se o documento for enviado e efetivado na SVC, irá ocorrer falha na sincronização entre os ambientes, devido a duplicidade de documento com diferença nas chaves de acesso;

– Se for enviado para EPEC, o problema irá ocorrer no momento da conciliação do documento, pois o documento teve um EPEC com horário posterior a sua autorização.

Uma vez referenciado o documento, o InvoiCy se encarrega de realizar as ações necessárias sobre ele, realizando seu cancelamento ou inutilização, conforme for a situação em que o mesmo se encontra junto a SEFAZ.

 

Restabelecimento de comunicação

Após cessarem os problemas de comunicação com a SEFAZ da UF o InvoiCy voltará ao modo de comunicação normal e passará a verificar quais documentos precisam receber algum encaminhamento.

Para o documento que identificou a contingência e foi referenciado no segundo documento, o InvoiCy fará automaticamente a sua consulta junto a SEFAZ. Se estiver efetivado será providenciado seu cancelamento, caso contrário, a sua inutilização.

Já para os documentos emitidos em EPEC, o InvoiCy irá realizar seu envio para conciliação, podendo ser efetivado ou rejeitado. Estes são os casos de retorno 136, onde o emissor deverá fazer a consulta dos documentos para atualização de seus status e reenvio, quando necessário.

Para facilitar o entendimento do emissor, foi elaborado um fluxo abrangendo todas as situações de emissão em contingência, bem como o retorno de cada situação.

Durante o processo de envio, ainda podem acontecer situações como o Aplicativo Comercial ou ERP não possuir conexão com a internet, ou a conexão com o InvoiCy ser perdida durante o processo de emissão e não dar nenhum retorno do documento.

Na primeira situação o documento não será enviado para o InvoiCy, sendo responsabilidade do emissor ajustar a sua infraestrutura para permitir a comunicação com o InvoiCy. Já na segunda situação, o emissor deverá consultar o status do documento para verificar se o mesmo já não foi emitido, ou se será necessário enviá-lo novamente.

Desbloqueio de EPEC

Última atualização em: 11 de fevereiro, 2015

 

O que é o EPEC?

A SEFAZ disponibilizou uma nova forma de emissão em contingência, o EPEC ou Evento Prévio de Emissão em Contingência, que permite a empresa emitir uma solicitação de registro de evento de CT-e ou NF-e anterior à emissão do documento em si com um layout mínimo de informações. Esse evento deve ser enviado para o Ambiente Nacional (AN), utilizando-se o Web Service de Eventos genérico, criado para este fim.

A emissão do evento tem como objetivo permitir que a empresa continue sua operação, uma vez que autorizado o EPEC, esta poderá imprimir o DACTE/DANFE e realizar a prestação do serviço.

Conforme disponível na NT2012/004, a emissão do EPEC poderá ser adotada por qualquer emissor que esteja impossibilitado de transmissão e/ou recepção das autorizações de uso de seus CT-e ou NF-e.

Após realizada a autorização do Evento EPEC, da mesma maneira que para os demais eventos, o EPEC também será distribuído para as UF envolvidas na operação, inclusive para a própria UF do emitente.

Eventos do tipo EPEC devem ser reenviados no período máximo de sete dias (168 horas) para obterem sua efetivação, utilizando ainda o “tpEmis” = 4. Esse reenvio deve ser realizado para que as emissões feitas em EPEC não entrem em lista de pendências na SEFAZ.

Destacando que esse modelo de contingência deverá ser utilizado somente em casos de dificuldade técnica, sendo que o uso de forma contínua poderá ser bloqueado por regra de validação ou medida restritiva.

Após cessarem os problemas o InvoiCy fará a conciliação automática dos Documentos que foram emitidos em EPEC, e durante esse processo se algum documento rejeitar e não for corrigido e reenviado em até sete dias este ficará pendente de conciliação.

Decorrido o prazo para reenvio o ambiente de contingência EPEC será bloqueado para este emitente, e para liberar o uso do Ambiente de Contingência EPEC a empresa deverá corrigir o documento rejeitado e envia-lo novamente.

Durante o processo de testes de integração pode ocorrer algum erro na emissão, e autorizar o EPEC e o documento que o originou. Neste caso, a empresa também ficará bloqueada para emitir em ambiente de contingência EPEC. Para continuar emitindo deve desbloquear a empresa seguindo as seguintes instruções:

1) Fazer um termo no livro de ocorrências. Fotocopiar a capa do livro e o Termo de Ocorrência lavrado pela empresa e protocolizar. Deve-se obedecer, no que couber o Regulamento do ICMS do estado do emissor.

2) Fazer requerimento solicitando a regularização do caso, explicando o ocorrido.

3) Junto com o requerimento anexar cópia de Termo no Livro de Ocorrências e Documentos Fiscais relatando o fato. Pode ser realizado pelo contador do contribuinte.

4) Protocolar em Agência da Receita do Estado do emissor. Pode ser realizado pelo contribuinte.

Importante ressaltar que se o contribuinte não protocolar este requerimento, permanecerá bloqueado para a emissão de novos EPEC em casos de entrada em contingência.

Para visualizar um modelo do requerimento que deve ser enviado, clique aqui.

Quando o documento for emitido em EPEC, será retornado o código 136 no status do documento, assim como, será gerado duas vias do DACTE/DANFE conforme a legislação. Neste caso não será retornado o XML do documento, pois este será enviado automaticamente pelo InvoiCy à SEFAZ quando a mesma voltar a operar. Para obter o XML do documento, posteriormente poderá ser feita uma consulta.

Layout de CC-e para CT-e

Última atualização em: 06 de junho, 2017

 

Olá! Este artigo tem por objetivo disponibilizar o layout do XML da CC-e. Aqui você irá encontrar a estrutura completa de campos da Carta de Correção Eletrônica, para realizar a integração de seu ERP com o InvoiCy.

A tabela abaixo deve ser utilizada como legenda para interpretação dos campos do arquivo do envio e retorno do XML.

Coluna

Nome do Campo

Tipo

(tamanho)

N – campo numérico C – campo alfanumérico D – campo data H – campo hora

Ele

G – Grupo E – Elemento CG – Elemento de Grupo que deriva de uma escolha (choice) CE – Elemento que deriva de uma escolha (choice)

Pai

TAG raiz do XML de integração

Ocorrência

x-y, onde x indica a ocorrência mínima e y, a ocorrência máxima:

1-1  = campo obrigatório, com uma possibilidade,

1-N = campo obrigatório, com uma ou várias possibilidades,

0-1  = campo opcional, com uma possibilidade,

0-N = campo opcional, com uma ou várias possibilidades.

LAYOUT CC-e

 

Acesse também a Central de Downloads Migrate, onde você poderá encontrar diversos exemplos reais da Carta de Correção Eletrônica para download.