José Mauro
-
Total de ítens
115 -
Registro em
-
Última visita
-
Days Won
1
Tipo de Conteúdo
Blocks
Notes ACBrLibNFe
Fóruns
Downloads
Calendário
Posts postados por José Mauro
-
-
Teste especificar o charset no construtor do ACBrAAC, Charset.forName("cp1252").
Quanto tive esse problema no ACBrSintegra e ACBrSpedFiscal, resolveu desta forma.
-
Achei que poderia ser o SO, estava no XP testei no 7 e no 8 32 e 64, e deu no mesmo
Verifique se está utilizando a DLL mais recente do ACBrFramework32.dll - lembrando que a dll 64 está descontinuada e jdk deve ser de 32 bits.
-
Realmente deve ser a versão do JNA, conforme o Rafael disse. O exemplo presente no framework está gerando corretamente o arquivo com estes registros.
-
Acabei de realizar o teste de geração dos registros 60D e 60I e não houve problema na geração. Em anexo o arquivo gerado com a versão que está no SVN.
Att.
-
Obrigado, mas eu já havia feito esse teste, e também não gerou. Estranho não
Tente informar toda a estrutura do bloco G e não somente o bloco G110, preferencialmente, com valores próximos a realidade, e verifique se os registros serão gerados. Observe que o layout específico no registro de abertura afeta diretamente os registros formados.
-
Altere o registro para ComDados.
De:
sped.getBlocoG().getRegistroG001().setIND_MOV(IndicadorMovimento.SemDados)
Para:
sped.getBlocoG().getRegistroG001().setIND_MOV(IndicadorMovimento.ComDados)
Att.
-
Boa tarde.
Ajustes do ACBrAAC e ACBrTED (CliSiTEF) liberados na revisão 7357.
Att.,
-
Boa tarde.
A questão relacionada ao componente ACBrAAC foi resolvido e em breve será liberado. Estamos verificando a questão do ACBrTEFD e acreditamos que a situação seja análoga ao do corrigido para o ACBrAAC.
Quando você diz: "...Porém se faço fora da thread ele funciona corretamente....", o que isso realmente significa, Unit Test? Rodando a classe de Teste?
Att.,
- 1
-
Registro R07
em Java
Caro Geovani,
Foi acrescentanda a informação do COO no registro R07. Liberado na revisão 7330.
Atualize a ACBrFrameworkXX.dll.
Att.,
- 1
-
jmsandy, verificamos aqui que o problema estava na biblioteca jna, no nosso projeto estávamos utilizando a jna-3.2.5 e o acbr jACBrFramework utiliza a jna-3.5.1, atualizado o arquivo e o problema dos caracteres foi resolvido.
Obrigado pela ajuda.
Att
Show de bola.
Quando houver um tempo, vamos avaliar a possibilidade de colocar a lib no maven e melhorar o empacotamento com exemplos.
Att.,
-
Cleonir,
Realizei novamente os testes com o exemplo do SVN e não aparece o problema. Alterei o nome da software house para o nome da empresa de vocês e a geração foi bem sucedida, assim como a informação da validade dos registros. Lembrando que o nome da software house é marcado com "?" quando o registro é marcado como excluído.
Qual é o ambiente que você está executando? Atualize a dll do ACBrFramework.
Meu ambiente é Win 2008 x64 R2, com jdk 7, com idioma en-US.
Att.,
-
jmsandy, fiz alguns testes e verifiquei o seguinte:
o R02 ainda está apresentando caracteres estranhos;
Anexei o arquivo gerado
Att
Geovani,
Este cenário está relacionado ao charset associado ao componente. Eu utilizo o cp1252, conforme abaixo:
ACBrPAF lAcbrPaf = new ACBrPAF(Charset.forName("cp1252"));
Desta forma não há este problema no encoding.
Att.,
-
Caro Geovani,
Havia um problema no recebimento dos dados via JNA. Foi realizada a modificação e liberado no repositório, revisão 7312.
Por favor verifique se o erro persiste.
Att.,
-
Fiz os testes com a geração de arquivo de registros do PAF-ECF, acontece um erro do oleData no momento de preencher o Registro do Tipo E1 com a data null. Afinal para esse relatório não eh mais preciso os dados do Registro E1.
fiz a seguinte alteração na classe ACBrPAF.java:
lRegistroE1.DT_EST = null != paf_E.getRegistroE1().getDataEstoque()? OleDate.toOADate(paf_E.getRegistroE1().getDataEstoque()) : 0.0;
A classe OleDate foi modicada para retornar 0d caso a data informada seja nula. Desta forma qualquer registro que vier a fazer uso da conversão não terá problema. Liberado no repositório, revisão 7312.
-
Liberado na revisão 7309 alguns ajustes relacionados ao PAF. Por favor verifiquem se o erros ainda persistem.
Att.,
-
Com relação ao registro R está atribuindo uns caracteres estranhos... segue o arquivo gerado pelo teste e pela minha aplicação.
Este é um dos problemas apresentados acima. Estamos verificando o fluxo junto ao JNA.
-
Caro Geovani,
O problema está no tipo boolean no envio dos interops do ACBrPAFInterop. Conseguimos resolver para o registro D mas não para o R, que está apresentando problemas em outros pontos. Estamos verificando uma solução para tal. Acompanhe os fontes que em breve será liberado.
Att.
-
Boa tarde.
Atualmente a lib em java não possui o recurso para parte deste requisito. A lib, em java, contempla apenas Paraíba Legal, Cupom Mania e Minas Legal.
Creio que mesmo estando dentro do mesmo perfil, deste que sua UF não seja DF, você não está obrigado a mostrar estas informações extras.
Por favor, poste esta dúvida no fórum específico que com certeza haverá algum usuário que já passou por este cenário.
Att.
-
Boa tarde,
Estamos providenciando as correções e amanhã liberamos os ajustes.
Att.,
-
Boa tarde CELL Corporação Tecnológic,
Estamos pesquisando para ver se conseguimos resolver estes problema ao acionar os listeners. O que fiz aqui, como paliativo foi o seguinte:
"Tenho uma classe que encapsula os componentes do ACBr e esta classe é Singleton, que retorna uma instância que obtenho os componentes. Sempre que aciona o getInstace() já seto as chaves novamente nos componentes, como os componentes são únicos dentro do ciclo de vida da jvm, acaba redundando as chaves, mas este erro desaparece".
O ideal é descobrir como resolver este problema de vez, estamos olhando como resolver, mas da forma acima é possível contornar.
Ps.: Não sei se você tem alguma operação que faz uso de multithread, para controlar o acesso concorrente a impressora, coloquei nessa classe singleton um conceito de semáforo nos componentes e resolveu problemas de acesso concorrente aos recursos da ECF.
Att.,
-
jmsandy, nesse meio tempo entre o post e a sua resposta, cheguei exatamente ao que você falou acima, porém achei que fosse algo a mais, estou tentando vasculhar o projeto em delph, porém, meu conhecimento nessa linguagem é muito pouco.
Por hora vou fazer como você disse, mas acredito que isso seja um problema a ser observado e corrigido.
Att
Tanto em Delphi quanto em .NET isso acaba sendo mais tranquilo. O que complica nestes casos é o acesso via JNA por algum motivo o handler não é acionado, talvez pela gerencia de threads, synchronized, etc. Não tenho uma ideia fixa sobre isso.
Mas com certeza é um ponto que precisa ser verificado.
Att.,
-
Boa tarde.
Tive um problema parecido e resolvi setando a chave novamente no componente. Basicamente tenho o seguinte:
1) Três componentes ACBrECF, ACBrEAD e ACBrAAC;
2) Referencio os componentes ACBrEAD e ACBrAAC, no componente ACBrECF;
3) Na hora da chamada eu recrio o listener das chaves privadas;
Ainda não consegui detectar, mas em alguns momentos o handler não é acionado. Como resolveu a situação fui para outros pontos que precisava resolver na app. Penso que seja algo vinculo a lock no threads e o JNA não aciona ou algo do tipo.
Att.,
-
Gostaria de saber se já foi compilado o acbrframework.dll com essas atualizações?
Sim já foram. É preciso atualizar a dll para funcionar.
-
O problema é que ainda temos ECF que arredonda ou trunca... com isso pode ocorrer diferença na hora do fechamento de cupom. Isso ocorre na multiplicação de produtos fracionados.
Você consegue especificar se a quantidade de casas decimais para o valor e quantidade. Além de informar se será ou não truncamento. Desta forma você consegue fechar o movimento com maior precisão, configurando seu sistema para trabalhar com a mesma estrutura que a ECF.
Att.,
Recebimento Em Múltiplos Cartões Com Cancelamento
em Dúvidas sobre TEF
Postado
Pessoal boa tarde.
Estamos implementando o processo de pagamento utilizando o ACBrTEFD com a CliSiTef e ficamos na dúvida sobre como proceder quando houver a desistência de alguma das transações autorizadas. Devido a isto levamos o seguinte cenário para a Software Express:
1) O cliente chega ao estabelecimento e paga com 2 cartões, cada um representando metade da venda;
2) Ambas as autorizações são aprovadas pelo SiTef;
3) Passados alguns segundos, a transação ainda não foi finalizada (encerramento de CF + impressão de CCD), o cliente decide que não vai pagar mais em um dos cartões e que pagará a diferença em dinheiro, ou seja, metade será em um dos cartões e a outra em dinheiro.
Como devemos proceder com este cenário, cancelamos toda a venda para que haja a impressão do comprovante de estorno (HEADER = CNC) ou simplesmente cancelamento a autorização (HEADER = NCN)?
Com base no cenário levantado, a SE respondeu:
No cenário apresentado você teria que mandar uma NCN (Não confirmação da venda) para o cartão que houve a desistência, pois os dois ainda não receberam a CNF (Confirmação da venda), agora se as duas já tivessem recebido a CNF, teria que mandar a CNC (Cancelamento de Venda).
Implementamos o processo enviando o NCN (o SiTef muda o estado para CANC. PDV) mas quando acionamos o método para imprimir transações pendentes, a transação que não foi confirmada pelo NCN é impressa também.
Ao realizar a não confirmação de uma autorização ela não deveria sair da lista de transações pendentes?
Segue em anexo um exemplo onde o pagamento de R$ 100,00 não foi confirmado. A DLL utilizada é a versão 0.9.6.3.
Obrigado.
José Mauro
trace-multiplos-cartoes.txt