EMBarbosa

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?

Nota: Por algum motivo esse tópico foi criado no ACBrSAC, mas o usuário que o criou não tem permissão de acessá-lo. Eu até tinha fechado o outro mas ele me contatou para reabrir o tópico devido a não ter acesso ao ACBrSAC.

Sem saber de qual versão você partiu fica muito difícil de saber quais alterações aconteceram. Você pode utilizar o log do SVN e o arquivo ACBrNFePCN-change-log.txt para verificar as mudanças mais recentes no ACBrNFe2

Já foi corrigido pelo Isaque.

Eu procurei, mas não achei mais nenhum tópico sobre o assunto...

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.

Desculpe, não entendi.

Atualizar não vai adiantar. A ideia é justamente o contrário: voltar as versões até descobrir em qual funcionava do jeito que você quer.

Que bom! (:

A 8208 não alterou nenhum componente no trunk. A 8204 eu verifiquei alterou apenas código do MDFe. Visto que você fez o outro post dia 15, deve ser alguma outra, talvez anterior a 8178. Você lembra em qual revisão estava seu código antes de fazer a atualização e começar a ter problemas?

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

Olá hetoandrade, O pessoal está tentando verificar qual alteração fez isso, mas acho que não vai continuar assim. Se você puder e quiser ajudar, precisamos encontrar exatamente qual a revisão em que esse comportamento foi alterado.

Obrigado Isaque. Tive um problema aqui com minha máquina virtual e não tinha conseguido descobrir onde estava o erro. Agora já está corrigido.

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.

O arquivo que você anexou não tem nenhum erro do bloco K. Acho que está havendo algum problema diferente ou então estamos tendo algum problema na comunicação... Veja fiz alterações no programa de exemplo para eliminar os erros de datas e enviei para o SVN. Com essas alterações o arquivo está sendo importado e validado com sucesso como você pode ver na imagem abaixo.

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.

Acabei de subir ao SVN uma atualização para o exemplo que gera o bloco K. Posso confirmar que o bloco K não é gerado antes de 2016 e quando ele é gerado está na posição correta. Há algum problema na sua atualização ou nos arquivos que estão sendo utilizados. Tente efetuar uma limpeza no PC conforme explicado neste Depois disso utilize o Exemplo do ACBrSPEDFiscal para testar.

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.

Desculpe, não entendi qual o problema. Poderia tentar descrever mais detalhadamente? 1) o que fez? 2) o que esperava encontrar? 3) o que encontrou?