Ir para conteúdo
  • Cadastre-se

José Mauro

Membros
  • Total de ítens

    115
  • Registro em

  • Última visita

  • Days Won

    1

Posts postados por José Mauro

  1. Bruno,

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

    Att.,

  2. 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

     

  3. 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:

    1. atualizar os recursos no ACBrFramework.NET;
    2. exportar o interops;
    3. fazer o merge dos interops gerados com os antigos - as vezes são precisos alguns ajustes, ao gerar fica mais claro;
    4. 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

     

  4. 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.,

     

    • Curtir 1
  5. 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.  

  6. 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

     
  7. 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.

     

  8. 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.

  9. 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

  10. 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

     

  11. Rapaz, ou não tem, ou não to achando, espero que seja a segunda.

    Alguem já precisou usar o bloco M, vlw.

     

    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

  12. Acho que realmente isso não foi previsto... (chamar o NCN para o TEF dedicado)

     

    Seria necessário ajustar o componente para remover a transação da lista de pendentes... (não deve ser difícil)

    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.

  13. Fiquei confuso... qual é o modelo de TEF que você está usando no ACBrTEFD ?

     

    Com a CliSiTef.DLL não há necessidade de confirmar uma transação para poder enviar outra (assim como ocorre no discado)

     

    Ou seja, você pode deixar todas as transações pendentes... sobe o mesmo numero de Cupom...

     

    Quando confirmar ele confirma todas pendentes... (commit)

    Quando enviar a Não confirmação ele desfaz todas as transações pendentes... (rollback)

    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

    • Curtir 1
×
×
  • Criar Novo...

Informação Importante

Colocamos cookies em seu dispositivo para ajudar a tornar este site melhor. Você pode ajustar suas configurações de cookies, caso contrário, assumiremos que você está bem para continuar.