Valdir Dill

Boa noite, Acho que você tem razão. A contingência EPEC pode ser acionada pelo próprio emitente. Os SVC (RS e AN) é que precisam de autorização especial de cada SEFAZ. Abraços

Certo, mas uma hora você vai precisar, rs... Lembrando que quem define qual contingência usar não é o software, mas sim a própria SEFAZ, no momento que libera o envio em contingência. Obrigado.

Bom dia, Sim, NFe em contigência EPEC. Obrigado

Bom dia, Também tivemos umas 4 ou 5 situações exatamente como essa relatada no post. Nossa orientação foi para o usuário solicitar algo mais concreto (como um laudo, por exemplo) por parte da certificado e não apenas alegações verbais. Outro argumento que pedimos para nosso cliente utilizar junto à certificadora é "...o certificado de vocês é tão frágil em termos de segurança que o nosso simples sistema gerencial consegue acessar o cartão e destruí-lo? Qual é a segurança que o certificado oferece então?..." Nunca tivemos retorno, rs... Abraços.

Bom dia, Estou abrindo este post, mais com o objetivo de buscar opinião sobre uma questão que estou na dúvida como proceder. Trata-se de NFes enviadas em contingência e que depois devem ser reenviadas mudando a forma para normal. Pelo que analisei nos manuais de integração, o que encontrei foi que a nota enviada em contingência deve ser retransmitida pela opção normal após sanado problema da contingência, mas essa retransmissão deve ser com o mesmo arquivo XML que foi enviado quando da contingência. Ocorre que, como todos sabemos, a conferência do XML pelo WS na contingência é precário, ou seja, confere apenas alguns poucos dados. Nessa conferência, a nota pode ter algum dado incorreto, mas esse erro "passa" na contigência. Porém, no envio normal, o erro não passa e aí acontece a rejeição quando da retransmissão. Como vocês procedem nesses casos? Permitem que o usuário faça alterações nos dados da nota? Mas aí teria que gerar um novo XML e isso não seria contrário às normas? Por outro lado, se não permitir alteração na nota depois de enviado por contigência e ocorrer a rejeição posterior, o usuário não conseguirá retransmitir a nota!!! Agradeço pelas opiniões/sugestões Obrigado!

Bom dia, Funciona sim Agnaldo, basta não atribuir a senha ao componente Acbr na segunda vez que for usá-lo. Mas só acontece com SERASA. Isso é certeza, pois fiz dezenas e dezenas de testes com outros certificados e não ocorre. Com SERASA, fiz dezenas e dezenas de testes e, se atribuir a vez segunda a senha ao componente antes a aplicação ser encerrada, dá o erro ao usar qualquer operação do Acbr que chame o certificado. E nem adianta destruir/recriar o componente Acbr, vai dar erro igual. Acho que o certificado controla isso da aplicação que o chamou e não pelo componente Acbr. Prova disso é que quando não se alimenta a senha no componente, a tela do PIN é chamada uma única vez pelo gerenciador do certificado (isso já vale para qualquer certificado A3). Eu fiz da seguinte forma e e está funcionando 100% em vários clientes que antes (quando eu atribuía a senha na segunda vez) não funcionava: 1) No onCreate do DataModule (que é onde está meu componente): - ACBRNFe1.tag := 0; //atribuo 0 só para garantir, pois 0 já é o default. Obs.: a) O DM é criado somente uma vez durante toda aplicação; Não, não adianta criar o DM dinamicamente e destruí-lo depois. Como mencionei acima, o certificado faz algum tipo de controle pela aplicação que o chama. 2) Ao iniciar qualquer procedimento do Acbr que necessitará do certificado: a) if ACBRNFe1.tag = 10 then exit; try b) ACBRNFe1.SSL.Senha := TBDadosCertif.FieldByName('SenhaCert').asString; c) Configuracoes.Geral.SSLLib := libWinCrypt; n) ...; y) ACBRNFe1.SSL.CarregarCertificado; z) ACBRNFe1.tag := 10; except ACBRNFe1.tag := 0; end; Funciona perfeito. Mas, se o item 2 b for executado uma segunda vez pela aplicação, e se tentar assinar um XML, por exemplo, vai dar o erro se o certificado vinculado for A3 SERASA. Abraços.

Boa tarde, Bem, em primeiro lugar é preciso salientar que o problema só ocorre com certificados A3 SERASA. Pelo menos comigo foi assim. 1 - AcbreNFe1.Configuracoes.Geral.SSLLiB = Wincrypt 2 - AcbreNFe1.SSL.Senha := '123456' 3 - Enviar uma nota 4 - Sem sair do sistema, repetir passos 2 e 3. Ao tentar enviar a segunda nota, dá o erro. Observações: 1 - Se não informar a senha para o componente nenhuma vez (passo 2), aí quando vai enviar a nota, será aberta a tela do PIN (só pede a primeira vez), informa-se a senha normalmente e o erro não ocorre; 2 - No passo 2 acima, se mudar para "if AcbreNFe1.SSL.Senha <> emptyStr then AcbreNFe1.SSL.Senha := '123456'", aí o erro não ocorre, ou seja, se não atribuir a senha uma segunda vez ao componente, aí o erro também não ocorre. Obrigado

Bom dia, Sim, agora com a mudança de url (atualização 13903) está funcionando beleza, mesmo com acentuação/espaços. Provavelmente que a URL antiga é que não aceitava no formato "Lucas%20do%20Rio%20Verde". Mas agora está beleza. Obrigado.

Bom dia, Pelo código está funcionando. O que não funciona é pelo nome da cidade quando o nome tem espaço(s) e/ou acentuação. A linha Param := AjustaParam( ACidade ) da function TACBrIBGE.BuscarPorNome(const ACidade : String ; ... está formatando assim: Espaços: cidade: Lucas do Rio Verde: formatação do ACBR: Lucas%20do%20Rio%20Verde. O correto seria Lucas+do+Rio+Verde. Pelo menos é assim que gera lá na url do site do IBGE, quando se consulta direto. Acentuação: cidade: Divinópolis: formatação do ACBR: Divin%F3polis. O correto (para funcionar) seria Divinopolis. No caso da acentuação, um simples TiraAcentos() já resolve. Mas no caso dos acentos...não sei ainda como fazer. Obrigado!

Bom dia, Não sei se entendi direito, mas nesse caso não seria dispensável a variável? Colocando apenas if ACBrNF.SSL.Senha= '' then begin ... end; ao invés de U_Acesso_Term.VSENHADIGITADACERT = '' then begin ...end;? Obrigado!

Bom dia, Também estou tendo exatamente esses mesmos problemas, ou seja, no segundo envio de nota, dá erro. E apenas com A3. A solução (temporária) foi não informar a senha no componente (AcbrNFe.SSL.Senha := ''). Dessa forma o gerenciador do certificado é que pede a senha quando necessitar e o erro não acontece. Obrigado!

Bom dia, Na ACBrDANFCeFortesFr.pas eu não encontrei isso que você menciona Daniel. Aliás, na ACBrDANFCeFortesFr.pas, em nenhum local e encontrei rotina que verifique se ImprimirTributos é false ou true. Veja bem, nessa mudança que eu propus, apenas o lTitLei12741 (que é um TrlLabel) é que vai ficar invisível e não a banda toda. Obrigado.

Boa noite, As alterações feitas até agora têm efeito apenas para danfe com ACBrNFeDANFeESCPOS. Pelo que entendi e nos testes que fiz, a impressão da NFCe com Fortes Report está imprimindo os tributos igual, mesmo que .imprimirTributos = false. Então, creio que é preciso fazer as alterações abaixo na ACBrDANFCeFortesFr.pas, a qual já envio anexo com as alterações. Peço que seja incluído no código oficial . procedure TACBrNFeDANFCeFortesFr.rlbRodapeBeforePrint(Sender: TObject; var PrintIt: Boolean); var i:integer; begin with ACBrNFeDANFCeFortes.FpNFe do begin if (ACBrNFeDANFCeFortes.ImprimirTributos) and //alteração proposta (Total.ICMSTot.vTotTrib > 0) then lTitLei12741.Caption := lTitLei12741.Caption +' '+ FormatFloatBr(Total.ICMSTot.vTotTrib) else lTitLei12741.Visible := False; for I := 0 to InfAdic.obsCont.Count - 1 do begin lObservacoes.Lines.Add( StringReplace( InfAdic.obsCont.xCampo + ': ' + InfAdic.obsCont.xTexto, ';', #13, [rfReplaceAll] ) ) ; end; if InfAdic.infCpl <> '' then lObservacoes.Lines.Add( StringReplace( InfAdic.infCpl, ';', #13, [rfReplaceAll] ) ); lObservacoes.Visible := ( lObservacoes.Lines.Count > 0 ); end; end; Obrigado. ACBrDANFCeFortesFr.pas

Bom dia, Temos um sistema sem TEF e gostaríamos de implementar essa opção e precisamos de um parceiro freelancer para desenvolvimento inicial até homologação. Obs.: estamos analisando proposta de integração da skyTef. Interessados contatem por e-mail [email protected]. Obrigado

Bom dia Daniel, Que bom que resolveu... Será melhor ainda para o grupo se você compartilhar a solução!!! Obrigado!

Testado e funcionando. Muito bom. Obrigado!

Boa noite, Não vi no manual, mas num boleto (anexo) impresso por um cliente através do sistema do banco. Não sei dizer se isso afetaria outros bancos. Acredito que sim, pois as cooperativas também têm esse campo da modalidade. Obrigado.

Bom dia, Gostaria de fazer uma sugestão para que, na impressão de boletos de carteiras do BB, com variação (ex. 17/27), seja impressa a variação no boleto Fortes Report. Explico a sugestão: Os convênios do Banco Brasil têm sempre o código da carteira e a variação (ex.: carteira 17, variação 27). Na alimentação do título, eu coloco: ACBrBoleto1.CriarTituloNaLista.Carteira := '17'; ACBrBoleto1.Cedente.Modalidade := '27'; Ocorre que, no campo da carteira no boleto impresso, o Acbr só imprime "17", enquanto que no boleto impresso no sistema do próprio banco, esse campo imprime "17/27", que é o correto e exigido pelo banco. Minha sugestão é para incluir as linhas 654 e 800 na ACBrBoletoFCFortesFr.pas (anexo). Aí a impressão ficaria certinho. Em anexo estou enviando o arquivo, já com a alteração sugerida. Obrigado! ACBrBoletoFCFortesFr.pas

Beleza Ricardo, consegui eliminar os registros repetidos e minhas rotinas já estão totalmente funcionais. Vou disponibilizar o arquivo lá para o Cantu se ele quiser colocar no Firebase. Joguei os registros todos num banco mySQL on line e busco os CEST com uma rotina .php, a qual estou disponibilizando o arquivo aqui para quem for útil. Aí dá para listar os CESTs tanto por rotinas em Delphi, como em páginas de algum site. Obs.: a rotina em php é praticamente uma cópia daquela sua para Delphi, que você disponibilizou no outro post, hehe! Obrigado pela ajuda. getCEST.php

Ricardo, você disse que montou sua tabela pelo script disponibilizado no Firebirase pelo Cantu, certo? Fui copiar o o script lá e tem vários e vários itens duplicados como por exempla linha "INSERT INTO CEST_NCM (CEST, NCM, DESCRICAO_ITEM) VALUES ('1700300','18063220',substring('Chocolate em barras, tabletes ou blocos ou no estado líquido, em pasta, em pó, grânulos ou formas semelhantes, em recipientes ou embalagens imediatas de conteúdo inferior ou igual a 2 kg' from 1 for 512))". Tens ideia do porquê disso? Tem alguns que estão até triplicados. A lista completa tem mais de 1.500 itens. Quantos tem aí na sua tabela? Obrigado!

Obrigado Ricardo, Eu já tinha visto esse post e sua contribuição nele. Veja bem, para que sua rotina funcione, você precisa permitir que o usuário do seu sistema alimente com qualquer quantidade no campo do NCM de cada produto e não uma quantidade fixa de 8 dígitos, não é? Vamos pegar novamente o meu exemplo que, ou seja, NCM 0901 (CEST 1709600). Ao informar o NCM daquele produto na sua tabela de cadastros de produtos, o usuário vai informar "0901" e, com a rotina que você compartilhou nesse outro post, você encontrará o CEST. Até aqui tudo certo. Mas e quando você for gerar o XML da nota fiscal desse produto, você não busca o NCM da mesma tabela de cadastro, ou seja, terá NCM "0901" para esse item e, se informar esse dado no XML, vai dar erro, pois na nota fiscal, ele tem que ter 8 dígitos obrigatoriamente. Essa é minha dúvida. Obrigado!

Bom dia, Estou montando minha tabela de relação NCM x CEST. Porém, tem uma detalhe que ainda não entendi bem. Pesquisei bastante, mas não encontrei nada conclusivo. No manual de integração, exige-se que o NCM seja com 8 dígitos, certo? Mas, na maioria das tabelas que se consegue por aí, inclusive as oficiais, como esta, por exemplo https://www.confaz.fazenda.gov.br/legislacao/convenios/2017/CV027_17, em vários itens o NCM apenas tem 2, 3, 4, ..dígitos. Vamos pegar como exemplo o item 96.0 da tabela desse link acima. O CEST para o NCM 0901 é 1709600, certo? No meu sistema, exijo que o operador preencha o NCM do produto com 8 caracteres, já que quando for incluí-lo na nota, também precisará ser com 8. Mas então, como farei essa relação para buscar automaticamente o CEST 1709600 para o NCM 0901? Qual a logística que os colegas utiliza para tratar essa questão? Qualquer dica ajudará... Obrigado!

Bom dia, Gostaria de uma dicas/comentários de colegas que têm um conhecimento maior nessa questão de comunicação de porta, neste caso, da balança de checkout. O AcbrBal tem as funções .Ativar e .Destivar, o que, por lógica, nos diz que para o utilizarmos devemos ativá-lo e, em dado momento desativá-lo, certo? Até aqui nenhuma novidade. Minha dúvida é quando ele deve ser ativado e, principalmente, quando deve ser desativado. Quais dessas três opções seria mais recomedada: 1) Cada vez que for fazer uma leitura de peso, ativar e depois inativar? Nesse caso não comprometeria a performance já que, numa empresa de fluxo grande de vendas, essa operação seria feita cententas e centenas de vezes por dia? 2) Ativar no momento da abertura da tela onde ele será usado e desativá-lo quando a tela for fechada? 3) Ativar na abertura do sistema e inativar no fechamento dele? Dependendo da forma de uso do sistema numa empresa, a componente poderia ficar ativo o dia inteiro. Isso teria algum ponto contra? Obrigado!

Resolvido. Eu estava desde ontem fuçando e não encontrava nenhuma dica. For só abrir este post que apareceu a solução, rs... Precisa criar duas portas virtuais e cada programa usará uma delas. O post abaixo tem mais detalhes. Obrigado!