Márcio B.

Eu testei com o DNS e funcionou e também testei mudando o arquivo hosts da pasta C:\Windows\System32\drivers\etc adicionando a linha e também funcionou: 200.233.4.145 mdfe.svrs.rs.gov.br

Boa tarde, Acabei de fazer um CTe mineiro em produção com sucesso e também já fiz o cancelamento dele. Não mudei nada no ACBr e já joguei em produção.

Apenas... para avisar que também estou com problemas. Acabei de atualizar e reinstalar o ACBR como administrador. Em Homologação a mensagem retornar é por causa da razão social que está sem traço no XML: Rejeicao: CT-e emitido em ambiente de homologacao com Razao Social do remetente diferente de CT-E EMITIDO EM AMBIENTE DE HOMOLOGACAO - SEM VALOR FISCAL Em produção não retorna nada... somente a exceção sem mensagem de retorno do motivo. Voltei para a versão 3.00 e funcionou em produção normalmente.

Bom dia Jeanny, Concordo com você. O Tratamento de gravação e leitura do qrcode deve ser o mesmo usado nos outros campos em que ocorre a utilização de caracteres especiais. Bom dia Juliano, Não sugiro omitir o qrCode e sim usar a solução ParseTextXML sugerida até que passe pelo crivo do ACBr. Para isto muda para true o parâmetro como sugerido pela Jeanny. O default do ParseTextXML da procedure wCampo é true e quando não informada e portanto nos outros campos gerados onde ela é omitida não tem este problema.

Sugiro que vocês atualizem o ACBR conforme a recomendação do Sr. Italo. Segue em anexo a imagem do XML gerado por um sistema "não ACBr" que motivou as alterações bem como a imagem do schema onde indica a utilização do & no lugar do CDATA.

Boa tarde Juliano, Acabei de re-atualizar o ACBr, baixei usando o TortoiseSVN em uma pasta limpa, instalei utilizando o executável do instalador como administrador, abri o projeto, fiz um build, compilei, e fiz um CTe em homologação utilizando os schemas que vem junto do ACBr na pasta C:\ACBr\Exemplos\ACBrDFe\Schemas e deu tudo certo e até já coloquei em produção. Quanto ao CDATA o schema do CTe não prevê o uso por isto um cliente foi irredutível quanto a remoção dele. Quanto ao & ele não pode estar "sozinho" dentro do XML porque ele atrapalha a estrutura, então ele dever ser acompanhado dos outros caracteres ficando & como na imagem do schema do post anterior. Se remover a parte anterior "![CDATA[ " e posterior "]]" e deixando apenas & então tentar abrir com um navegador o XML ele fica errado. Caso neste mesmo arquivo você além de eliminar o "involucro" do CDATA alterar o "&" para "&" como indicado no schema o navegador vai abrir corretamente e se olhar na linha os caracteres "que foram a mais" são automaticamente ocultados porque a leitura deles "explica" que o & comercial deve ser apenas mostrado pelo navegador e não "interpretado" pelo programa que está lendo o XML. Ficou meio complicado a explicação mas esta funcionando desde uma semana antes do primeiro post. Lembrando que o & é usando sempre que precisar mostrar o caracter & como no nome do emitente, remetente, destinatário e etc.

Bom Tarde Italo, Eu que agradeço! (Já estou atualizando eles.)

Italo, Segue em anexo os arquivos que modifiquei. ACBrCTe.pas linha 329. pcteCTeW.pas linhas 270, 271 e 272. No ACBrCTe.pas mais adiante no Passo 2 tem &sign que pelo esquema pode ir &sign, mas não mexi. ACBrCTe.pas pcteCTeW.pas

Bom dia Italo, Já esta rodando em produção desde semana passada e até agora zero problemas. Dentro do schema da receita já tem previsto por isto acho que não está dando problemas.

Olá, Uma empresa está exigido que a estrutura CDATA que fica dentro do qrCodCTe seja removida porque o sistema dela não interpreta este campo e trata ele como erro e impede a leitura. Ela está exigindo de todas as transportadoras e mesmo eu explicando o motivo do CDATA eles estão irredutíveis. Para poder atender alterei o arquivo pcteCTeW.pas removendo os caracteres que formavam o CDATA dentro do Gerador.wGrupo('infCTeSupl') e dentro do ACBrCTe.pas onde era criado o link eu alterei o '&tpAmb=' para '&tpAmb=' utilizando assim o escape & no lugar do &, seguindo um CTe de exemplo que me passaram. Enviei em homologação e está tudo certo sem erro no XML como esta empresa solicitou. A minha pergunta é se há algum problema em fazer estas alterações? Existe alguma norma técnica que impeça este tipo de alteração?

Alguém conseguiu gerar esta guia da UF favorecida PR quando o transportador não está inscrito lá?

Olá... Acabei de ter este problema... A solução que achei foi entrando em Project -> Options -> Application -> Manifest -> DPI Awareness = Unaware

Eu fiz assim... e tá passando com emissor em SP: if cbContingencia.Checked = True then begin if (AnsiMatchStr(ufFiscal, ['RS', 'MS', 'MT', 'SP', 'AP', 'PE', 'RR'])) then begin ACBrCTe1.Configuracoes.Geral.FormaEmissao := teSVCRS; Ide.tpEmis := teSVCRS; end else begin ACBrCTe1.Configuracoes.Geral.FormaEmissao := teSVCSP; Ide.tpEmis := teSVCSP; end; end; Olhei no site de SP e no nacional e os CTes estão lá. E na chave do CTe onde ia 1 de normal está indo 7.

Eu não sugeri aos clientes enviarem sem porque pode ser que os tomadores tenham problema na hora de se creditar do ICMS.

Liguei no 0800... mandaram abrir chamado que para eles tá tudo ok. https://portal.fazenda.sp.gov.br/Paginas/Correio-Eletronico.aspx

As transportadoras do SP que atendo, estão apresentando este problema emitindo para qualquer UF destino dá erro de IE não vinculada. Já as transportadoras que estão no RS estão emitindo normalmente.

Tudo funcionando! Atualizei os fontes, fiz os ajustes no programa, coloquei em homologação, testei todas as operações e tudo funcionou corretamente. Obrigado.

Bom dia, O método GerarPagamentosAdicPagamento não esta correto. Fiz desta forma porque não conseguia alimentar o componente da maneira correta. Vou atualizar os fontes e testar. Obrigado.

Olá, Também tive este problema e após muitos chamados e e-mails com imagens para o suporte do e-Frete consegui resolver. O pessoal do e-Frete chegou a me retornar imagens(desenharam) para explicar o problema e ai consegui compreender que o erro era no prefixo do namespace que somente no envio da viagem de agregado é "obj" e não "adic". Isto acontece em duas tags: UnidadeDeMedidaDaMercadoria e TipoDeCalculo. Então no arquivo pcnCIOTW_eFrete.pas eu modifiquei as seguintes linhas na procedure TCIOTW_eFrete.GerarViagemAdicViagem: Gerador.Prefixo := 'obj:'; Gerador.wCampoNFSe(tcStr, 'AP46', 'UnidadeDeMedidaDaMercadoria ', 01, 01, 1, TpUnMedMercToStr(UnidadeDeMedidaDaMercadoria)); Gerador.wCampoNFSe(tcStr, 'AP47', 'TipoDeCalculo ', 01, 01, 1, TpVgTipoCalculoToStr(TipoDeCalculo)); Gerador.Prefixo := 'adic:'; Gerador.wCampoNFSe(tcDe4, 'AP48',..... etc.... etc... É só nesta procedure. Não mexi nas outras quanto a este dois campos. Coloquei o arquivo em anexo. Também fiz uma alteração grotesca em TCIOTW_eFrete.GerarPagamentosAdicPagamento para conseguir coloca em produção porque não tinha jeito de alimentar os pagamentos. Grato. pcnCIOTW_eFrete.pas

A resposta para a pergunta sobre precisar do PEF eu achei dentro do esquema do xml que diz para informar os zeros caso não utilize PEF. Lembrando que não somos obrigados a usar PEF porque temos a obrigação de pagar com depósito bancário e usar o PEF como "opção" de pagamento. <xs:element name="CNPJIPEF" type="TCnpjOpc"> <xs:annotation> <xs:documentation>Número do CNPJ da Instituição de Pagamento Eletrônico do Frete</xs:documentation> <xs:documentation>Informar os zeros não significativos.</xs:documentation> </xs:annotation> </xs:element>

Que eu entendi não há como visualizar. Mas através da hash gravada lá, obriga você ter a imagem original gravada contigo, pois, somente com esta imagem você pode gerar de novo a mesma hash.

Na minha opinião a receita esta obrigando as transportadoras a terem um documento digital da entrega. Ou seja se a transportadora enviou uma hash com base na chave cte mais uma imagem convertida em base64 é porque a transportadora tem com ela uma imagem guardada. Se a transportadora enviar esta imagem para o interessado e o interessado fizer o procedimento com a chave do cte e imagem utilizando SHA1 o resultado deve ser a hash que a transportadora registrou no sefaz. Então é uma forma da transportadora não "mentir" que entregou. Uma jogada interessante do Sefaz onde não tem controle do conteúdo mas dá ao interessado da entrega a possibilidade de exigir o documento digitalizado. Onde, como, que tamanho, qual o formato e por quanto tempo a transportadora deve manter esta imagem é que vai ser o problema. Imagino o lobby que correu por trás para tomarem esta decisão porque as empresas terão gastos. Ou seja no desenvolvimento de aplicativos de celular, ou seja com um funcionário digitalizando e principalmente o gasto no local onde será guardada a imagem que pode ser no computador/servidor do cliente ou na nuvem. No sistema que ajudo a desenvolver foi feito da seguinte forma: Se o cliente informar o caminho da imagem jpg o sistema pega a imagem e codifica em base 64, depois pega a chave do cte e soma ao texto base 64 da imagem e aplica SHA1 para gerar a hash de 28 dígitos conforme o manual. Se o cliente não informar o caminho da imagem o sistema gera a hash através somente da chave cte e aplica SHA1 que também gera os 28 dígitos. Mesmo não estando em acordo com o que a receita sugere no manual. Então informei aos clientes sobre tudo isto... resultado... ninguém esta fazendo. Somente vão fazer se a receita exigir ou se o tomador exigir.

Realmente, no site da receita tem novos esquemas com as alterações que o Sr. Italo teve que fazer na data de hoje bem quando abre a produção.

Pelo que li do seu XML, você esta com a versão desatualizada, ou dos fontes, ou dos schemas, ou dos dois. Digo isto porque na descrição do evento falta a palavra Eletronico que pode ser com ou sem acento conforme os novos esquemas da receita. O Sr. Italo fez estas alterações e eu usei os fontes totalmente atualizados com os esquemas da pasta de exemplos. Atualizada tudo com o svn, coloca os esquemas novos onde tem um arquivo chamado evCECTe_v3.00.xsd que possuí as regras de validação.

1101814319071340995500014957000000060202100060202310-procEventoCTe.xml 1101804319071340995500014957000000060202100060202310-procEventoCTe.xml Fiz 10 testes de envio e cancelamento em homologação.