José Mauro

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

Teste especificar o charset no construtor do ACBrAAC, Charset.forName("cp1252"). Quanto tive esse problema no ACBrSintegra e ACBrSpedFiscal, resolveu desta forma.

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

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

Caro Geovani, Foi acrescentanda a informação do COO no registro R07. Liberado na revisão 7330. Atualize a ACBrFrameworkXX.dll. 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.,

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

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

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

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

Sim já foram. É preciso atualizar a dll para funcionar.

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