BigWings

O código numérico da chave de acesso *deve* ser um número randômico. Existem muitos casos de fraude envolvendo empresas que emitem NFe com o código numérico igual ao número da nota, ou usando uma sequência qualquer. As próprias SEFAZ já estão advertindo emissores que fazem uso dessa prática. Gere um número randômico na sua aplicação e informe no .ini, assim você sabe qual será a chave de acesso.

Foi incluída essa validação na NT 2016.002. O motivo provável é que, como os veículos já serão obrigatoriamente informados no MDFe, não há necessidade de informar na NFe.

Para o SINTEGRA veja este tópico: Para o SPED Fiscal gera-se o C100 e C190.

Editei seu post pois continua a chave digital do prestador em um dos arquivos. Houve uma atualização no webservice com alteração de schema. Se você usar o debug pode obter o retorno do webservice no seu envio: <GerarNfseResposta><ListaMensagemRetorno><MensagemRetorno><Codigo>Erro</Codigo><Mensagem>O elemento 'http://www.agili.com.br/nfse_v_1.00.xsd:Codigo' é inválido - O valor '-1' é inválido dependendo do tipo de dados 'http://www.agili.com.br/nfse_v_1.00.xsd:tsRegimeEspecialTributacao' - Falha na restrição Pattern.</Mensagem><Versao>1.00</Versao></MensagemRetorno></ListaMensagemRetorno></GerarNfseResposta> Segue correção, substitua os arquivos em suas devidas pastas, recompile o ACBr e teste. pnfsConversao.pas pnfsNFSeR.pas pnfsNFSeW_Agili.pas nfse_v_1.00.xsd xmldsig-core-schema20020212.xsd Agili.ini

Você vai ser obrigado a informar o GTIN para alguns NCMS/CNAE específicos, como brinquedos, cigarro e medicamentos. Itens sem GTIN devem ser enviados com cEAN = "SEM GTIN". Deve-se consultar a legislação sobre isso, se a indústria já não é obrigada a ter cadastros das mercadorias que produz. O que será validado é a informação do código de barras na tag cEAN, caso não seja um código de barras registrado, não pode informá-lo nessa tag.

A NT 2012.002 me parece clara nessa questão: Então, a menos que o contador tenha posse do certificado digital do destinatário da NFe, ele não pode assinar o evento de manifestação. Os demais interessados na NFe, como o transportador e terceiros, não podem fazer a manifestação, nem precisam dela pra ter acesso ao XML completo da NFe.

Bom dia. O manual pede que se informe a alíquota dividida por 100: Trecho do demo do ACBr: Imposto.PIS.CST := pis49; Imposto.PIS.vBC := TotalItem; Imposto.PIS.pPIS := 0.0065;

Não existe manifestação do destinatário para CTe. Também não há método que recupere o XML do CTe pela chave do mesmo, como há para NFe. É possível fazer a consulta pelo último NSU recebido, ou por um NSU específico. http://www.cte.fazenda.gov.br/portal/exibirArquivo.aspx?conteudo=5c1PwLTdrCA=

https://svn.code.sf.net/p/acbr/code/tags/ACBrTrunk2015

Quando a resposta vem em um formato não esperado como esse caso pode aparecer a mensagem em branco. Você pode ativar a gravação dos arquivos de envio e retorno e analisar por lá. Creio que não. A sua mensagem de erro e a do outro post é idêntica, inclusive apontando mesma linha e coluna... o mais provável é que seja um erro no webservice.

Minha pergunta é em relação a qual componente DANFE está associado ao componente ACBrNFe no momento da impressão. Se for um componente DANFE NFCe, ou um componente DANFE configurado para imprimir NFCe ele vai tentar descobrir a URL do QRCode para impressão no DANFE, que não existe para MG no ACBrNFeServicos.ini. Veja que no demo do ACBr a atribuição do componente é feita em tempo de execução, de acordo com a configuração: if cbModeloDF.ItemIndex = 0 then ACBrNFe1.DANFE := ACBrNFeDANFEFR1 else ACBrNFe1.DANFE := ACBrNFeDANFCeFortes1 ; Estando configurado para imprimir NFCe, mesmo que você carregue um XML de NFe pode causar o erro.

Tente alterar esta linha para ACBrNFe1.NotasFiscais.LoadFromFile (OpenDialog1.FileName, False); Verifique também qual o DANFE associado, se não está configurado para imprimir a NFCe.

Apenas imprimir o DANFe de um XML não deveria tentar carregar a URL... Qual o passo a passo para reproduzir o erro pelo demo do ACBr?

Se não me engano ainda não há URL divulgadas para NFCe em MG, nem mesmo homologação. Caso tenha as URL informe aqui.

Essa validação foi excluída na versão 1.10 da NT 2016.002. Então, certifique-se de que o XML está sendo gerado na versão 4.00. Caso esteja, entre em contato com a SEFAZ do estado e questione se todas as atualizações da NT 2016.002 foram aplicadas ao webservice. Provavelmente não foram.

Bom dia, Antes dessa alteração os arquivos *-eve*.xml e *-ped-eve*.xml estavam sendo salvos na pasta configurada em PathEvento, e os *-inu*.xml e *-ped-inu*.xml na pasta configurada em PathInutilizacao. Após a alteração eles passam a ser salvos na pasta configurada em PathSalvar. Os arquivos *-procEvento*.xml e *-procInut*.xml continuam sendo salvos nas pastas configuradas em PathEvento e PathInutilizacao, respectivamente.

@Juliomar Marchetti @hleorj Segue correção de compatibilidade. ACBrNFeDANFEFRDM.pas

Sem a confirmação de que o webservice ou qual webservice atende a requisição de envio de evento da versão 4.00 da NFe, não adianta alterar o ACBrNFeServicos.ini. Você só terá um retorno o diferente que causa o mesmo erro no final.

Italo, Notei que os arquivos de envio e retorno referentes a eventos e inutilizações estava sendo gravadas nas pastas erradas, misturando com os XML de eventos e inutilização, respectivamente. Segue correção para análise anexos. ACBrNFeWebServices.pas ACBrCTeWebServices.pas ACBrMDFeWebServices.pas

Verificando as URL divulgadas no portal nacional podemos observar que MG foi a única a não disponibilizar um webservice de recepção de evento específico para a versão 4.00 da NFe. http://hom.nfe.fazenda.gov.br/portal/webServices.aspx?tipoConteudo=Wak0FwB7dKs=#MG O único webservice disponível é a versão 1.00 que não teve alterações até a versão 3.10 da NFe. Entretanto o cabeçalho de envio dos XML na versão 4.00 mudou, e esse webservice aparentemente não atende mais. Debugando você pode obter o retorno do WebService: <?xml version="1.0" encoding="UTF-8"?><soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope"><soap:Body><soap:Fault><soap:Code><soap:Value>soap:Sender</soap:Value></soap:Code><soap:Reason><soap:Text xml:lang="en">Message part {http://www.portalfiscal.inf.br/nfe/wsdl/NFeRecepcaoEvento4}nfeDadosMsg was not recognized. (Does it exist in service WSDL?)</soap:Text></soap:Reason></soap:Fault></soap:Body></soap:Envelope> Caso se faça o ajuste no ACBrNFeServicos.ini para usar o SoapAction dessa URL, temos o retorno: <?xml version="1.0" encoding="UTF-8"?><soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope"><soap:Body><soap:Fault><soap:Code><soap:Value>soap:Receiver</soap:Value></soap:Code><soap:Reason><soap:Text xml:lang="en">Fault occurred while processing.</soap:Text></soap:Reason></soap:Fault></soap:Body></soap:Envelope> O que você precisa fazer, a meu ver, é entrar em contato com a SEFAZ-MG e questionar se vai ser liberado um webservice de recepção de evento da versão 4.00, nos padrões definidos na NT 2016.002:

Favor manter-se no assunto do tópico. Seu problema tem a haver com alterações mais recentes no componente. Acompanhe o tópico a seguir:

Está acusando caractere ilegal no XML: Tem alguma quebra de linha no seu XML de envio? Veja também este tópico sobre o mesmo erro: Veja que você informou número de série e arquivo pfx, só é necessário informar um.

Foi feita uma correção recente sobre isso, você está com os fontes atualizados?

Veja a regra de validação G085: