EMBarbosa

Olá, Acho que não tem uma regra sobre isso. Na verdade o roteiro para NFC-e, até onde me lembro, é exatamente o mesmo para impressoras não fiscais. Contudo, eu sugiro você confirmar a transação TEF primeiro. Assim, caso o pagamento TEF não seja confirmado você não precisará alterar/cancelar a NFC-e que já transmitiu. Imagine que o cartão não passe e você já transmitiu a NFC-e com a forma de pagamento tipo TEF? Ainda tem que você precisa preencher alguns dados da NFC-e com detalhes da transação que só vão estar disponíveis depois. Além disso, caso tenha que fazer algum tratamento de contingência, a parte do TEF já foi confirmada. Acho que você poderia usar o evento onDepoisConfirmarTransacoes pra esse objetivo. A lista de respostas pendentes é adicionada na ordem que são feitas as chamadas. Então a última da lista é a última que foi feita... Você pode dar uma olhada nos seguinte tópico e no tópico que ele menciona: Se não estiver usando o SiTef tem outros tópicos sobre o assunto como: e também esse: https://www.projetoacbr.com.br/forum/topic/37672-como-capturar-os-dados-do-acbrtefd/

Que bom que resolveu. Muito obrigado pelo retorno. Bom trabalho por aí.

E você tem certeza que não está vindo nenhum registro? Em caso afirmativo, eu sugiro você utilizar algum profiler. É melhor você medir exatamente onde está a demora que a gente ficar especulando. Talvez queira tentar o dbgSpider, ou o asmprofiler, ou ainda o Sampling Profiler.

Não sei de qual tipo de Dataset é o componente TB10000, mas geralmente PacketRecords não quer dizer quantos registros você vai puxar do BD. Apenas quantos vai puxar por vez. Então setar ele como 0 não vai necessariamente impedir de puxar todos registros da tabela. Bom, no código está apenas o Post e o ApplyUpdates. Qual método do componente você está utilizando para abrir um novo registro? Insert? Append?

Depende da forma que você faz a gravação. Por exemplo, se estiver carregando dados da tabela ao gravar, isso pode acontecer.

O gerenciador gpTefDial funciona diferente do gpCliDTEF. O gerenciador gpTefDial funciona por troca de arquivos como era comum há alguns anos quando a maioria dos comércios usavam TEF discado. Talvez eles tenham atualizado a aplicação TEF e alterado o modo do gerenciador trabalhar e por isso parou de funcionar. Independentemente disso, quaisquer um desses eventos são demonstrados nos aplicativos de exemplo. Você pode verificar a implementação neles. Mas aqui vai uma explicação rápida: OnObtemInformacao é um evento que trata as situações onde o Gerenciador do TEF está obtendo as informações do usuário. Então você deve criar uma tela para obter essa informação do usuário e retornar ao gerenciador TEF. Por exemplo: Qual a senha do Administrador? Em quantas vezes vai dividir? Qual o valor da taxa de embarque? Etc... ExibeMenu é um evento que gera para o usuário um menu com várias opções para que ele escolha uma. Assim você deve criar uma tela que mostre as opções e permita ele escolher uma. Por exemplo: É Crédito, Débito, Alimentação? É parcelado ou a vista? Dá uma olhada no aplicativo de exemplo que deve ficar claro como é simples fazer uma implementação dessas.

Veja bem, o seu log diz que a compilação do ACBr_Comum foi "um sucesso". Veja o log apenas a parte relevante: 29921 lines, 0.30 seconds, 121624 bytes code, 14861 bytes data. Compilation success Pacote "ACBr_Comum.dpk" compilado com sucesso. Então, pelo menos em teoria, o arquivo BPL deveria estar sendo criado. Mas se isso não está acontecendo, então você não vai conseguir compilar os outros pacotes pois eles dependem do ACBr_Comum. Talvez tenha que começar a avaliar se seu Delphi está instalado corretamente, se não está com algum conflito com o sistema operacional, se algum antivírus ou antimalware não está entrando em conflito. Em último caso, tente compilar e instalar os pacotes manualmente.

Que isso. Agradecemos o retorno. Bom trabalho por aí.

Olá, Esse código não parece ser do componente de SAT. Poderia verificar onde está definida essa variável 'AliqICMS' e qual o tipo dela? Pois ela parece estar definida como Integer.

Só um aviso. Esse evento serve para que você possa analisar e preencher os detalhes dos itens caso necessário. Então não basta descomentar. Você precisa preencher e/ou validar os dados que geralmente não vão no ECF, mas precisam ir na NFC-e, como CST/CSOSN, CFOP, etc...

Por favor, nos dê um retorno se conseguiu resolver.

Ficamos felizes em ajudar. Temos uma política de apenas um assunto por tópico. Por isso, por favor, da próxima vez crie um novo tópico para uma nova dúvida. Note que essa mensagem de erro foi interceptada pelo debugger do Delphi. Mas ela é originária do sistema operacional. Está dizendo que não foi possível criar o arquivo por causa de seu caminho ou nome. E isso fica evidente no nome do arquivo na mensagem, veja: "C:\uniquesystems\teste.txt " Tem um parágrafo no nome do arquivo. Isso não é permitido. Não sei como você está passando o nome para o componente, mas investigue isso daí.

Não vejo como problema. Na verdade isso indica que várias coisas estão certas. Podemos então procurar o que não está. Essa é a linha do seu projeto. É necessário que você a coloque por inteiro. Tente colocar um breakpoint nessa linha e depois ir apertando F7 para seguir dentro do código do componente até descobrir qual linha gera o AV (Access Violation). Isso apenas indica que o caminho que o código seguiu não gera o Access Violation. Talvez porque ele é gerado após a validação das alíquotas.

O que está mencionado na sua imagem me parece ser sobre a EFD ICMS/IPI, ou seja o SPED Fiscal. Sendo assim, o componente para te ajudar a gerar o arquivo é o ACBrSPEDFISCAL.

E nessa outra máquina está funcionando? E onde está o arquivo ACBr_Comum.bpl?

Acredito que está havendo alguma confusão na sua máquina. Veja que no log do ACBrInstall que você anexou não está mencionando a pasta trunk2 como você disse acima que existe: Compiling package C:\ACBr\Pacotes\Delphi\ACBrComum\ACBr_Comum.dpk "C:\Program Files (x86)\Borland\Delphi7\bin\dcc32.exe" "C:\ACBr\Pacotes\Delphi\ACBrComum\ACBr_Comum.dpk" Se você não conseguir descobrir o motivo dessa diferença, talvez tenha que apagar a pasta C:\ACBr e remover o ACBr completamente do Delphi antes de tentar fazer uma nova instalação.

Da mesma maneira que faria com outros TListBox não funciona? Usar a propriedade Items e o método IndexOf.

Obrigado por ter colocado a mensagem completa do erro. Por favor, coloque sua aplicação em modo de debug e verifique exatamente em qual linha esse erro acontece. Geralmente Access Violation acontece quando você tenta acessar propriedades ou métodos de um objeto que ainda não foi instanciado ou que já foi destruído.

hmmmm... então basta verificar o motivo disso estar acontecendo. Daí você consegue resolver o problema.

Uma sugestão é você ter uma tabela no seu sistema e atualizar ela de vez em quando. Daí você tem o melhor dos dois modos.

Pra transformar sua aplicação PAF em emissora de NFC-e, esses realmente são os comandos principais. Mas você pode continuar verificando pelos outros comandos do ECF caso sejam interessantes pra você. Por exemplo, caso seus clientes utilizem, Suprimento, Sangria, Leitura X e Redução Z, talvez você queira implementar algum controle nessas funções. Mas isso não está diretamente relacionado com a NFC-e, mas sim com as regras de negócios do seu sistema. Depois de fazer isso, você pode continuar a expandir seu aplicativo por implementar coisas que são específicas da NFC-e...

Teria que verificar no código fonte do Fortes. Mas isso não deveria ser necessário. De modo geral, todos os usuários tem acesso a pasta temporária do sistema operacional, mesmo que você tenha alterada para outra pasta. Se isso não está acontecendo, seria melhor você verificar o ambiente em que seu software está rodando.

Qual a mensagem de erro?

O que está disponível nesse tópico foi criado pelos usuários, mas não foi adicionado aos componentes ACBr.