Gabriel Bonzanini

Olá pessoal. Estou tendo problemas em um dos testes para certificação TEF: Questão: Como posso fazer para identificar o tipo de via que está sendo impresso no evento OnComandaECFImprimeVia? Pela descrição do teste isto será necessário, visto que o gerenciador de pagamento irá retornar 3 vias (de tipos distintos) e devo tratar para que apenas 2 destes 3 tipos sejam impressos. Os parâmetros do evento não parecem conter tal informação: TACBrTEFDComandaECFImprimeVia = procedure(TipoRelatorio : TACBrTEFDTipoRelatorio; Via : Integer; ImagemComprovante : TStringList; var RetornoECF : Integer ) of object ; Obs: Sei que já existem outros tópicos que abordam esta questão dos comprovantes, porém estou há algum tempo procurando e não achei nada específico a respeito. Qualquer ajuda será bem vinda. Agradeço desde já.

Boa tarde. Segue dois pequenos ajustes que fiz no exemplo do componente ACBrTEFD: Substituição da diretiva {$END} por {$ENDIF} (utilizo Delphi 2010, e não estava compilando; verificar se as duas são equivalentes em versões anteriores do Delphi, onde possivelmente tenha sido criado o exemplo); Controle da visibilidade do painel de pagamentos, mostrando o mesmo apenas na aba referente à venda (a primeira aba é apenas para configurações). Abraço, Gabriel. Unit1.dfm Unit1.pas

Bom dia pessoal! @Juliomar Marchetti, vocês acham que seria possível publicar esta propriedade, para que o objeto FCTeRetornoOS possa ser acessado externamente? Acredito que seja útil, pois todos os dados da aprovação estão contidos nele. Abraço.

Muito obrigado @Italo Jurisato Junior! Eu realmente não havia implementado nada utilizando este método "ImprimirEvento", nem tinha me atentado para sua existência. Realmente, concordo contigo que este seja o caminho mais correto. Vou instruir os usuários à adotá-lo como padrão.

@Claudemir F. Laureano, volta e meia tenho este problema também. Ele acontece esporadicamente, desde que comecei a trabalhar com documentos eletrônicos. Acredito que seja algo que fuja do controle do componente, por ser um retorno do webservice. Ou seja, o problema pode estar "do outro lado". O que eu considero péssimo é a falta de detalhes da mensagem, por exemplo: Qual identificador? Qual o estado correto para ele? Qual o estado atual, que é considerado incorreto? Qual a operação? Com estas respostas, teríamos mais condições de tratar o problema... Eu tenho instruído os clientes a tentar enviar novamente, pois geralmente é algo momentâneo e na tentativa seguinte funciona.

Boa noite Ítalo. Primeiramente, obrigado pela atenção. Acredito que realmente isto não exista... Mas é que, como no report está sendo testado o cStat do xml, imaginei que o componente devesse trabalhar da mesma forma. Pois é, até reparei nesta propriedade, mas a questão é que, assim como outros sistemas, o nosso ERP permite a impressão de CT-e's em lote. Caso eu assinale esta propriedade como True, todos os CTe's impressos aparecem com a tarja. Não seria o caso de remover esta propriedade do componente, sendo que o xml alterado aparentemente fica inválido juridicamente após a alteração? Em nosso sistema, deixamos ela ativa. Se tiver algo que eu possa fazer ou ajudar a desenvolver para melhorar este processo, estou à disposição. Abraço, Gabriel.

Boa tarde pessoal. Gostaria de saber se há alguma forma de configurar o componente para que o campo 'cstat' dentro do xml seja alterado de 100 (autorizado) para 101 (cancelado). O componente da NF-e possui a seguinte propriedade: ACBrNFe.Configuracoes.Geral.AtualizarXMLCancelado := True; Existe algo semelhante para o componente ACBrCTe? Desde já agradeço a atenção. Gabriel.

Às vezes acontece também da solicitação ser rejeitada devido à transportadora não estar cadastrada no DAER e sim na METROPLAN. A falta de informação por parte do SEFAZ é algo terrível, tudo tem que ser testado na prática, na tentativa e erro. Bom, se nem a contabilidade de nossos clientes sabia desse procedimento para habilitar o emissor, imagina nós, desenvolvedores. No fim, sempre sobra pra gente pois, para o usuário, o "erro" ocorre dentro do sistema de gestão. A demanda por este emissor está crescendo, então quaisquer novos problemas e soluções que eu obter compartilho aqui com vocês. Abraço.

Bom dia Thobias! Vou deixar aqui o passo a passo para habilitar um CNPJ para a emissão de CT-e OS: Acesse http://www.cte.fazenda.gov.br/portal/ No lado direito da página, existe um campo para acesso aos portais estaduais. Selecione o estado desejado No meu caso, o estado é Rio Grande do Sul, para o qual é aberta a página https://www.sefaz.rs.gov.br/Site/MontaMenu.aspx?MenuAlias=m_cte Clique no menu 'Solicitação de Credenciamento Voluntário', conforme a imagem (acredito que os portais de outros estados sejam semelhantes): Faça o login por certificado digital (dependendo do navegador, pode não funcionar; aconselho utilizar o Google Chrome) Clique nos três pontos para localizar o documento do cliente, conforme imagem, e depois clique em 'Avançar': A solicitação irá passar por uma avaliação, e isto pode levar algumas horas. No mesmo portal estadual, existe a opção de consulta de credenciamento voluntário, que irá mostrar se a solicitação foi deferida (aceita) ou não. Espero ter ajudado.

Fico feliz em poder ajudar. É o mínimo que posso fazer, o projeto de vocês é fantástico e economiza muito tempo de programação. Abraço!

Boa noite pessoal. @sergiom, acredito que seja mais interessante testar a versão do MDF-e no momento em que o campo do dataset criado em tempo de execução é alimentado, e preenchê-lo conforme a tag correspondente: * Versão 3.0: rodo.infANTT.RNTRC * Versões anteriores: rodo.RNTRC Esta alteração resolveu a questão pra mim. Segue em anexo a unit, caso queiram utilizar. Abraço. ACBrMDFeDAMDFEFR.pas

Bom dia Italo! Pelo que entendi, o colega @dionatan pediu um xml qualquer que estivesse aprovado... Só postei pra que ele pudesse analisar um exemplo de formato aceito pelo sefaz. Acredito que esta questão do grupo de cobrança/faturas esteja sendo analisada em um outro tópico.

Segue em anexo. Ainda não estou conseguindo enviar as faturas, pois dá 'Falha no schema xml'. Acredito que esta questão esteja pendente de ajuste lá no webservice mesmo. 43170902080759000157670020000000241042586830-cte.xml

Boa tarde pessoal. A quem possa interessar, para sanar o problema de forma temporária, adicionei a propriedade 'CTeRetornoOS' para acesso externo: Após o envio do lote, para acessar os dados do retorno, basta acessar as propriedades ACBrCTe.WebServices.Enviar.CTeRetornoOS.* . Não sei se era a intenção inicial dos programadores do projeto, mas por enquanto pode "quebrar um galho" pra quem tenha urgência. Abraço. ACBrCTeWebServices.pas

Bom dia Italo! Muito obrigado pelo retorno, sei como é a correria de vocês e como o tempo é escasso. Na verdade, reparei que existe, internamente, o objeto FCTeRetornoOS, porém o mesmo não foi publicado para acesso externo.

Bom dia Cleonir. Caso queira testar em homologação, acredito que o SEFAZ tenha removido esta validação.

Bom dia pessoal, tudo bem? Estou tendo problemas ao tratar o retorno da receita para a aprovação do CTe-OS (modelo 67). Questão: em qual propriedade do componente podemos encontrar os dados do retorno, após o envio? O xml de retorno da receita é o seguinte: <?xml version="1.0" encoding="UTF-8" ?> - <retCTeOS xmlns="http://www.portalfiscal.inf.br/cte" versao="3.00"> <tpAmb>2</tpAmb> <cUF>43</cUF> <verAplic>RS20170524123027</verAplic> <cStat>104</cStat> <xMotivo>Lote processado</xMotivo> - <protCTe versao="3.00" xmlns="http://www.portalfiscal.inf.br/cte"> - <infProt Id="CTe143170000069206"> <tpAmb>2</tpAmb> <verAplic>RS20170829094659</verAplic> <chCTe>43100002080759000157070020000000221040004850</chCTe> <dhRecbto>2017-09-22T09:03:22-03:00</dhRecbto> <nProt>143170000669200</nProt> <digVal>SCqHYRKjbBPT3F99/Wr3ZP0AFRk=</digVal> <cStat>100</cStat> <xMotivo>Autorizado o uso do CT-e</xMotivo> </infProt> </protCTe> </retCTeOS> Pelo que reparei, após a aprovação, as propriedades do componente ficam todas em branco ou zeradas, como ACBrCTe.WebServices.Retorno.* e ACBrCTe.WebServices.Retorno.CTeRetorno.* Desde já agradeço a ajuda dos colegas, Gabriel.

Bom dia pessoal. A princípio, havia deduzido que a verificação estivesse baseada no "Número do Registro Estadual" (Tag <NroRegEstadual>), de 25 dígitos, já que nenhum dos clientes/contabilistas fazia ideia do que deveria ser informado neste campo. Porém, ontem fiz mais alguns testes e os CTe's foram aprovados normalmente. Pelo que percebi, esta validação acaba de ser removida do webservice de homologação.

Perfeito BigWings, muito obrigado.

Também estou passando pelo mesmo problema. Parece que o componente está ignorando os valores preenchidos na tag Ide.toma4 para o modelo 67.

Olá Luís. De uma forma simples, o que você pode fazer é abrir os dois manuais em PDF, lado a lado, deixá-los na mesma posição (detalhes do layout dos campos: 2.0, pág. 119; 3.0. pág. 153) e ir navegando. Dá pra ver claramente o que foi alterado, e como a colega Gr@c@ comentou não é muita coisa. http://www.cte.fazenda.gov.br/portal/listaConteudo.aspx?tipoConteudo=YIi+H8VETH0= O componente do ACBr ainda irá conter as propriedades referentes à tags descontinuadas, apenas para compatibilidade com a versão 2.0, não sendo necessário preenchê-las pois as mesmas serão ignoradas caso o componente esteja configurado para utilizar a versão 3.0.

Obrigado pela atenção pessoal. Daniel, qual opção devo utilizar para que o componente se comporte da forma "tradicional"? libCapicomDelphiSoap? Abraço!

Acredito que tenha sido alguma outra propriedade modificada ao mesmo tempo, pois estes erros estão acontecendo na assinatura do arquivo, antes mesmo do envio para o webservice...

Deixando de lado a questão de definir o valor da propriedade de forma explícita ou não, alguém sabe dizer quais os pré-requisitos para utilizar cada um dos métodos de comunicação com os certificados digitais? Já tentei todas as opções: libOpenSSL, libCapicom, libCapicomDelphiSoap e libWinCrypt. A opção 'libCapicom' não deveria ser a "tradicional", que sempre funcionou? Obrigado pela atenção.

Estou tendo o mesmo problema... Tentei reinstalar o certificado digital, removê-lo e plugá-lo novamente e reiniciar o computador, mas o erro persiste... Passou a ocorrer depois da última atualização dos componentes.