Agnaldo Prates

Uma pergunta, quando você configura o componente em sua aplicação, está definido o path do arquivo de cidades? ex: ACBrNFS1.Configuracoes.Geral.PathIniCidades := Informar o path do arquivo Cidades.ini; ACBrNFS1.Configuracoes.Geral.PathIniProvedor := Informar o path do arquivo do seu provedor Pode ser isso ai.

Você está usando o schema que tem no exemplo do componente? Acbr\Exemplos\ACBrDFe\Schemas\NFe\ Certifique que são os mesmos.

Não está mesmo. Atualizei agora mesmo! Pode ser algo temporário na hora que você testou. Aparentemente está normal.

Só uma observação que não citei no tópico anterior. Envio da seguinte forma: ACBrNFSe1.Enviar(fNota);

Exatamente!

Com certeza vai funcionar sim. Eu faço assim a anos e ainda não tive problemas. Quanto ao protocolo, que você frisou no tópico anterior, em relação ao protocolo eu faço da seguinte forma: ACBrNFEe1.NotasFiscais.Clear; ACBrNFEe1.WebServices.Consulta.NFeChave := fChave; ACBrNFEe1.WebServices.Consulta.Executar; if ACBrNFe1.WebServices.Consulta.Protocolo <> '' then begin Aqui eu salvo o protocolo no meu sistema. End; Utilizo dessa forma antes de enviar, se a nota ja existe mas não há protocolo, o mesmo simplesmente é atualizado, não ocorrendo erro de duplicidade. O detalhe é que analiso antes se não há protocolo no meu banco.

Boa tarde. Não foi com o Boleto mas, com a NFe houve um caso desses comigo. Depois de analisar todo o meu código descobri que havia uma varável que era alimentada e ao final do processo esta não era zerada o seu valor. Debuguei todo o AcbrBoleto, em especial a Unit referente ao Itau, e não observei nada de anormalidade. É importante que ao gerar o boleto certifique que é exatamente aquele valor se não há uma variável perdida com o 0,01 centavo.

Veja a discussão neste tópico. http://www.projetoacbr.com.br/forum/topic/7534-c%C3%B3digo-que-comp%C3%B5e-a-chave-de-acesso-nfe/

Já sim. Isso ocorre porque as Notas Fiscais Eletrônicas são enviadas para o Ambiente Nacional através de agendamento. Teve um cliente que bateu o pé que a NFe não valia por não estava no ambiente nacional, mesmo o DANFE impresso pela SEFAZ/RS, mas no outro dia a NFe já estava na base da RFB.

Boa tarde. Erro: Falha na validação dos dados do lote: 1. '' violates length constraint of '11'. The element '{http://www.abrasf.org.br/nfse.xsd}Cpf' with value '' failed to parse. Causa: Falta infomar os dados referente ao emitente. Solução: Adicionar os dados do emitente conforme abaixo. ACBrNFSe1.Configuracoes.Geral.Emitente do begin CNPJ := Cnpj do Emitente; InscMun := Inscrição Municipal; RazSocial := Razão Social; End; Boa tarde. Italo, depois que atualizei o ACBr, percebi que o erro está de fato ocorrendo. Diante disso, fui analisar o que realmente estava acontecendo. No debug, pode observar que o método assinar é chamado mais de uma vez, ,mesmo o xml já assinado, então fiz o seguinte: Erro: A string literal was expected, but no opening quote character was found Causa: Este erro ocorre porque, ao solicitar o envio da NFSe, o XML é assiando duas vezes. Solução: Para que o XML não seja novamente assinado, procedi uma mudança na unit ACBrNFSeWebServices.pas. Adicionei a seguinte condição a partir da linha 1524: if FNotasFiscais.Items[0].NFSe.signature.DigestValue='' then begin FPDadosMsg := FNotasFiscais.AssinarLote(FPDadosMsg, FPrefixo3 + TagGrupo, FPrefixo3 + TagElemento, FPConfiguracoesNFSe.Geral.ConfigAssinar.Lote, xSignatureNode, xDSIGNSLote, xIdSignature); // Incluido a linha abaixo por após realizar a assinatura esta gerando o // atributo xmlns vazio. FPDadosMsg := StringReplace(FPDadosMsg, 'xmlns=""', '', [rfReplaceAll]); end; Com isso, o XML já assinado não chama novamente o método FNotasFiscais.AssinarLote; Não posso afirmar que seja a solução, todavia aqui ficou resolvido. Estou enviando em anexo a unit devidamente modificada para análise. ACBrNFSeWebServices.pas

Seus Schemas estão desatualizados. Dentro da pasta do ACBr estão atualizados. Acbr\Exemplos\ACBrDFe\Schemas\ tente atualizar por estes que dá certo.

Correto. Eu entendi a sua necessidade. Antes porem, deve ser observado o que preceitua as normas técnicas para definição do DANFE, não adianta o cliente querer alterar o layout se há regras a serem seguidas. Mais informações no Manual Integração do Contribuinte, em especial o anexo II do respectivo manual. Por isso, devemos observar se tal adequação não irá de encontro com as normas específicas do DANFE.

Para você solucionar este problema, poderá fazer o seguinte: Não sei se o pessoal do ACBr vai mudar, mas, para que a impressora padrão não seja mudada, proceda da seguinte forma: Abra o arquivo RLPrintDialog.pas que deve estar dentro da pasta FortesCE, e, a partir da linha 734, comente as seguintes linhas: lh 734 // if RLPrinter.PrinterNames = RLPrinter.PrinterName then lh 735 // J := I; Pronto. Recompile e vai dar tudo certo. Oportuno salientar que, toda vez que atualizar o FortesCE esta alteração deve ser feita.

É isso mesmo. No na Impressão do Danfe em FortesCE, a impressora escolhida fica setada no sistema como padrão, todavia, quando finaliza a aplicação, a impressora padrão volta ao normal. Ao que parece, tem a ver com o FortesCE, ainda não testei no FortesReport. No FastReport o mesmo não ocorre.

Isso significa que o "componente" está setando a TM-20 como padrão? Eu não tenho esta situação, pois, onde emito a NF, não tem outra impressora. Vou fazer este teste.

Quem agrade sou eu amigão.

É no mínimo estranho. Aqui comigo está tudo dentro da normalidade. Notei que este XML postado está faltando muita coisa, inclusive a tag infNFeSupl. Mas, esse erro começou exatamente a partir de quando? Depois de uma atualização ou outra mudança? Acabei de enviar uma NFce com identificação, assinou, transmitiu sem problemas. Sugiro a você, analisar os fontes do ACBr, se estão mesmo sendo chamados os fontes do Trunk2. Tambem, analise se no seu HD não existe nenhum fonte relativo ao ACBr Trunk.

Não há de que!

Boa tarde. Não posso afirmar mas, a Friorilli está mudando alguns endereços, por exemplo, aqui em jaru foi modificado de http://201.45.58.229:5660/IssWeb-ejb/IssWebWS/IssWebWS?wsdl para http://201.16.129.176:5660/IssWeb-ejb/IssWebWS/IssWebWS?wsdl Portanto @Italo Jurisato Junior, estou enviando o arquivo Fiorilli.INI com a devida correção. Fiorilli.INI

Posta o XML para que possamos avaliar.

Denis, dê uma olhada no path, o delphi está identificando algum arquivo perdido no seu hd, portanto, verifique o path library.

Você está diante de uma suite open source. Se você separar as pastas e enviar somente o que vai utilizar, ainda assim, na hora de compilar com certeza o outro desenvolvedor terá que instalar o componente, pense numa trabalheira como citou o @Juliomar Marchetti. Seria tão difícil assim para ele instalar o ACBr ainda mais com o instalador dispoível?

Minas Gerais é um caso à parte. O cancelamento de NFe em MG pode ser feito dentro de 24:00hs, isso quer dizer que, decorrido este prazo, você deverá proceder o cancelamento extemporâneo. “Nos termos da Cláusula décima segunda do Ajuste SINIEF 07/05, o prazo legal de cancelamento é de 24hs contado a partir do momento da autorização da respectiva NF-e” Segundo o que dispõe o manual de cancelamento em alguns casos excepcionais, poderá ser permitido o cancelamento fora do prazo, em outras palavras, a regra é que, o cancelamento deve se dar dentro de vinte e quatro horas. Fonte: http://portalnfe.fazenda.mg.gov.br. Dispoível em: <http://portalnfe.fazenda.mg.gov.br/downloads/Manual_Cancelamento_Extemporaneo_NFe.pdf> acesso em 03 fev 2016.

Esse tópico a meu ver está em local indevido, creio que deveria estar em ACBrNFE. Agora, quanto ao conteúdo, havendo mais de uma parcela, como seria o comportamento?

Pode ter alguma relação sim. Veja no tópico abaixo que trata desse assunto, pode ser que há algo que lhe ajude. http://www.projetoacbr.com.br/forum/topic/6740-nao-ha-suporte-para-criptografia-24-resolvido/