sesistemas

Este problema que o Wislei citou está ocorrendo comigo também. Quando emitimos um CT-e em FSDA e o transmitimos no mesmo dia, tudo ocorre sem problemas. Mas se tentarmos transmitir o CT-e no dia posterior, é retornado a seguinte mensagem: Rejeicao: Data de entrada em contingencia posterior a data de emissao Alguém sabe me dizer o que pode ser? Segue XML que estou tentando enviar em anexo. Atenciosamente 31131103341645000186570010000033215032478517-cte.xml

Boa tarde Italo. Realizando novos testes eu identifiquei o seguinte. A Rejeicao: Falha no Schema XML especifico para o modal só ocorre se eu tentar emitir o MDF-e em homologação. Se eu mudar para produção o XML é autorizado. Eu entrei em contato com o SEFAZ de MG para saber se há algum problema com o ambiente de homologação. Qualquer resposta ou solução que eu encontrar aqui posto no forum. Seguem os XML de homologação que não foi autorizado e o de produção que foi autorizado. 31131103341645000186580010000011231000000013-mdfe - HOMOLOGACAO.xml 31131103341645000186580010000001231000000019-mdfe - PRODUCAO.xml

Bom dia. Muito obrigado pelas dicas Carloshteles, através das suas dicas eu consegui autorizar a NFC-e no WebService de AM pelo Demo da NF-e. Detalhe: Tive que voltar a hora do meu computador duas horas para ficar igual ao do WebService e corrigir uma rejeição.

Bom dia Italo, Depois que você postou a inclusão desta nova propriedade eu verifiquei ela aqui no meu componente. Estou tentando transmitir utilizando a versão 1.00 primeiramente pois com menos TAGS creio que terei menos problemas...rs A validação do XML pelo componente com os XML Schemas que você me informou ocorre perfeitamente. Porém o WebService que não aceita o meu XML me retornando a Rejeição:Falha no Schema XML especifico para o modal Eu já revirei o XML de cima em baixo conferindo com o manual, e salvo as novas tags da versão 1.00a, está tudo certo. Você tem alguma outra dica que posso verificar aqui? Segue XML gerado. Atenciosamente Wislei 31131003341645000186580010000123681000000010-mdfe.xml

Bom dia Juliomar, Peço desculpas pelo post, pois confesso que minha primeira pesquisa foi meio corrida e não tinha encontrado o post do Ítalo. Muito obrigado pela atenção. Vou começar os testes com o componente. Atenciosamente Wislei.

Bom dia a todos. Segundo publicação do Regys em seu blog: http://www.regys.com.br/sefazam-libera-ambientes-de-testes-de-nfc-e-para-todo-o-pais/ a SEFAZ/AM disponibilizou um Web Service para todo o país testarem suas aplicações. Como está o projeto do ACBrNFCe para este webService? Link do projeto: http://portalnfce.sefaz.am.gov.br/desenvolvedor/ambiente-de-homologacao-para-desenvolvedores/ Atenciosamente.

Boa tarde Italo. Estou testando o MDF-e após esta correção e estou tendo problemas nas informações da tag <veicTracao> Já atualizei os fontes, recompilei o componente e atualizei os XML Schemas. Segue em anexo o erro e o XML que estou gerando. Estou alimentando o componente da seguinte forma: rodo.veicTracao.cInt := '001'; rodo.veicTracao.placa := 'ABC1234'; rodo.veicTracao.tara := 5000; rodo.veicTracao.capKG := 4500; rodo.veicTracao.capM3 := 400; rodo.veicTracao.tpRod := trTruck; rodo.veicTracao.tpCar := tcAberta; rodo.veicTracao.UF := 'MG'; Att, 31131003341645000186580010000123451000000016-mdfe.xml

Creio que o componente deve ser recompilado. Eu ainda não estou testando a versão 2.00

O Italo já explicou em outro tópico:

Bom dia. Acabei de instalar o componente disponibilizado pela Nellien sem muitos problemas. Foi necessário apenas modificar os requisitos do FastRepor para a versão do Delphi XE3 que utilizo ( frx17, fs17, frxe17, frxDB17) Ao imprimir o DAMDFE ocorreu apenas um erro de conversão de string para double e também senti falta das informações do CT-e e NF-e presentes do MDF-e. Mas ainda vou dedicar um tempo para verificar o que é e estudar melhor o manual. Como o objetivo deste meu post não é este, gostaria de agradecer e parabenizar à Nellien pela contribuição! Segue em anexo o documento que gerei ao testar. DAMDFE.pdf

Parabéns pela iniciativa Neilien! Vou fazer os testes aqui.

Realmente Solivan. Bastou apenas atualizar o repositório, dar um 'build' e um 'install' que o componente apareceu em minha paleta de ferramentas! Muito obrigado!

Parabéns pela iniciativa! Gostaria de saber se há algum pacote específico para instalação? Pois só encontrei uma unit na pasta /Fontes/...

Italo, Isto é algo que achei estranho, pois procurei por este arquivo e não o encontrei. Encontrei apenas os arquivos QR5RunDXE3.res, QR5RunDXE3.dcp e QR5RunDXE3.blp os quais já informei o diretório no library path. Será que há algo de errado com a minha instalação do QuickReport ???

Bom dia Italo, O path do Quick Report estava depois dos path do ACBr, mas mesmo mudando para antes dele não funcionou. Estou utilizando a versão 5.05.2. Estou tentando de tudo aqui, se tiver mais alguma dica fico grado.

Boa tarde. Estou tentando instalar o componente ACBrMDFeDAMDFEQR que é responsável pela impressão do DAMDFE e estou tendo o mesmo problema citado acima: [dcc32 Error] E2466 Never-build package '.ACBrMDFeDAMDFEQRpkg' requires always-build package 'QR5RunDXE3' Eu removo o QR5RunDXE3 dos requisitos e o delphi me solicita adicioná-lo novamente. Mas mesmo assim continua dando este erro. Alguém pode me ajudar? Obs: estou utilizando o QuickReport Triall pois utilizo o FastReport e ainda não há o componente para o fast anda.

Este problema costuma acontecer aqui em Minas Gerais quando o WebService está indisponível ou instável.

Bom dia Graça. Inicialmente eu estava tendo o mesmo problema que você. Seguindo as instruções deste post: Eu atualizei os meus XML schemas e comentei as linhas mencionadas. A partir daí até hoje estou conseguindo emitir e consultar o MDF-e em homologação aqui em MG. Segue em anexo o xml gerado. Se de tudo não der, poste o trecho de código ou a unit que você alimenta o componente para analisarmos. 31131003341645000186580010000123631000000014-mdfe.xml

Bom dia. Gostaria de saber se alguém passa por situação semelhante e como é contornada. Possuímos um cliente (Distribuidora que Transporta seus próprios produtos) que está me questionando a necessidade de emitir um único CT-e para vários destinatários. Em um caso específico, ele possui uma única carga com 30 destinatários diferentes. Sendo assim, ele é obrigado a emitir 60 documentos (30 NF-e e 30 CT-e). O seu contador entrou em contato com um Coordenador de Fiscalização da Delegacia Fiscal de Varginha - MG onde ele responde que é possível emitir um único CT-e para estas cargas, seguindo os seguintes procedimentos: Prezados, O Regime Especial continua em vigor, devendo ser observados as normas abaixo para e emissão do CT-e Global. 3.1 Campo Tipo do CT-e <tpCTe> será preenchido com “0” = CT-e Normal. 3.2 Prestação de serviço de transporte de um remetente para vários destinatários: Os campos da secção Remetente serão todos preenchidos com os dados do remetente das mercadorias. · Os campos da secção Destinatário serão preenchidos: · Campo CNPJ <CNPJ> - será preenchido com o número do CNPJ do emitente do CT-e; · Campo Razão Social/Nome <xNome>- Será preenchido com a expressão “DIVERSOS”. · Demais campos dessa secção serão preenchidos com os dados do emitente do CTe. 3.3 Prestação de serviço de transporte de vários remetentes para um destinatário: Os campos da secção Destinatário serão todos preenchidos com os dados do destinatário das mercadorias. · Os campos da secção Remetente serão preenchidos: · Campo CNPJ <CNPJ> - será preenchido com o número do CNPJ do emitente do CT-e; · Campo Razão Social/Nome <xNome> - Será preenchido com a expressão “DIVERSOS”. · Demais campos dessa secção serão preenchidos com os dados do emitente do CTe. 3.4 No campo “Observações Gerais” <xObs> - deverá ser informado a legislação pertinente ou os dados que identificam o regime especial que permite a emissão do respetivo documento. Att. Solano Bicalho Coordenador de Fiscalização Masp 668.964-0 - Tel. (35) 3068-0120 Fax. (35) 3068 0190 - VOIP 9020 Secretaria de Estado de Fazenda de Minas Gerais Delegacia Fiscal de Varginha / Superintendência Regional de Varginha Então fica a dúvida, pois o que sempre li até hoje, seja aqui no forum, em outros foruns e até mesmo pelo que entendi do manual, somente é permitido emitir um único CTé para um único Remetente e Destinatário. Se um deles mudar, será necessário a emissão de um novo documento. E então, é permitido fazer este tipo de documento? Ou neste caso caberia um MDF-e ao invés de um CT-e ? Atenciosamente, Wislei.

Já pensamos algumas vezes em mudar a impressão do DACTE para QuickReport, porém todo o nosso sistema já esta utilizando o FastReport. Sera que algum usuário do forum já não tenha esta modificação para poder disponibilizar pra gente? Eu até tentei realizar esta mudança mas preciso estudar melhor como o componente trabalha.

Bom dia. Após passar a utilizar o ACBrCTe com OpenSSL, não consigo mais Inutilizar a numeração do CT-e. Não obtenho nenhum retorno ou erro ao tentar inutilizar. Estranho é que não houve nenhuma alteração na minha rotina, apenas recompilei o componente e não inutiliza mais. Alguém conseguiu inutilizar com OpenSSL ? Att, Wislei.

Na pasta \ACBr\Projetos\ no repositório existe um projeto para o que eu precisava: ValidadeCertificadoOpenSSL

Bom dia. Depois de muito testar, vi que o problema estava no meu certificado digital no Windows Server. Utilizando o ACBrCTe com OpenSSL, não é necessário eu ter o certificado instalado na máquina, bastando apenas informar o diretório do mesmo e a senha. Muito obrigado pela atenção. Att, Wislei

Bom dia. Alguém conseguiu pegar a data de vencimento do certificado utilizando OpenSSL? Na versão Capicon existe a propriedade ACBrCTe1.Configuracoes.Certificados.DataVenc, porém com OpenSSL não consigo de nenhuma forma. Não consegui capturar a data também com o comando informado pelo Igor através do executável openssl.exe Att, Wislei

Com a propriedade ACBrCTe1.Conhecimentos.Items.CTe.procCTe.cStat você consegue tratar o retorno de cada CT-e separadamente de acordo com a página 71 do manual v. 1.04