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); }

Pessoal bom dia. O erro estava na minha chamada ao informar o código do País, ajustando foi enviado corretamente. Acredito que não seja um cenário recorrente, e provavelmente, não vai voltar a acontecer com outro, mas vale o registro. Talvez seja o caso de validar a tabela de País assim como ocorre com a tabela de municípios. Obrigado pela atenção. José Mauro.

Pessoal boa tarde. Estou desenvolvendo um projeto e utilizando o ACBrNFeMonitor e a comunicação está ocorrendo da forma correta. No entanto, ao enviar o comando NFe.CriarNFe, com seus devidos parâmetros, o CNPJ do emitente e o CNPJ/CPF do destinatário não vão para o XML submetido a receita. Além disso estou observando que alguns valores enviados na identificação do destinatário e emitente estão ficando com valores diferentes no XML. O envio está sendo feito para o ambiente de homologação da receita do estado de SP. Em anexo o XML enviado e o arquivo de log. Alguém já passou por isso para me indicar onde pode estar meu erro? Desde já obrigado. José Mauro. log-chamada.txt nfe-xml.xml

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