José Mauro

Bom dia Alexandre, Sim, isso ocorre devido o Locale. Tente com cp1252. Att.,

Alexandre, bom dia. Te enviei alguns arquivos que podem auxiliá-lo no processo. Att.,

Bom dia Bruno, Você está utilizando a versão atualizado do SVN? Att.,

Caro eliziorezende, Os ajustes propostas estão disponíveis no SVN. José Mauro

Bom dia Jackeline Santos, A dll sempre é o parâmetro base para comparação. Os ajustes foram realizados e liberado no SVN. Obrigado pela contribuição. José Mauro

Olá eliziorezende, Os arquivos foram recebidos. Iremos atualizar o repositório. Agradecemos a contribuição. Att.,

Bruno, Basta associar ao componente ACBrECF o componente ACBrAAC. Após esta associação você aciona, o método doAtualizarValorGT, presente no ACBrECF. Att.,

Boa tarde Jackeline, O erro ocorre apenas na classe de testes ou também em seu ambiente? Quais registros estão sendo informados? Att.,

Bom dia BrunoCosta, Como os colegas disseram essa é uma funcionalidade do ACBrAAC. Hoje utilizo o seguinte fluxo: 1) Ao iniciar o PDV obtenho na base de dados todos os equipamentos que tenho autorizado e jogo para o arquivo. Este processo basicamente é acrescentar da seguinte forma: AACECF lEcfAutorizada = new AACECF(); lEcfAutorizada.setCni(pCni); lEcfAutorizada.setCro(pCro); lEcfAutorizada.setValorGT(pValorGT); lEcfAutorizada.setNumeroSerie(pNumeroSerieEcf); lAcbrAac.getIdentPaf().getEcfsAutorizados().add(lEcfAutorizada); 2) Adicionados os ECF's e as demais configurações, salvo o arquivo. lAcbrAac.salvarArquivo(); 3) Verifico se a impressora conectada está presente no arquivo auxiliar de criptografia pelo número de série. lAcbrAac.achaIndiceECF(lAcbrEcf.getNumSerie()) >= 0 4) Caso exista o usuário entra no sistema. Não existindo é avisado que o ECF atual não está autorizado e que este deve ser acrescentado ao sistema. O processo de acréscimo do ECF fiz externo com outro módulo. Basicamente o usuário informa uma senha que carrega uma tela com todas as informações do ECF conectado: GT, número de série, fabricante, MF, etc., e o usuário informa o CNI e inclui em sua base de dados local. A partir dai ao entrar no sistema no novamente a ECF será dada como autorizada - refaz os passos anterior. Essa é uma abordagem que adotei por ter o processo mais desacoplado, mas o framework permite que você acrescente novas ECF's quando estas não são autorizadas. Para tal, você precisa configurar o PAF para recompor o número de série (propriedade do objeto que você irá configurar antes de salvar o arquivo pelo ACBrAAC), implemente o evento addOnVerificarRecomporNumSerie e acionar lAcbrAac.verificarGTECF. Caso não encontre o ECF este evento é acionado e você informar os dados do ECF que deseja adicionar e no retorno o framework o salva no arquivo. José Mauro

Boa noite Welkson, Hoje o jACBrFramework possui os recursos básicos para homologação, a geração de documentos eletrônicos NFe, NFC é preciso utilizar o monitor em Delphi. O processo de compilação da DLL realmente não posso te ajudar porque sempre utilizo a compilada do SVN. Como eu disse, hoje os Interops são gerados via reflexão pelo projeto mencionado, logo para utilizar aquele Exporter é preciso que os fontes em C# estejam atualizados com a DLL da biblioteca. Então para acrescentar uma nova funcionalidade hoje é preciso: atualizar os recursos no ACBrFramework.NET; exportar o interops; fazer o merge dos interops gerados com os antigos - as vezes são precisos alguns ajustes, ao gerar fica mais claro; criar manualmente as funcionalidades (classes, métodos, etc.) que se deseja incluir seguindo os padrões de nomes já existentes nos demais projetos. Esse é o fluxo básico para qualquer adição de funcionalidade. O processo de compilação o pessoal com certeza vai esclarecer melhor, o projeto em .NET quem atualiza é o Rafael Dias. A geração de arquivos, mesmo que ainda em beta, seria interessante dar uma olhada no JPOSBr, pois você não vai ter trabalho para criar novos registros pois lá está mais atualizado. Temos um refactor grande para subir para o JPOSBr, mas está bloqueado devido ao SVN, mas acredito que vale a pena considerar e deixar apenas a comunicação de dispositivos com o jACBrFramework. Att., José Mauro

Boa noite Welkson, Quanto a compilação não posso te ajudar pois sempre pego as DLL's já compiladas que ficam no repositório. Os Interops são gerados com base no fonte em C#, através do projeto CBrFramework\ACBrFramework.Net\ACBrDefExporter. Com base neles são construidas as cascas para acesso ao componente. Obs.: Há um projeto engatilhado com a parte de arquivos: AAC, EAD, PAF, Sped Fiscal, Contribuições, Contábil e Sintegra, que será nativo, sem a necessidade de acessar via JNI. Att.,

Felix, O registro 90 refere-se a totais que são calculados com base nos demais registros informados. Logo este é criado diretamente pelo framework, você não precisa informá-lo, pois ele será gerado de forma automática. José Mauro

Como o colega Juliomar colocou é bem provável que o problema seja o ambiente. Dê uma olhada no tópico, http://www.projetoacbr.com.br/forum/topic/22032-como-gerar-o-arquivo-do-menu-fiscal-tabela-índice-técnico-de-produção/, nele é informado como atualizar o jACBrFramework e sua dll. Outro ponto que observei é em relação aos prints com traces que estão sendo colocados, pegar estas soluções prontas geralmente é necessário uma boa revisão. Esse projeto foi feito a alguns anos como um howto de PAF, talvez o mesmo não contemple mais a versão de requisitos existentes e não esteja atualizado.

Bom dia, Faça algo como: getEcf().gerarArquivo(getNomeArquivoMFOuMFD(false)); /** * Obtem o nome do arquivo MFD ou MF. * * @param pIndMFD indica se e um arquivo MFD. * @return nome do arquivo. * @throws IOException */ protected String getNomeArquivoMFOuMFD(boolean pIndMFD) throws IOException { String lNomeArquivo = MessageFormat.format("{0}arq_mf{1}.mf{1}", getCaminhoBaseAplicacao(), pIndMFD ? "d" : ""); criarArquivoComDiretorio(lNomeArquivo, true); return lNomeArquivo; } Basicamente o getCaminhoBaseAplicacao() retorna o diretório de execução do aplicativo e criarArquivoComDiretorio cria um arquivo em branco e remove o antigo caso o mesmo existir. José Mauro

Que bom. Por favor, marque o tópico como resolvido. José Mauro

Boa noite Jackeline, Seu jar deve estar desatualizado. Atualizei os fontes em: https://svn.code.sf.net/p/acbr/code/ACBrFramework/jACBrFramework/jACBrFramework/, e gere uma nova lib. Além disso atualize a DLL que é utilizada como wrapper para a biblioteca em: https://svn.code.sf.net/p/acbr/code/ACBrFramework/ACBrFramework/x86/cdecl/ACBrFramework32.dll. José Mauro

Habilite o log nos componentes para termos o que analisar. Para homologar hoje no paf, você precisar todos métodos: getEcf().gerarArquivoMF(pArquivo); getEcf().gerarArquivoMFD(pArquivo); getEcf().pafMF_MFD_Cotepe1704(pReducaoInicial, pReducaoFinal, pCaminhoArquivo); getEcf().pafMF_MFD_Cotepe1704(pDataInicial, pDataFinal, pCaminhoArquivo); Estes que vão acessar a memória fiscal. Anexe o log do componente para termos o que verificar, como falei este erro é retornando pela dll da própria fabricante, o log auxilia no processo de verificação.

Verifique se está com as DLL's do fabricante atualizadas, pois as rotinas MFD são repassadas a elas. Nunca trabalhei com Daruma mas acredito que tenha algum mecanismo de habilitar log das chamadas, tente fazer isso para verificar onde pode estar ocorrendo o problema. Um outro ponto que pode auxiliá-lo é habilitar o log do ACBrECF. Além disso é interessante manter as DLL's juntamente com a aplicação para não correr o risco de carregar resquícios de outras versão e ficar mais fácil o seu controle.

O tipo de contador pode assumir 0 - COO ou 1 - CRZ. Realize os testes de MF por favor junto ao ECF.

Boa tarde Fernando Werneck, Alguns métodos podem estar desatualizados em relação aos métodos disponíveis no ACBrFramework_32.dll, pois o jACBrFramework é apenas um wrapper para a dll. Por favor verifique os seguintes pontos: 1) Atualize a dll ACBrFramework_32.dll; 2) JDK 32 bits com a DLL em 32 bits, isso é devido ao uso do JNA; 3) Caso ocorra algum erro de violação de acesso de memória nos informe para corrigirmos o Wrapper pois a dll pode ter sido evoluída; No caso do método que você cita, gerarArquivoMF, está condizente com o que é na DLL, mas como é leitura da memória fiscal o comportamento será adequado apenas fora de emuladores. José Mauro

brunosafewaretecnologia, Os possíveis valores para finaliza e tipo de documento são: Finaliza: 0 - finMF, 1 - finMFD, 2 - finTDM, 3 - finRZ, 4 - finRFD, 5 - finNFP, 6 - finNFPTDM, 7 - finSintegra e 8 - finSPED. Tipo de Documento: 0 - docRZ, 1 - docLX, 2 - docCF, 3 - docCFBP, 4 - docCupomAdicional, 5 - docCFCancelamento, 6 - docCCD, 7 - docAdicionalCCD, 8 - docSegViaCCD, 9 - docReimpressaoCCD, 10 - docEstornoCCD, 11 - docCNF, 12 - docCNFCancelamento, 13 - docSangria, 14 - docSuprimento, 15 - docEstornoPagto, 16 - docRG, 17 - docLMF, 18 - docTodos e 19 - docNenhum. Estes campos são para indicar aos métodos base quais registros devem ser gerados. Você está realizando a leitura no emulador ou diretamente na impressora? José Mauro

Boa tarde Jackeline Santos, Creio que o método que você esteja procurando seja: saveFileTXT_TITP. Verifique por favor a classe em anexo e veja se atende o que você precisa. Att., José Mauro ProgramTestPaf.zip

Em java está encapsulado apenas o Sped Fiscal, pelo que eu sei não existe este bloco nele. Não há o Sped Contribuições e nem o Sped Pis/Cofins e não existe uma previsão para porta-lo. No Sped Pis/Cofins o registro M é uma consolidação dos blocos A, C, D e F, dê uma olhada no PVA que o mesmo talvez ofereça está consolidação. Att. José Mauro

Show de bola.. era mesmo para entender se este era o comportamento os se estávamos pensando alguma coisa errada. Imagino que seja apenas remover o item da lista, mas só vendo mesmo. Vou dar uma olhada aqui. Obrigado.

Bom dia Daniel, obrigado pelo retorno. Estamos utilizando o TEF dedicado. Não confirmamos nenhuma transação manualmente, o ACBrTEFD faz corretamente o processo como você disse. A dúvida, não sei se é um erro no framework, é a seguinte: "Por exemplo, uma venda é realizada em cima do COO 00001, o cliente paga com dois cartões (qualquer valor desde que pague toda a venda) e estas vendas ainda não foram confirmadas no SiTef pela biblioteca, conforme você mencionou. Sendo assim temos N transações autorizadas para uma venda, N:1, até aqui é o processo padrão sem nenhum problema. Porém, antes de finalizar o cupom fiscal, i.e., ainda não foi confirmada nenhuma autorização, o cliente resolve desistir de pagar com um dos cartões, mesmo tendo sido autorizado pelo TEF. Para este caso acionamos explicitamente o NCN para cancelar a autorização informando rede, nsu, valor, data/hora transação e finalização, os campos da assinatura do método. Ao acionar, a transação autorizada muda no SiTef para CANC. PDV perfeitamente, mas não são da lista de transações pendentes do ACBrTEFD pois quando mandamos imprimir as transações pendentes a transação que enviamos NCN sai impressa no cupom vinculado. Neste ponto que ficou a dúvida, se a transação autorizada foi "descontinuada" junto ao SiTef, seria correto imprimi-la no cupom vinculado?" Obrigado novamente. José Mauro