EMBarbosa

Seria bom se tivesse informado isso logo a princípio... É o mesmo modelo de ECF? Mesmo computador? Utilizando a mesma porta USB? Criando a mesma porta serial?

Duas opções: Uma contate a bematech e pergunte como fazer comunicação direta com a impressora. Eles tem um driver, mas não sei se funciona com essa impressora. Outra compre uma placa serial tipo pci.

E, Independente disso, não há no log erros de comunicação conforme foi dito no post original.

Não vi erros de comunicação no trecho que você anexou. Mas notei a chamada a CarregaAliquotas e CarregaFormasPagamento que resultam em erros. Você está utilizando os métodos CarregaAliquotas e CarregaFormasPagamento sempre durante a abertura e fechamento dos cupons? Não seria melhor fazer isso apenas uma vez ao abrir o programa?

Já foi corrigido pelo Isaque.

O arquivo na sua terceira imagem não é nem o que eu anexei nem o que é gerado pelo exemplo atualmente, isso me deixou confuso. Não sei ao certo se entendi sua dúvida, mas a obrigação é só pra 2016. Sendo assim, se o validador está recusando então não deve ser gerado. Pelo menos até que chegue uma versão do validador que aceite. No entanto, se o componente ou o exemplo do ACBrSPEDFiscal está gerando o bloco K no mês de janeiro de 2015, você está com seu código fonte desatualizado.

Que bom! (:

Não use o Retentar := True; Use um flag e um loop como o repeat ou o while.

Aqui validou corretamente. ACBrSpedFiscal.txt

Não veio nenhum anexo. Mas o arquivo gerado pelo exemplo está sendo validado normalmente pelo PVA 2.1.1. Esta versão do PVA é que deve ser utilizada a partir do dia 20/01/2015.

Na verdade já foi corrigido no componente, tanto a ordenação como a geração. Hoje eu enviei ao SVN uma atualização para o exemplo do ACBrSPEDFiscal que demonstra a geração do bloco K e não detectei nenhum problema.

Tente fazer uma

Quis dizer fazer o que está no post que eu mandei o link.

Fiz uma pequena pesquisa sobre o assunto, e parece que o mais aceito é que: O nome do teste deve: ser curto, mas descritivo o suficiente para identificá-lo mesmo por quem não está acostumado com os testes; descrever, se possível, a ação, o estado do objeto testado e o objetivo do teste; descrever o resultado esperado; Isso basicamente é conseguido seguindo o padrão: [unidadeDeTrabalho_EstadoSendoTestado_ResultadoEsperado] Neste caso, unidade de trabalho pode ser um método, classe ou várias classes. Mas representa o que está sendo testado neste teste específico. No entanto, deve-se tomar cuidado ao incluir o nome do método no teste caso exista alguma possibilidade de este método ser renomeado depois. Estado sendo testado descreve as condições do teste ou ação. Isso sugere nomes como: WEBServer_LoginComSenhaVazia_DeveFalhar WEBServer_LoginComUsuarioVazio_DeveFalhar WEBServer_LoginComSenhaeUsuarioVazios_DeveFalhar Soma_NumeroNegativoNo1oParametro_GeraException Soma_ValoresSimples_SaoCalculados As classes de teste podem ser nomeadas com o nome da classe e o sufixo Testes (ou Tests) por exemplo: [NomeDaClasseTestes] Se todos concordarem, podemos definir esse padrão. O que acham? Algumas das fontes que eu consultei: https://stackoverflow.com/questions/155436/unit-test-naming-best-practices http://osherove.com/blog/2005/4/3/naming-standards-for-unit-tests.html http://testing.bredex.de/naming-conventions-for-test-cases.html https://code.google.com/p/robotframework/wiki/HowToWriteGoodTestCases#Test_case_names http://sysgears.com/articles/the-art-of-writing-effective-and-transparent-test-cases/

Boa tarde Ricardo. Mais uma vez muito obrigado pelas contribuições. Já está disponível no SVN.

Tente fazer uma

Se é realmente assim, uma opção seria você verificar exatamente em qual versão parou de funcionar. Essa informação serviria para tentar uma alternativa.

Modificações para o SPED PIS/COFINS foram enviadas ao SVN.

Os problemas apresentados nos métodos StringToFloat e StringToFloatDef são na verdade de comparação. Parecidos com o que foi levantado antes nos métodos DFill e LFill. Fiz uma alteração no teste StringToFloatDefTest.Normal para poder mostrar isso. Dê uma olhada. EDIT: Revisão 8169. Também modifiquei ara adicionar a vírgula na string visto que este método serve exatamente para isso. (: Outra coisa, o método StrIsAlpha não considera acentos como sendo Alpha. Se verificar o código vai perceber. Então acho que basta modificar o teste StrIsAlphaTest.TextoComCaractersAcentuados para CheckFalse.

Visto que funciona em algumas máquinas e não em outras e o erro não é descritivo, estamos sem saber ao certo onde é o problema...

Vou subir as adições. Vi que você mudou os nomes de alguns testes. Você acha que assim fica mais claro? Pessoalmente, eu preferia o jeito anterior. EDIT: Já foi pro SVN.

O Juliomar já corrigiu. Os arquivos haviam sido renomeados.

Espertinhos eles. Não tinha me ocorrido isso...

São coisas distintas. ECF é Emissor de Cupom Fiscal. O ECF pode ser do tipo ECF-IF, ou seja uma Impressora Fiscal. Aqui no fórum e em quase toda documentação, quando você ler ECF deve entender Impressora Fiscal (ECF-IF). Já a impressora não fiscal é, como o nome diz, diferente. Não entendi essa pergunta. Mas veja bem, a obrigatoriedade da impressão do imposto é no documento fiscal (Nota Fiscal, NF-e, Cupom Fiscal, CF-e, NFC-e, etc...). Qualquer coisa fora disso sai do propósito da legislação inicial. EDIT: Moderação: Desmarquei o tópico como resolvido, pois "obrigado" não é um post que traz solução ao tópico. Você deve marcar a resposta que lhe ajudou a resolver sua dúvida.