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.

Primeiramente, não entendo por que o DownloadNFe está te retornando algo zipado. Eu consigo baixar o XML da nota normalmente, como sempre. Quanto à sua outra pergunta, o fluxo exemplificado da NT, na página 11, item 8, diz: "O destinatário consulta o WS NFeDistribuicaoDFe a partir do último NSU recebido e recupera a NF-e"; Não te garanto que isso esteja funcionando agora. Optei por continuar usando o DownloadNFE por garantia, por enquanto. Mas minha conclusão é de que o novo WS é que será responsável por essa tarefa agora. ___ Não havia lido a resposta do Tiago Ravache antes. Desculpa.

Bom dia a todos, Exatamente Tiago, todo arquivo XML ou fragmento de código devem ser inseridos nas postagem como anexo e não como parte do texto. Fabricio, no programa exemplo se não me falha a memória existe um botão exemplificado como fazer a manifestação do destinatário. Caso não tenha, por favor pesquise aqui no fórum que você vai encontrar dezenas de dicas como fazer. Lembre-se que a manifestação do destinatário nada mais é do que um evento, como por exemplo o cancelamento.

Guilherme, é isso mesmo, Italo ja ate confirmou para você. Agora, Pessoal, Vai justificar o DFe retornar notas canceladas? Não fiz tratamento nenhum disso? É necessário manifestar nota cancelada? Estranho isso, pois o emissor pode ter cancelado a nota por inumeros fatores, o qual o destinatário não tem porque tomar ciencia disso, desconhecer e muito menos confirmar o cancelamento. Aguardo. Darlana Nogueira

é exatamente isto que está acontecendo comigo. FAzendo o loop certo, de repente vem o consumo indevido. Porém, eu não notei se eu recebi o lote seguinte conforme tu comentou. vou verificar isso e te respondo. Mas é bem estranho. Quanto ao seu post anterior, você está certo. No layout consta que a nota vira como Autorizada ou Denegada. Me parece que o cancelamento virá com um outro NSU, como um evento...

Bom dia guilherme, Exatamente, inicialmente o destinatário recebe o resumo da NF-e e caso esta NF-e possua eventos vinculados a ela, como por exemplo cancelamento Carta de Correção e até a emissão de CT-e e MDF-e (quando a carga vai ser transportada por uma transportadora) essa informação será apresentada ao destinatário através de um resumo de evento.

Ítalo e Luan, Consegui descobri o motivo! Não estava preenchendo o ReqResp.URL'https://bhisshomologa.pbh.gov.br/bhiss-ws/nfse' responsável para BH! Eu comentei e assim ficou! Ptuz!!! Falta de atenção a minha! a URL 'http://ws.bhiss.pbh.gov.br/CancelarNfse' estava correta. A questão é se você não informa qual o servidor responsável pelo serviço, não há como executar o serviço solicitado, no caso a URL 'http://ws.bhiss.pbh.gov.br/CancelarNfse'. Fica meu agradecimento pela atenção de vocês!

A sugestão é boa... e pode ser aplicada... Já havia pensado nisso, mas penso em dividir as palletas por Package (ACBrSerial, ACBrTCP, ACBrDFe, ACBrTXT, etc) Estou promovendo um amplo Refactoring e reorganização de todas as pastas... (com a ajuda e cooperação de toda a equipe) https://svn.code.sf.net/p/acbr/code/branches/Daniel/

Boa tarde todos, Encontra-se disponível no repositório o Manual do ACBrCTe, mais precisamente na pasta: ...\Doctos\Manuais. Este manual é destinado aos desenvolvedores Delphi que se utilizam do componente ACBrCTe. Ele traz uma tabela contendo as propriedades de configuração do componente, bem como os métodos de cada funcionalidade. Acredito que ainda falta algumas coisas, mas com a colaboração de todos vamos acrescentando para que ele se torne o mais completo possível. Obs: encontra-se também disponível no fórum na seção Downloads.

Lista de campos e registros alterados: SPED PIS/COFINS (EFD Contribuições). Nota: substitua abaixo o asterisco * por PIS ou COFINS conforme o registro. Registros C191 e C195 campos VL_DESC, VL_BC_*, ALIQ_*, QUANT_BC_*, ALIQ_*_QUANT, VL_* Registros C381 e C385 campos VL_BC_*, ALIQ_*, QUANT_BC_*, ALIQ_*_QUANT, VL_* Registros C481 e C485 campos VL_BC_*, ALIQ_*, QUANT_BC_*, ALIQ_*_QUANT, VL_* Registros C491 e C495 campos VL_BC_*, ALIQ_*, QUANT_BC_*, ALIQ_*_QUANT, VL_* Registros D350 campos VL_BC_*, ALIQ_*, QUANT_BC_*, ALIQ_*_QUANT, VL_* Vários campos dos Registros M100, M105, M210, M500, M505, M610 Registro C170 campos ALIQ_*_PERC, QUANT_BC_*, ALIQ_*_R, VL_* SPED Fiscal (EFD ICMS/IPI) Ainda em análise Ainda em análise