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.

Traduzindo a grosso modo, deve de conter itens na nota, no caso um serviço pelo menos! não é isso?

Deu certo, agora vou trabalhar com o zipmaster pra descompactar o retorno, se tiver algum progresso relato aqui no fórum, vai que ajuda né. Obrigado Darlana e Ítalo.

Prezados boa tarde! Sei que o componente é feito de Delphi, existe alguma forma de plugar o componente em Java? li uma parte dos post referente ao Download do XML rotina que me foi solicitada, e há neste momento... baixei e estou lendo a NT 2012/002 Robson

Está no componente ACBrNFeDANFEFR. Não sei se existe nos outros componentes Danfe. Só uso o FastReports para Relatórios.

Realmente, vacilo meu, analise demais os códigos e esqueci da propriedade . Obrigado amigo Juliomar.

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

Ola Ferdiand. Sabe que sempre procuramos as coisas mais difíceis e esquecemos as mais fáceis que estão a frente de nosso 'nariz'. Fiz isso e funcionou também. Grato

Darlana, Alguns conseguiram realizar a consulta, informando "1" como sendo o terceiro parâmetro. Você tentou nos dois ambientes: Homologação e Produção? Após a consulta, a TAG ultNSU que consta no retorno retornou um numero diferente de zero?

Segue em anexo alterações que fiz no componente para integração com o municipio de Campo Bom / RS. sds, Leandro do Couto KoutoSoft Sistemas Novo Hamburgo / RS Acbr Campo Bom.zip

A DLL de qualquer SAT, deve seguir a especificação definida nas leis do SAT... (Muito bom que a especificação do SAT também definiu o padrão da DLL) Ou seja, todos os fabricantes devem fazer uma DLL idêntica, com os mesmos métodos... e o componente ACBrSAT sabe como falar com ela... O que os fabricantes oferecem de facilidade, são métodos na DLL para facilitar a criação do XML do SAT, impressão do Extrato com QRCode, e outras tarefas... ou seja, coisas que acredito que o ACBrSAT seja capaz de fazer...

Segue a resposta da SEFAZ. ----- Resposta da Mensagem 6490486 Bom dia, Não existe ainda na NF-e, campo para referenciar Cupom Fiscal Eletrônico. Nestes casos, recomendamos, por enquanto, referenciar no campo de informações adicionais. Atenciosamente, Secretaria da Fazenda do Estado de São Paulo Mensagem Original: Referenciar CF-e dentro de uma NF-e Resposta anterior [6488877] A regra para os contribuintes jurídicos que querem reaver os créditos ICMS de compras que houveram sido emitidas em Cupom Fiscal é solicitar à empresa que vendeu o produto uma NF-e com o CFOP 5929 (Operações efetuadas também em emissor de cupom fiscal). Dentro dessa NF-e, existe um local especifico para indicar quais foram os cupons fiscais que estão sendo referenciados. Com a mudança para o SAT, como devemos fazer essa emissão de NFe? Uma vez que o CF-e, assim como o Cupom Fiscal, também não gera direitos a créditos ICMS e não existe local especifico na NF-e para referenciar o CF-e? NÃO RESPONDA ESTE E-MAIL Para fazer uma nova pergunta, clique aqui. ------ Espero ter contribuído. Abraços

Bom dia pessoal! Fazendo uma correção, o meu cliente é do Rio Grande do Sul, ele adquiriu o certificado nos correios e o certificado é ACS, com o nome de ACOS5, é um Token. Site do Certificado ( http://www.acs.com.hk/en/products/18/cryptomate64-cryptographic-usb-tokens/). Como falei a cima a tela para informar o PIN é diferente, segue a imagem: . Passei o ACBrNFe_Demo pra la, troquei de maquina, entrei em contato com o pessoal da Invia ( http://invia.com.br/) que da suporte a este certificado digital para a instalação do mesmo, após a instalação, abri o Demo do ACBr NF-e e tentei verificar o status do serviço, diretamente ele ja me traz o mesmo erro: Lembrando que pelo sistema do governo envia nota fiscal eletronica normalmente. Fico no aguardo. Obrigado!

Bom dia Pessoal.... Estou vindo aqui para compartilhar uma experiência com vocês do mesmo problema. Dércio, passei por um problema que colocou na mesma dúvida que você. Realizando testes em homologação e simulando erros, emiti uma NFC-e em contingência e 30 minutos depois eu enviei de fato essa NFC-e para SEFAZ e me retornou o Status 150. Eis que entrei em contato com a SEFAZ RS e obtive a seguinte resposta: "01. NF-e emitida em contingência: As NF-e emitidas em situação normal tem o prazo de 30 dias a partir da data de emissão para serem transmitidas para a SEFAZ. No caso de autorização em contingência (tpEmis = 2, 4 ou 5), a NF-e deve ser transmitidas para a SEFAZ assim que cessarem os problemas. Para situações em que a data de emissão da NF-e emitida em contingência for maior do que 30 dias, foi criado o cStat=150 - Autorizado o uso da NF-e, autorização concedida fora de prazo, conforme definido na NT 2012/003 02. NFC-e emitida em contingência Para NFC-e emitida em contingência a regra utilizada é a mesma. O prazo de autorização da NFC-e normal é de 5 minutos, porém é possível autorizar NFC-e fora deste prazo desde que tenha sito emitida em contingência offline (tpEmis=9). A NFC-e abaixo foi enviada 30 minutos após a data de emissão. Por este motivo foi autorizada fora de prazo. Para ambos os casos não existe prazo de autorização para documentos emitidos em contingência. Laura Soares Equipe da NF-e Receita Estadual - RS"

Boa tarde Juliomar, acabei de resolver o problema, vou deixar aqui postado como consegui resolver para aqueles que se depararem novamente com este mesmo problema que eu perdi 2 dias para achar o mesmo rsrs. 1) Apagar todas as referencias do acbr com o apagarAcbr.bat 2) Excluir e baixar novamente do repositório 3) Instalar manualmente os pacotes dos componentes de acordo com as orientações do LEIA-ME.TXT 4) No meu casos para Relatórios do Fortes Report precisei substituir nos pacotes caso precise RLibWinDXE7.bpl pela atual FortesReportCE_Win32_DXE7_vcl.bpl 5) Alguns pacotes que não reconhecem as uses Forms. Graphics... principalmente os de relatorios.... então fiz o seguinte clique botão direito em cima do projeto e vá em ->Options..->Delphi Compiler->Unit scope names e adicione a palavra VCL; em um pacote que usa a uses jpeg necessitei adicionar também a palavra Vcl.Images Feito isto consegui instalar os componentes perfeitamente. Juliomar não mexi em nenhum path do delphi, para desencargo de duvida, até desinstalei e instalei novamente o delphi e os componentes e persistiu o problema. Agradeço pela atenção Juliomar, não sei se é problema com o delphi ou se esta faltando em alguns pacotes estes detalhes, mas espero ter ajudado. abs

É o mesmo cálculo de antes, mas agora separado por esfera (Federal, Estadual, Municipal).

Pessoal, segue anexo alterações efetuadas no DANFe Fortes Report das NFCe um impresso antes de alterar e outro após a alteração. Se possível disponibilizarem no SVN.

EURECAAAAAA !! A SEFAZ RESPONDEU !!! kakkakaka Veja resposta deles: Não existe uma regra de validação que rejeite a NFC-e emitida depois do prazo legal. Porém, a empresa corre o risco de autuação caso emita tais notas depois das 24 horas previstas na lei. Laura Soares Equipe da NF-e Receita Estadual - RS ou seja, Não vamos bloquear, mas vamos multar .... kakakakakakkakaka