Painel de líderes

Estamos fazendo modificações nos componentes SPED que podem resultar em necessidade de corrigirem seu código. Por isso estamos avisando com antecedência para você poder estar pronto. As alterações estão previstas para ir para o SVN na primeira quinzena de Janeiro de 2015 já estão no SVN. Há algum tempo temos um bug em certos registros do SPED que não puderam ser resolvidos. O problema é devido a alguns campos que precisam ser gerados com valores numéricos incluindo '0' (zero), mas também precisam aceitar o valor vazio ( e mais ). O componente não consegue atualmente tratar esses casos de forma satisfatória e as alterações são para corrigir isso. Infelizmente, estas alterações podem quebrar a compatibilidade do seu código atual. "Não!!! Não façam isso com meu código!!!" - disse o programador preguiçoso. Em primeiro lugar não é seu código. É nosso! Além disso, como dito acima, também não estamos tão felizes assim. Mas ou fazemos a alteração, ou não vamos atender a necessidade de todos nem a legislação atual. Preferimos qualidade e confiabilidade. "Mas o que vai mudar?" - disse o programador curioso. Resumindo a alteração: Estamos modificando o tipo destes campos para Variant ao invés de um tipo numérico (Currency, Double, extended, etc...). Assim, quando você precisar gerar um valor vazio no campo, bastará passar Null (variant nula) para o campo. Se quiser que seja gerado com '0' (zero), bastará passar zero para o campo. Sim, isso já foi e não é um dejavu. Alguns registros já funcionam assim, como por exemplo os Registros C181 e C185. "Nenhuma chance de eu não precisar fazer nada?" - disse o programador esperançoso. Se você não utilizar os registros mencionados você não vai precisar fazer nada. A lista dos registros estão no deste tópico. "E se eu não quiser mexer com isso agora?" - disse o programador apertado com os prazos. Bom, você pode ficar sem atualizar seus componentes SPED. Mas que fique claro que não recomendamos isso e que você talvez não consiga gerar os arquivos 100%. Daí você talvez pense: "Ok, eu quero resolver isso. Mas queria saber onde eu posso ter problemas, e o que fazer para corrigi-los." Achei que não ia perguntar. O caso é que os componentes não vão mais tentar adivinhar se o campo ficará vazio ou não vazio quando o valor dele for zero. Você é quem deverá definir isso. Logo, se você está sempre confiando que quando passar zero o componente vai tornar os campos vazios por você, então você pode ter problemas nestes casos. Veja um exemplo: Na EFD Contribuições (SPED PIS/COFINS), quando você gera registros C191, existem os campos VL_BC_PIS, ALIQ_PIS, QUANT_BC_PIS e ALIQ_PIS_QUANT. Normalmente, você vai preencher os dois primeiros. Ao preencher os dois primeiros você deve fazer com que os campos QUANT_BC_PIS e ALIQ_PIS_QUANT fiquem vazios. O código atual talvez seja assim: RegistroC181.VL_BC_PIS := 100; RegistroC181.ALIQ_PIS := 1.65; RegistroC181.QUANT_BC_PIS := 0; RegistroC181.ALIQ_PIS_QUANT := 0; Você vai ter que alterar para: RegistroC181.VL_BC_PIS := 100; RegistroC181.ALIQ_PIS := 1.65; RegistroC181.QUANT_BC_PIS := Null; RegistroC181.ALIQ_PIS_QUANT := Null; Mas talvez, você seja um dos que desenvolvem software para fabricantes ou importadores de combustíveis e de bebidas frias (água, cerveja, refrigerantes) que tenham optado por apurar as contribuições sociais com base na quantidade de produto vendida. Neste caso, você vai querer preencher os campos posteriores e deixar os dois primeiros vazios. Algo assim: RegistroC181.VL_BC_PIS := Null; RegistroC181.ALIQ_PIS := Null; RegistroC181.QUANT_BC_PIS := 10; RegistroC181.ALIQ_PIS_QUANT := 0.1; Isso foi apenas um exemplo. Mas, via de regra, o que você de prestar atenção é: O código gerava vazio pra você e você quer que continue assim? Então atribua Null. "Mas e os eventos? Não tinha alguns eventos para resolver esse problema?" Hmmm!!! Temos um espertinho aqui! O problema dos registros com eventos (C481, C485, C491, C495), é que o evento é gerado na hora de escrever o arquivo e não na hora de alimentar o componente. Por isso, você já não tem acesso ao banco de dados. Assim, pode ser preciso consultar novamente ao banco de dados para decidir quais campos vão ser preenchidos ou deixados vazios. Isso pode ser um problema muito grande e até insustentável dependendo do tamanho do seu banco de dados e do período gerado. Fora que são mais conexões desnecessárias ao BD. Assim, os eventos estão sendo considerados obsoletos (deprecated). Mais cedo ou mais tarde eles serão removidos. Para evitar maiores problemas, o código dos eventos a princípio vão continuar funcionando. Quer dizer que, se você está utilizando os eventos e eles estão lhe atendendo, você pode decidir não mexer nessa parte do código. Mas incentivamos você a remover os eventos e fazer os tratamentos conforme acima sugerido para os outros registros assim que as alterações forem postadas no SVN. Veja abaixo onde as modificações estão sendo feitas primeiro e analise ali se seu código precisa ser modificado. Apenas atente que isso é apenas os primeiros lugares onde vão acontecer as modificações. Mais lugares vão ser alterados sempre que percebemos que o código atual não pode atender a necessidade e legislação que afeta todos os nossos usuários. Vamos tentar manter a lista abaixo atualizada.

Obrigado Italo, e desculpe Juliomar, eu fiz uma busca sobre este assunto no forum, e não encontrei nada que me desse uma resposta aceitavel.

Bom dia a todos, A nova URL de Recepção de Eventos da SEFAZ-GO já esta atualizada a um bom tempo. Favor atualizar os fontes e compilar a aplicação com a opção Build.

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 Senhores. Neste fim/início de ano, tive que implementar em nosso sistema a Nota Fiscal de Serviços para São Paulo. Com base nos fontes que o Ariel havia passado, realizei testes e ajustes para o pleno funcionamento da integração com São Paulo. A assinatura de São Paulo, continua sendo feita pela DLL desenvolvida pelo Ariel. Conforme já comentado em outros posts, para funcionamento da dll, basta que ela e o arquivo TLB estejam na mesma pasta do executável e na pasta system32 e o seguinte comando seja executado: (Acessar a pasta da versão 2.0 do .NET Framework, "C:\Windows\Microsoft.NET\Framework\v2.0.50727" por exemplo) regasm C:\Windows\SysWOW64\AcbrAssinaRPSSP.dll /tlb:AcbrAssinaRPSSP.tlb As seguintes funções estão funcionando plenamente: Geração de RPS, Envio de Lote RPS, Consulta de Situação Lote, Consulta de Lote, Cancelamento de NFSe e Impressão de NFSe. Todas as funções acima foram testadas em ambiente de produção, tendo a emissão, consulta e cancelamento de mais de 10 notas fiscais. Todos os testes foram feitos com o envio de apenas 1 NF por lote. Estou enviando em anexo todos os fontes envolvidos, sendo que todos já estão na última versão do Trunk do ACBr. Para facilitar a visualização das alterações, em todos os locais alterados existe o comentário {add-SP}. Portanto, seria possível já incorporar ao ACBr, ou é necessário mais algum teste ou modificação? Qualquer dúvida, estou à disposição. Atenciosamente. Roger Rodrigues Fontes_SP.zip

O ACBrECFVirtualNFCeQuandoFecharDocumento é executado antes de enviar, provavelmente precisaremos de mais eventos. Mas vc pode tentar depois de chamar o ACBrECF1.FechaCupom( Obs ); usar o seguinte objeto: ACBrECFVirtualNFCe1.ACBrNFCe.NotasFiscais.Items[0].NFe; Bastaria trocar o "with NFe do" do seu código por "with ACBrECFVirtualNFCe1.ACBrNFCe.NotasFiscais.Items[0].NFe do" mas não tenho certeza se irá funcionar.

Bom dia a todos, Dentro de alguns minutos vou estar disponibilizando os fontes do componente ACBrNFe com as alterações necessárias para suportar a nova versão 3.10 da NF-e e NFC-e. A liberação do ambiente de homologação ocorreu no dia 02/12/2013 para ambos os modelos de documentos fiscais. Quanto ao de produção esta previsto a liberação para o dia 06/01/2014 ( NFC-e ) e 10/03/2014 ( NF-e ). A versão 2.00 da NF-e vai ser aceita até 01/12/2014, data também prevista para o término da versão 3.00 da NFC-e. Para deixar o componente configuravel a nivel de execução foi acrescentado uma nova propriedade chamada: VersaoDF = Versão do Documento Fiscal. Dica de configuração para que o componente gere o XML no modelo e versão correta: ACBrNFe.Configuracoes.Geral.ModeloDF := moNFe; ACBrNFe.Configuracoes.Geral.VersaoDF := ve200; No exemplo acima o XML a ser gerado vai ser o da NF-e na versão 2.00 Valores aceitos pela propriedade ModeloDF: moNFe e moNFCe. Quando o modelo for moNFe, os valores aceitos pela propriedade VersaoDF são: ve200 e ve310. Quando o modelo for moNFCe, os valores aceitos pela propriedade VersaoDF são: ve300 e ve310. Como o componente esta ganhando uma nova propriedade, se faz necessário a compilação do pacote de instalação do mesmo ou a sua reinstalação com o ACBrInstall, caso contrario essa nova propriedade não vai aparecer no Object Inspector. Favor reportar erros e problemas.