Painel de líderes

Igor, Estou chegando a uma conclusão que o grupo <ICMSUFDest> deve ser gerado mediante as condições impostas pela regra NA01-20 (NT 2015/003 versão 1.50 - página 13). Se os campos desse grupo não forem alimentados todos eles serão gerados com o valor zero, e desta forma a nota poderá ser rejeitada pelo fato da informação esta errada e não pela ausência do grupo. Desta forma caberá ao desenvolvedor a alimentar corretamente cada um desses campos dependendo do produto ser ou não isento.

Bom dia Michel, Esse "aval contábil" é que está difícil. Não há nenhuma instrução oficial por parte da RFB ou dos SEFAZ orientando o envio da tag ICMSUFDest nos produtos isentos; no entanto, a NF-e não consegue ser emitida sem a TAG. Eu tenho um cliente que entrou em conferência com contadores de três estados diferentes (ES, DF e GO) mais um grupo de trabalho de um curso sobre a EC 87 e após horas de analíse e confabulação, a decisão deles é que os campos da partilha devem ser enviados zerados, apenas com a alíquota de ICMS interestadual e o percentual de partilha preenchidos, que são os campos obrigatorios. Eu modifiquei a unit pcnNFeW.pas para que o teste da obrigatoriedade da tag seja feito pela alíquota interestadual e não pela base de cálculo da UF de destino, assim não tenho que preenchê-la como o Igor Moura fez. não vou sugerir que esta mudança seja incorporada permanentemente nos fontes do ACBr até porque não há nenhuma atualização da NT que regulamente esta opção, mas até que saia, vou ter de sempre manter minha modificação aplicada.

Bom dia a todos recentemente os clientes da empresa em qual trabalho vem recebido emails falsos de cobrança com boletos falsos, porem contendo informações verdadeiras.. como a compra realmente existir, dados cadastrais do destinatário e do remente vencimento e valor, apos muita investigação cheguei a seguinte conclusão: Estão usando portal da nfe, os hackers consultam chaves aleatoriamente no portal da nfe, e como exige apenas um captcha eles tem acesso as informações da empresam, do cliente e do financeiro usando apenas um parser de html simples ( como muitos usam para "baixar" o dito xml do portal se o uso do certificado digital) e como no portal é exibido também o e-mail do destinatário fica de prato cheio a eles. Isso descobri após uma analise das informações enviadas no boleto falso estão exatamente iguais as informações que registro na nfe que tem alguns detalhes diferentes de quanto eu envio o boleto real ao meu cliente. Como medida de segurança parei de enviar o e-mail do cliente em meus xmls, desta forma ao consultar a informação no portal do nfe ele nao tem como enviar ao cliente

tens de consultar a lei a que se refere a fcp para mais detalhes, ou melhor ainda, consultar o contador pois cabe a ele a leitura da legislação

atenção que essa grelha somente serve como guia de orientação, isto porque o fcp é definido por estado e, se assim determinado, somente para alguns produtos (normalmente os supérfluos ou de luxo), sendo que na NFe somente é atribuído o máximo de 2% (alguns estado têm % superior). Nós criamos isso como regra configurável, cabendo ao cliente indicar o valor e quais os produtos/estados onde vai vender.

Obrigado! Gente conseguir resolver, o local de emissão estava errado.

Obrigado, já enviei para o SVN...

Juliana, Muito obrigado pela atenção!

Na pasta tem os arquivos ACBrMonitor.chm e ACBrMonitor.pdf.

Regys bom dia. Obrigado pela resposta. Consegui resolver o problema com ajuda do Sérgio Assunção, estava faltando setar dois eventos no exemplo do ACBRSat procedure TForm1.ACBrSAT1GetcodigoDeAtivacao(var Chave: AnsiString); begin Chave := edtCodigoAtivacao.Text; end; procedure TForm1.ACBrSAT1GetsignAC(var Chave: string); begin Chave := edtSwHAssinatura.Text; end;

Bom dia, disponível no SVN.

relativamente a tabela c parece que foi revogada

em todo caso... subi uma nova versão do MonitorPLUS, compilado com as correções do Fortes REport, e Lazarus 1.4.4

Notei que a impressão sempre exigirá um "Servidor X", pois os geradores de Relatório do Fortes e Lazarus tem forte vinculo com as classes visuais do Lazarus / FPC O MonitorConsole não está compilando... será necessário fazer um grande refactoring nele, para compatibilizá-lo com o ACBrMonitorPLUS... E muito provavelmente, não haverá nele, suporte a Impressão de Boletos usando Geradores de relatórios... Essa tarefa (compatibilizar o MonitorConsole com o MonitorPLUS) é muito mais complexa, e deve levar alguns meses para ser concluída...

Consegui corrigir os problemas de impressão e geração de PDF, do Fortes Report CE com o Linux... Já fiz um PullRequest para o projeto Fortes CE... Vou tentar compilar uma nova versão em breve...

Sim, eu que fiz, mas é só um "baka" pra quebra galho e documentação, em anexo. DIFAL.zip

Bom dia pessoal! Ontem, 17/12/2015 assisti a um curso via web ministrado por uma advogada tributária oferecido pela IOB. Dentre muitas dúvidas sanadas, a questão do calculo foi confirmado por ela de acordo com as mais novas publicações da legislação (inclusive a do dia 15). Gostaria de compartilhar com vocês o entendimento dela referente a forma de calculo do grupo de ICMS e partilha. Achei muito coerente e serão as fórmulas que aplicarei no meu sistema. Só reforçando que agora trabalhamos com base única e que a nota técnica que foi publicada ontem (versão 1.50) foi removida aquele cálculo que utilizava base dupla (acho que perceberam que realmente não fazia sentido). Pois bem, eis o exemplo citado por ela. -Lembrando que é válido exclusivamente para as seguintes opções na NF-e: Operação interestadual Destinatário não contribuinte e consumidor final Que não seja devolução Mercadoria(sem Icms) R$ 1.000,00 Alíquota Interestadual 7% Alíquota Interna UF de Destino 17% Fundo de Combate a Pobreza 2% Base de Cálculo = (Valor Mercadoria/(100 - (Aliquota Interestadual + Alíquota Fundo Pobreza)) Base de Cálculo = (R$ 1.000.00 / (100 - 19%)) Base de Cálculo = R$ 1.000.00 / 81% Base de Cálculo = R$ 1.000.00 / 0,81 Base de Cálculo = R$ 1.234,56 Icms Origem = (Base de Cálculo x Alíquota Interestadual) Icms Origem = (R$ 1.234,56 x 7%) Icms Origem = R$ 86,41 Icms Destino = (Base Cálculo x Alíquota Interna UF Destino [Sem Fundo Pobreza] ) Icms Destino = R$ 1.234,56 x 17% Icms Destino = R$ 209,87 Fundo Pobreza = Base de Cálculo x Alíquota Fundo Pobreza Fundo Pobreza = (R$ 1.234,56 x 2%) Fundo Pobreza = R$ 24,69 Partilha UF Origem = 60% Partilha UF Destino = 40% Valor a Partilhar (DIFAL) = ICMS Destino - ICMS Origem Valor a Partilhar (DIFAL) = R$ 209,87 - R$ 86,41 Valor a Partilhar (DIFAL) = R$ 123,46 Valor Icms p/ UF Origem = DIFAL x 60% Valor Icms p/ UF Origem = R$ 123,46 x 60% Valor Icms p/ UF Origem = R$ 74,07 Valor Icms p/ UF Destino = DIFAL x 40% Valor Icms p/ UF Destino = R$ 123,46 x 40% Valor Icms p/ UF Destino = R$ 49,38 Espero que ajude.

Bom dia Marcio, Ontem em casa fiz um teste com o provedor Betha que também existe tanto RPS quanto Lote assinados e o resultado foi positivo. Como foi necessário fazer alterações nas classes do ACBrDFe, estou aguardando uma aprovação da equipe ACBr para estar liberando os fontes alterados.

Veja que na tag "tpImp" você está passando DANFE normal (1), conforme nota técnica (NT2013.005) para a NFC-e deve-se utilizar tipo de impressão 4 ou 5, caso contrário o erro 709 ocorrerá. Provavelmente você não está informando esta tag ao ACBrNFeMonitor e ele então assume o default 1.

Bom dia Daniel, obrigado pelo retorno. Estamos utilizando o TEF dedicado. Não confirmamos nenhuma transação manualmente, o ACBrTEFD faz corretamente o processo como você disse. A dúvida, não sei se é um erro no framework, é a seguinte: "Por exemplo, uma venda é realizada em cima do COO 00001, o cliente paga com dois cartões (qualquer valor desde que pague toda a venda) e estas vendas ainda não foram confirmadas no SiTef pela biblioteca, conforme você mencionou. Sendo assim temos N transações autorizadas para uma venda, N:1, até aqui é o processo padrão sem nenhum problema. Porém, antes de finalizar o cupom fiscal, i.e., ainda não foi confirmada nenhuma autorização, o cliente resolve desistir de pagar com um dos cartões, mesmo tendo sido autorizado pelo TEF. Para este caso acionamos explicitamente o NCN para cancelar a autorização informando rede, nsu, valor, data/hora transação e finalização, os campos da assinatura do método. Ao acionar, a transação autorizada muda no SiTef para CANC. PDV perfeitamente, mas não são da lista de transações pendentes do ACBrTEFD pois quando mandamos imprimir as transações pendentes a transação que enviamos NCN sai impressa no cupom vinculado. Neste ponto que ficou a dúvida, se a transação autorizada foi "descontinuada" junto ao SiTef, seria correto imprimi-la no cupom vinculado?" Obrigado novamente. José Mauro

Parabéns por disponibilizar sua solução para que os demais colegas possam ler e ajudar a eles!