Italo Giurizzato Junior

Alexsandro, Fiz um teste e também tive o mesmo erro.

Boa tarde BigWings, Se não me falha a memória um outro membro do fórum fez uma correção no EL.

Boa tarde Nickolas, Esta ocorrendo uma confusão. Ao enviar o XML do CT-e para ser averbado este deve ser colocando dentro do CDATA, a averbação ocorreu com sucesso, pois o CT-e só a partir de 26/08/2019 será obrigado a ter em seu XML a string do QR-Code em ambiente de Produção. Para quem deseja testar em homologação a data prevista é hoje. Implantada versão 3.00a e Comprovante de Entrega em HMLE na SVRS Foi implantada em homologação na SVRS a versão 3.00a do CT-e e CT-e OS na data de hoje (22/07). A versão contempla alterações nas regras de validação de chave de acesso relacionadas, introdução do QR Code no schema XML e a criação dos eventos de comprovante de entrega e cancelamento do comprovante de entrega do CT-e.

Boa tarde Emerson, Na estrutura de pastas do Branches, consta a pasta que contem o programa exemplo, os fontes do componente e do Pacote de Instalação. É necessário pegar essas pastas do ACBrCiot que esta no Branches e copiar para a estrutura do Trunk2. Feito isso através do Dephi abrir o pacote de instalação, compilar e instalar. Por fim abrir o programa exemplo e iniciar os testes.

Boa tarde Marcio, Muito obrigado pela colaboração, já enviei para o repositório.

Oliveira, Basta abrir o arquivo Cidades.ini e procurar pelo provedor que atende essa cidade e acrescentar ela da mesma forma que foi incluída para outras cidades do mesmo provedor. Talvez seja necessário abrir o arquivo INI do respectivo provedor e acrescentar as URLs de produção e de homologação para a respectiva cidade. Resumindo veja como foi feito para as demais cidades que utilizam o mesmo provedor e faça igual. Se tudo der certo favor anexar os arquivos alterados para que possamos enviar para o repositório.

Boa tarde Nebrio, O que tem na classe WebServices é uma propriedade chamada aMsg que contem uma mensagem de retorno que pode ser de erro ou não. Logo não tem nada haver com mensagem de cabeçalho ao enviar. O cabeçalho quando este deve ser gerado ele é colocado dentro do grupo Header que faz parte da estrutura do <Envelope>.

Boa tarde Oliveira, A cidade em questão é Serra Azul/SP ou Caieiras/SP ?

Boa tarde Alexsandro, Favor atualizar os fontes, note que fiz uma alteração no arquivo Cidades.ini Utilize o programa exemplo do componente para realizar os testes.

Bom dia Nickolas, Tanto o MDF-e quanto o CT-e (a partir de hoje em homologação e 26/08/2019 em produção) devemos informar a string do QR-Code na tag qrCodMDFe (para o MDF-e) e qrCodCTe (para o CT-e). Nessa string temos o caractere "&", sendo assim se faz necessário o uso do CDATA, para que a validação do XML ocorra sem nenhum problema. A remoção do CDATA do XML apesar de não tornar o XML invalido, uma vez que este é assinado antes da inclusão da tag qrCodMDFe / qrCodCTe, não faz sentido. A ATM por sua vez tem que fazer os ajustes necessários para que o XML do CT-e ou MDF-e sejam aceitos conforme o manual, ou seja, com o CDATA.

Bom dia Asterix, A sua alteração esta correta, aproveitei fiz a mesma correção no CT-e e enviei tudo para o repositório.

Bom dia Allan, Você poderia anexar um XML onde esse problema ocorre?

Ricardo, Acho que você não entendeu o problema no nosso amigo Nickolas. No XML a tag <qrCodMDFe> o seu conteúdo esta entre: <![CDATA[ .... ]]> O motivo de ter o CDATA é por causa do caractere "&" que aparece antes do campo tpAmb. O CDATA tem a função de indicar que o texto dentro dele é um texto comum e não pode ser interpretado como parte da marcação do XML. E ao enviar o XML do MDF-e para a seguradora fazer a averbação o recusa. Para removermos o CDATA do XML do MDF-e a SEFAZ teria que trocar o caractere "&" por "|" como fez na NF-e. Enquanto isso não ocorre, a seguradora vai ter que ajustar o seu sistema para aceitar o XML do MDF-e com o CDATA.

Boa tarde Ricardo, Favor anexar o XML que foi gerado e autorizado pela SEFAZ.

Boa tarde Fátima, Se o tomador do serviço é do exterior não tem como informa-lo no grupo de informações do contratante, pois nesse grupo só podemos informar o CNPJ ou CPF do mesmo.

Boa tarde Nickolas, Faça o seguinte teste: Gere o XML do MDF-e sem o ![CDATA], assina, valida e envia para a SEFAZ. Depois nos conta se a SEFAZ autorizou ou não o MDF-e.

Boa tarde Emerson, Você tem que pegar a URL de configuração do trunk2 que foi informada no Tortoise e mudar de trunk2 para branches. A URL para baixar os fontes do Trunk2 é: svn://svn.code.sf.net/p/acbr/code/trunk2 A URL para baixar os fontes do Branches é: svn://svn.code.sf.net/p/acbr/code/branches

Olá pessoal, Para quem utiliza o componente ACBrCTe e necessita emitir um CT-e de Substituição deve alimentar os seguintes campos: Vamos a estrutura completa: with infCTeNorm.infCteSub do begin chCte := chaveCTeOriginal; indAlteraToma := tiNao ou tiSim; // Se atribuir tiSim significa que foi alterado o tomador // Para tomador contribuinte do ICMS tomaICMS.refNFe := chaveNFe; // NF-e de anulação emitenta pelo tomador // ou informações da Nota Fiscal comum de papel emitida pelo tomador tomaICMS.refNF.CNPJCPF := sCNPJCPF; tomaICMS.refNF.modelo := sModelo; tomaICMS.refNF.serie := iSerie; tomaICMS.refNF.subserie := iSubSerie; tomaICMS.refNF.nro := iNumero; tomaICMS.refNF.valor := vValor; tomaICMS.refNF.dEmi := DataEmissao; // ou a chave do CT-e emitido pelo tomador quanto este for uma transportadora tomaICMS.refCte := ChaveCTeTomador; // caso tenha sido emitido o CT-e de Anulação informar a chave do mesmo no campo abaixo refCteAnu := ChaveCTeAnulacao; end; Exemplo 1: Caso tenha sido emitido um CT-e de Anulação with infCTeNorm.infCteSub do begin chCte := chaveCTeOriginal; indAlteraToma := tiNao ou tiSim; // Se atribuir tiSim significa que foi alterado o tomador // CT-e de Anulação informar a chave do mesmo no campo abaixo refCteAnu := ChaveCTeAnulacao; end; Exemplo 2: Caso o tomador tenha emitido uma NF-e de Anulação with infCTeNorm.infCteSub do begin chCte := chaveCTeOriginal; indAlteraToma := tiNao ou tiSim; // Se atribuir tiSim significa que foi alterado o tomador // Para tomador contribuinte do ICMS tomaICMS.refNFe := chaveNFe; // NF-e de anulação emitenta pelo tomador end; Exemplo 3: Caso o tomador tenha emitido uma Nota Fiscal comum de papel with infCTeNorm.infCteSub do begin chCte := chaveCTeOriginal; indAlteraToma := tiNao ou tiSim; // Se atribuir tiSim significa que foi alterado o tomador // Informações da Nota Fiscal comum de papel emitida pelo tomador tomaICMS.refNF.CNPJCPF := sCNPJCPF; tomaICMS.refNF.modelo := sModelo; tomaICMS.refNF.serie := iSerie; tomaICMS.refNF.subserie := iSubSerie; tomaICMS.refNF.nro := iNumero; tomaICMS.refNF.valor := vValor; tomaICMS.refNF.dEmi := DataEmissao; end; Exemplo 4: Caso o tomador seja uma transportadora e tenha emitido um CT-e with infCTeNorm.infCteSub do begin chCte := chaveCTeOriginal; indAlteraToma := tiNao ou tiSim; // Se atribuir tiSim significa que foi alterado o tomador // chave do CT-e emitido pelo tomador quanto este for uma transportadora tomaICMS.refCte := ChaveCTeTomador; end;

Boa tarde Christiano, Neste ultimo XML o campo CRT continua com o valor 1, tem que ser 2 ou 3.

Bom dia Michel, Anexe um arquivo TXT com o fragmento da sua rotina que alimenta o componente os dados do seguro, acredito que ela esteja errada.

Bom dia Emerson, Você precisa criar uma pasta com outro nome (pode ser ACBrBranches) e configurar o tortoise com a mesma URL alterando o final, em vez de trunk2 mude para branches. Desta forma você vai baixar os fontes que se encontram no repositório branches. Feito isso será necessário copiar os fontes do componente, do pacote de instalação e do programa exemplo para a estrutura de pastas do trunk2. Através do Delphi abrir o pacote de instalação e instalar o componente e por fim fazer testes com o programa exemplo.

Obrigado por reportar. Fechando. Para novas dúvidas, criar um novo tópico.

Bom dia Felipe, Não precisa alterar nenhuma propriedade de configuração, apenas atualize todos os fontes de todas as pastas e reinstale a suíte ACBr usando o ACBrInstall_Trunk2 com a opção apagar arquivos antigos marcada.

Bom dia Marcos, No manual consta como facultativo, mas existe um observação abaixo dessas regras que diz que a SEFAZ poderá ativar ou desativar essas regras caso ela consiga ou não ter acesso ao sistema da ANTT para poder fazer as devidas validações referente ao RNTRC.

Bom dia Ricardo, Procurando por essas propriedades notei que elas estão presentes para o DANFE feito em Fast Report. Caso queira colaborar com o projeto e implementar no DACTE, DAMDFE e DANFSE aos moldes do DANFE ficaremos gratos.