Agnaldo Prates

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/

Bom dia. No site da sefaz/mg tem todo um mecanismo para isso. http://www.fazenda.mg.gov.br/empresas/sistemas/siare/CDFA/cancelamento_docs.htm

Você já analisou se o arquivo nfse.xsd e xmldsig-core-schema20020212.xsd são os mesmos do trunk2? Tenho clientes que trabalha com a Fiorilli e não estou tendo estes problemas, pelo menos até agora.

Henrique bom dia. Para notas de crédito de CIAP, não sei como está no seu xml, mas, alguns aspectos devem ser observados. A finalidade deve ser fnAjuste, Ide.finNFe := fnAjuste; A tag, indTot deve ser itNaoSomaTotalNFe, Prod.IndTot := itNaoSomaTotalNFe; Isso deve resolver o seu problema.

Isso mesmo, somente o primeiro link é que estão informando que serão paralisados dos serviços no dia 02/02. Só pra você ver como eles tem um cuidado em divulgar as informações. Isso é coisa do governo.

Graça, eu tenho o RXLib que roda até o XE3. Caso haja interesse lhe envio por pvt.

Veja o comunicado da SEFAZ. https://www.sefaz.rs.gov.br/Site/index.aspx https://www.sefaz.rs.gov.br/Site/NoticiaDetalhes.aspx?NoticiaId=4440

Bom dia. Eu não entendi muito bem a situação. Após finalizar a venda o sistema não transmitiu a nota? Se transmitiu, o cliente jamais poderia excluir um item da venda, haja visto que esta já tornou-se um documento público, Nota fiscal. Se ainda não foi transmitido, e estamos diante de uma pre-venda, não há nenhum problema quanto à exclusão de itens. O agravante neste caso é que, o cliente recebeu do consumidor, e posteriori, apagou os itens, isso caracteriza fraude, podendo este ser autuado pela via administrativa estadual. Penso que você deve analisar a possibilidade de, ao finalizar a venda, se for venda, transmitir a nota fiscal imediatamente, sob pena de poder ser também responsabilizado de forma solidária com seu cliente, ainda que toda a ação foi executada por ele.