José Mauro

Penso que não vai ficar muito legal não.. Esse valor é acumulativo, então não vai servir... estava fazendo na mão e resolvi trocar para isso e testar deu problema. Desconsidera isso. Att.,

Caso você queira mandar o valor total informado e deixar que a ECF calcule o valor e depois você resgate pode também. Basta mandar o valor total da venda e acionar o método: ecf.getTotalTroco(). Ele vai te retornar o troco que a ECF calculou e você só grava o valor e não precisa calcular na mão. Att.,

Os registros S2 e S3 foram adicionados e estão liberados para testes no SVN. Att.,

Bom dia levymoreira, Não seria possível você usar algo que emulasse a biblioteca nativa? Por exemplo o wine. Tenho sistema em C# que roda através do mono redondo, penso ser até melhor para você para conseguir ajuda, infelizmente no ramo de automação ainda não há tantas estações de trabalho rodando Linux. Estes dias estão meio complicados mas assim que possível vou tentar rodar para ver se reproduzo o problema, você está usando qual distro? 32 ou 64 bits? Att.

Deve ser o comportamento da impressora mesmo, como utilizado sempre com a Bematech não tinha passado por isso. É até bom que inverto o meu lado aqui para não ter problema com outras marcas. Att.,

Qual é a impressora que você está utilizando? Fiz os testes com o emulador da bematech e a ECF MP4000, e em ambos o valor do índice foi o desejado. O índice é a representação em string com dois caracteres do sequencial. De qualquer forma havia um erro no interop para obtenção do sequencial, mas é estranho o índice não ter retornado o valor correto. Obtendo as alíquotas: ecf.carregaAliquotas(); Aliquota[] lAliquotas = ecf.getAliquotas(); for (Aliquota lAliquota : lAliquotas) { System.out.println( "Sequencial: " + lAliquota.getSequencia() + " Indice: " + lAliquota.getIndice() + " Tipo: " + lAliquota.getTipo() + " --> " + lAliquota.getAliquota()); } Saída: Sequencial: 1 Indice: 01 Tipo: T --> 18.0 Sequencial: 2 Indice: 02 Tipo: T --> 12.0 Sequencial: 3 Indice: 03 Tipo: S --> 18.0 Atualize os fontes e teste novamente. Att.,

O que você quer é o índice e não o sequencial. Faz isso: MessageFormat.format("{0}{1}{2}", StringUtils.leftPad(pIndice, 2, '0'), Character.toUpperCase(pTipo), StringUtils.leftPad(String.valueOf(new BigDecimal(pValor * 100).intValue()), 4, '0') Onde: pIndice -> obtido da alíquota; pTipo -> 'T' para ICMS ou 'S' para ISS; pValor -> valor associado ao totalizador. Att.,

Tranquilo, acontece. Aparecendo mais diferenças nos avise para irmos corrigindo. Att.,

Como está o seu enum TipoFrete? Post os valores. O mesmo deveria estar assim: PorContaEmitente(0, "0 - Por conta do emitente"), PorContaDestinatario(1, "1 - Por conta do destinatário/remetente"), PorContaTerceiros(2, "2 - Por conta de terceiros"), SemCobrancaFrete(3, "9 - Sem frete"), Nenhum(4, "Preencher vazio"); Fiz o checkout do zero e não teve esse comportamento. Att.

Boa tarde. Dê uma olhada na data que está sendo passada ao registro. Abaixo um exemplo feito em cima da versão que está no SVN: ACBrSpedFiscal sped = new ACBrSpedFiscal(Charset.forName("cp1252")); sped.setDelimitador("|"); sped.setPath(Paths.get("").toAbsolutePath().toString() + "\\"); sped.setArquivo("sped_teste1.txt"); sped.getBloco0().setDataInicial(new Date()); sped.getBloco0().setDataFinal(new Date()); sped.getBloco0().getRegistro0000().setCNPJ("58565051000140"); sped.getBloco0().getRegistro0000().setNOME("Empresa Teste"); sped.getBlocoC().setDataInicial(new Date()); sped.getBlocoC().setDataFinal(new Date()); sped.getBlocoC().getRegistroC001().setIND_MOV(IndicadorMovimento.ComDados); RegistroC100 regC100 = new RegistroC100(); regC100.setIND_OPER(TipoOperacao.SaidaPrestacao); regC100.setIND_EMIT(Emitente.EmissaoPropria); regC100.setCOD_PART("12312312387"); regC100.setCOD_MOD("55"); regC100.setCOD_SIT(SituacaoDocto.Regular); regC100.setSER("1"); regC100.setNUM_DOC("15"); regC100.setCHV_NFE("5140700593850000150550010000000151000001584"); regC100.setDT_DOC(new Date()); regC100.setDT_E_S(new Date()); regC100.setVL_DOC(1d); regC100.setIND_PGTO(TipoPagamento.Vista); regC100.setVL_MERC(8d); regC100.setIND_FRT(TipoFrete.SemCobrancaFrete); sped.getBlocoC().getRegistroC001().getRegistroC100().add(regC100); sped.saveFileTXT(); Observe o registro C100: |C100|1|0|12312312387|55|00|1|15|5140700593850000150550010000000151000001584|01082014|01082014|1,00|0|0,00|0,00|8,00|9|0,00|0,00|0,00|0,00|0,00|0,00|0,00|0,00|0,00|0,00|0,00|0,00| Att.

Bom dia. Havia um problema na obtenção do código nos enums. O SVN está atualizado com a modificação e atualize e verifique por favor. Att.,

Foi liberado no SVN um teste completo para o CliSiTef, disponível em: jACBrFramework\src\jACBrFramework\Test\ProgramTestTefCliSiTef.java. Os demais tipos de TEF ainda não foram implementados e não há uma previsão. Att.,

Bom dia. Os enums assumem valor diferente para o Sintegra e Sped. O erro do import foi corrigido e está no SVN. Obs.: Estas classes foram recentemente importadas e ainda não passaram por uma massa de testes considerável caso encontre mais situações desta natureza por favor nos informe para irmos ajustando. Att.,

O Interop é gerado com base no projeto em .NET, que também não tem os registros que você está precisando. O responsável irá implementar em C#, assim que for possível, e a partir daí será portado para Java.

Boa tarde.. Ainda não foram encapsulados para o jACBrFramework. Iremos mensurar os esforços para implementação e assim que possível iremos encapsulá-los. Att.,

Boa tarde Deno. O componente ACBrTEFD ainda não foi portado completamente para Java. Estamos realizando inicialmente a portabilidade do CliSitef, este erro que você encontrou já foi corrigido e será liberado nos próximos dias. Att., José Mauro

Ajustes enviados para o SVN. Att.,

CELL Corporação Tecnológic, obrigado pelo contribuição. Estes métodos serão ajustados e liberados amanhã no SVN. Obrigado.

Coloque quais você detectou para providenciarmos os ajustes necessários. Assim que colocar liberamos os ajustes. Att.,

Acabei de subir o ajuste. A leitura simplificada realmente apresentava o problema. Att.

Baixe os fontes do SVN e verifique se o problema persiste. Pelo que pude observar a versão dos fontes que estão no SVN, ao acionar as chamadas estão corretas, conforme abaixo: public void pafMF_LMFS_Impressao(Date DataInicial, Date DataFinal) throws ACBrException { int ret = ACBrECFInterop.INSTANCE.ECF_PafMF_LMFS_Impressao(getHandle(), OleDate.toOADate(DataInicial), OleDate.toOADate(DataFinal)); checkResult(ret); } public void pafMF_LMFS_Impressao(int CRZInicial, int CRZFinal) throws ACBrException { int ret = ACBrECFInterop.INSTANCE.ECF_PafMF_LMFS_Impressao_CRZ(getHandle(), CRZInicial, CRZFinal); checkResult(ret); }

Blza... Precisando post ai. Abraço.

Estas novas funcionalidades ainda não foram incluídas no projeto compilado. Será preciso baixar os fontes e compilá-los, verifique por favor na página: http://acbrframework.sourceforge.net/downloads/codigo-fonte/. Att.,

O valor deve ser calculado pela sua aplicação. Basicamente você precisa realizar o seguinte cálculo: Vlr. Aprox += Vlr. Liq. Prod. n * Perc. Aprox. Trib. n onde: Vlr. Aprox: será o valor calculado pela sua aplicação que será enviado ao jACBr; Vlr. Liq. Prod: valor líquido do produto vendido; Perc. Aprox. Trib: valor aproximado de tributos associado ao item vendido com base em alguma fonte, normalmente IBPT; n: refere-se aos produtos em questão. Desta forma o percentual aproximado de tributos deve ser um campo presente na sua estrutura de produtos e, após o cálculo, seu valor submetido ao jACBr. Att.

Boa tarde mascjunior, A classe Imposto.java está no pacote jACBrFramework.serial.ecf. Já o método getInfoRodapeCupom encontra-se disponível na classe ACBrECF. Verifique se você está com a última versão do jACBrFramework estas funcionalidades foram acrescidas no final do ano passado 28/12/2013. Você pode chamar o método para informar antes do método fecharCupom. Att.,