André Angeluci

Pelo que entendi, a partir da NFe 4.0 a SEFAZ passou a rejeitar requisições com protocolos diferentes do TLS 1.2. Porém, só agora vão desinstalar os protocolos antigos. Teoricamente, ngm vai ter dor de cabeça com isso. Entendi corretamente?

O intuito do ajuste proposto é ignorar a mensagem de erro quando o CNPJ do emissor for o mesmo do CNPJ destinatário, como é orientado no manual. Porém, esse método faz consistências nas regras de negócio no XML antes do envio à SEFAZ, se vc estiver recebendo essa rejeição ao tentar autorizar a NFe provavelmente existe alguma informação errada. Anexa o XML aqui pra darmos uma olhada.

Problema persiste até hoje nos servidores de SP...

Na unit ACBrNFeNotasFiscais existe a rotina ValidarRegrasdeNegocios, que faz uma série de validações dos dados da NFe. Segundo o manual de integração, a rejeição 772 (Operação Interestadual e UF de destino igual à UF do emitente) acontece em NFes de operação interestadual (idDest = 2), UF destino igual à UF origem e CNPJ do destinatário diferente do CNPJ do emitente. Essa última consistência não é feita pela rotina, fiz um pequeno ajuste para corrigir. Código anterior: if (nfe.Ide.idDest = doInterestadual) and (NFe.Dest.EnderDest.UF = NFe.Emit.EnderEmit.UF) then AdicionaErro('772-Rejeição: Operação Interestadual e UF de destino igual à UF do emitente'); Código ajustado: if (nfe.Ide.idDest = doInterestadual) and (NFe.Dest.EnderDest.UF = NFe.Emit.EnderEmit.UF) and (NFe.Dest.CNPJCPF <> NFe.Emit.CNPJCPF) then AdicionaErro('772-Rejeição: Operação Interestadual e UF de destino igual à UF do emitente'); Manual de integração: Segue anexo a unit ACBrNFeNotasFiscais com a correção. Obrigado! ACBrNFeNotasFiscais.pas

Precisei fazer integração com uma balança da marca Micheletti e percebi que a comunicação com o equipamento funciona no mesmo padrão da Filizolla ou Toledo. Porém a resposta da leitura do peso é formatada de uma maneira diferente. Segue anexo as implementações necessárias para a leitura correta. ACBrBAL.pas ACBrBALMicheletti.pas

Boa tarde Daniel. Sim, carreguei o CFeCanc com o LoadFromFile. if (ide.tpAmb = taHomologacao) then NumExtrato := '000000' else NumExtrato := Trim( IntToStr( ACBrSATExtrato.CFeCanc.ide.nCFe ) ); É nesse bloco de código que o número de extrato é alimentado, quando carrego apenas o CFeCanc com o .xml de cancelamento, o ide.tpAmb fica como taHomologacao. Devo então usar o CFe.LoadFromFile() e o CFeCanc.LoadFromFile() juntos?

O número de extrato do CFe está saindo zerado na impressão de cancelamento com o Fortes report. Fiz um pequeno ajuste para corrigir o problema, segue anexo a unit corrigida. ACBrSATExtratoFortesFr.pas

Entendi, tudo bem ent... Fica o código caso seja útil à alguém.

A informação é necessária para enviar o e-mail ao cliente após o faturamento.

Decidi fazer dessa forma pois existem outras maneiras de interceptar o XML gerado, seja por um vírus tratando os arquivos gerados pelo emissor ou até um sniffer interceptando as requisições à Sefaz. Dessa maneira eu consigo guardar o e-mail do destinatário para poder enviá-lo posteriormente, em um faturamento por lote, por exemplo, sem ter que gravar a informação no XML.

Prezado, muitos já se depararam com um golpe aplicado em contribuintes que informam o e-mail de seus clientes no XML da nota fiscal eletrônica, criando uma vulnerabilidade que possibilita a falsificação de boletos com o mesmo valor do documento. Já foi discutido o assunto nesse tópico: Adicionei uma propriedade ao TACBrNFe que define se a tag será alimentada no XML, possibilitando assim informar o atributo "email" do destinatário, sem serializar no XML. Segue anexo as units alteradas: pcnNFeW.pas ACBrNFeNotasFiscais.pas ACBrNFeConfiguracoes.pas

Bom dia, para resolver o problema, fiz a instalação do software de ativação da Bematech, com o intuito de que fosse instalado os softwares e DLLs que poderiam ser usados na comunicação (.net framework, etc). Após isso peguei a .dll e o .xml de configuração usados pelo software de ativação e coloquei no meu projeto, mudei o modelo de chamada da .dll para stdCall e funcionou perfeitamente. Obrigado à todos.

Entendi... eu fiz uma instalação nova do ACBr nessa VM diretamente no Trunk2.

Sim, dei build no projeto todo. Retornou a mensagem "Erro na abertura da porta de comunicação de o S@T.". Provavelmente não foi possível acessar a DLL.

Boa tarde, estou tentando fazer a integração de um software com um SAT Bematech mas estou tendo problemas em chamar a rotina ConsultarStatusOperacional, ocorre access violation dentro da unit ACBrSAT. Estou utilizando a ultima versão da DLL disponibilizada no site da bematech e o modelo de acesso à ela satDinamico_cdecl. Utilizo o Delphi 7 com o Windows XP. Segue anexo a DLL, print do erro e log do componente. Alguém sabe como proceder? Log.txt BemaSAT.dll