Painel de líderes

Obrigado!

Boa tarde! Fiquei muito feliz de encontrar esse projeto que me ajudou muito na implementação da NFC-e em um sistema então gostaria de colaborar de alguma forma. Eu trabalho com a linguagem de programação C# e fiz uma classe que faz toda a comunicação com o ACBrMonitor, não vi nada parecido na minha rápida passagem pelo fórum, então espero poder ajudar quem esteja precisando desse suporte nessa linguagem. Achei mais simples fazer dessa forma pois o monitor já é um projeto bem completo. Então basta integrar a classe no projeto em C# e disparar os comandos preenchendo os argumentos. Há uma classe que recebe o resultado. O arquivo não está 100% cobrindo os comandos do monitor, mas acho que já é uma ajuda pra quem está começando. Implementei apenas aqueles comandos que precisei, mas assim que tiver mais tempo pretendo implementar os demais. Acho que o código é fácil de entender, mas estou à disposição pra ajudar se alguém precisar. Monitor.cs

Olá pessoal, Depois de um empolgante trabalho em conjunto entre a equipe do ACBr e do Fortes Report CE... Temos o orgulho de apresentar a nova versão do Fortes Report CE, trazendo os seguintes benefícios: Diversos bugs corrigidos Suporte a Lazarus Suporte a D7 a Tokyo 10.2.2 em um único Package Instalador automatizado (frceInstall.exe) O Fortes Report CE poderá ser baixado pelo SVN ou GIT, ou ainda, baixado pelo FRCEInstall.exe, usando a integração com o SVN Para baixar o Fortes Report CE por SVN, use o endereço: https://github.com/fortesinformatica/fortesreport-ce/trunk Para baixar o Fortes Report CE por GIT, use o endereço: https://github.com/fortesinformatica/fortesreport-ce.git Lembre-se que você precisará remover qualquer outra versão do Fortes Report que existir em sua máquina antes de instalar a nova versão... Isso implica em: Remover o Package da versão antiga do Delphi Remover os diretórios da versão antiga do Lib Path do Delphi Apagar os fontes e DCUs, e BPLs da versão antiga Todos os pacotes do ACBr, que fazem referencia ao Fortes Report, estão nesse momento, sendo alterados para fazer uso do novo nome de pacote adotado pelo Fortes Report CE Delphi: frce.dpk; Lazarus: frce.lpk

Erro no download do XML manifestado , o mesmo ao entrar na função TNFeR.LerXml(unit pcnNFeR) não esta conseguindo achar a tag( VersaoInfNFe := Leitor.rAtributo('versao=');) correta, pois o xml obtido possui no inicio do xml uma outra tag 'retDownloadNFe versao=', logo a função sempre pega a versão errada. Realizei uma correção pegando a tag desse forma (VersaoInfNFe := Leitor.rAtributo('nfeProc versao=');), poderiam me informa se esse erro ocorre com vocês? Iiicio do XML '<retDownloadNFe versao="1.00" xmlns="http://www.portalfiscal.inf.br/nfe"><tpAmb>1</tpAmb><verAplic>AN_2.1.1</verAplic><cStat>139</cStat><xMotivo>Pedido de Download processado</xMotivo><dhResp>2015-11-12T10:23:03</dhResp><retNFe><chNFe>32151130544795000160550010000012641000012640</chNFe><cStat>140</cStat><xMotivo>Download disponibilizado</xMotivo><procNFe schema="procNFe_v3.10.xsd"><nfeProc versao="3.10" xmlns="http://www.portalfiscal.inf.br/nfe"><NFe xmlns="http://www.portalfiscal.inf.br/nfe"><infNFe versao="3.10" Id="NFe32151130544795000160550010000012641000012640"> segue abaixo .pas "corrigido" pcnNFeR.pas

As dúvidas são sobre a partilha do ICMS que listo abaixo: 1 - A partilha deve ser realizada apenas para produtos tributados? 2 - NFe's de substituição de cupom com CFOP 5.929 ou 6.929 devem também executar a partilha? 3 - Solicito gentileza detalhar o cálculo da partilha para uma NFe onde a alíquota interna no estado de destino é 17% e a interestadual é 12%, no valor total de R$ 100 que tem apenas um produto Tributado. 4 - Já é possível efetuar testes de emissão de NFe utilizando os novos campos de Partilha de ICMS e Cest?

Bom dia, Estou iniciando alguns testes na NFSe com trunk2. Percebi que uma mudança implementada é a utilização de arquivos .ini (cidades.ini e provedor.ini). Minha sugestão é que se defina um path específico para esses arquivos e não mantê-los na ApplicationPath. Por exemplo, na procedure TGeralConfNFSe.SetConfigMunicipio da ACBrNFSeConfiguracoes.pas, na linha "NomeArqParams := ApplicationPath + 'Cidades.ini';", mudar para " FPathOutros + 'Cidades.ini'. Mesma coisa na "NomeArqParams := ApplicationPath + FxProvedor +'.ini';". Lógico que precisa criar toda estrutura nos fontes desse novo FPathOutros. Do jeito que está, os arquivos .ini precisam ficar na pasta raiz da aplicação. Não haveria maiores problemas nisso. Mas acho que sendo possível colocar esses arquivos em uma pasta específica, ficaria mais organizado. Não sei exatamente quais seriam todas as units que teria que alterar para criar essa propriedade (FPathOutros) no componente. Se não eu já enviaria os fontes com as alterações. Então, peço que alguém que conheça melhor os fontes e saiba como fazer isso e, logicamente concordar com minha sugestão, que o faça. Obrigado!

Geral.CSC e Geral.IdCSC

Boa tarde! O Comando NFe.SetVersãoDF('3.10') se vc já tem setado no config não é necessário. O Comando NFe.SetModeloDF(55) se vc utiliza NFe e NFCe deve usar antes de utilizar os comandos pertencente a cada modelo. É mais seguro (Digo isto pois entendo que tem algumas mudanças que estão ocorrendo que permitem o ACBr tomar a decisão, mas nem tudo está implantando ainda). Desta forma vc não terá problema ao fazer por exemplo uma inutilização de um numero NFe após ter emitido uma NFCe e receber a mensagem de rejeição pelo ACBr "entender" que vc está tentando inutilizar uma NFCe, pois ficou setado no modelo 65.

Boa tarde Douglas, Vamos simplificar: Alimentar o componente >> Assinar >> Enviar >> Gravar XML no Banco O método Assinar já se encarrega de gerar e gravar o XML em disco. Você tem o retorno da SEFAZ que acusa que a nota foi denegada para que possamos analisar? Se sim, post como anexo.

sim trunk2, Deu certo vlw.

Eu também concordo que deve reduzir o trabalho.... Estou de acordo que não terá mais suporte. A questão é que o codigo ainda esta no trunk2 e ele não esta funcionando. Deixar ele lá sem compatibilidade com o trunk2 é pior. Se vai deixar ele lá, pelo menos deixa algo que esteja funcionando, e ai .... "não estamos mais dando suporte"... Se não vai corrigir nem o que já tinha, então melhor remover ele do trunk2.

Eu implementei assim: No cadastro de formas de pagamento do meu sistema tem o CNPJ da autorizadora(Operadora de Cartão) que é vinculado ao cadastro de fornecedor, caso seja informado um CNPJ ai acrescenta as Tag (tpIntegra = 1, CNPJ, tBand, cAut) referente ao cartão, nas transações TEF, faço a transação TEF antes de enviar NFC-e, caso seja aprovado, capturo o NSU "Autorização" para alimentar a Tag (cAut). Por que vinculei ao cadastro de fornecedor? Devido ao SPED Fiscal que deste 09/2015 passou a ter registro "REGISTRO 1600: TOTAL DAS OPERAÇÕES COM CARTÃO DE CRÉDITO E/OU DÉBITO" que trata das transações de cartão de crédito e debito, neste por sua vez deve ser informado os participantes, que será as empresa autorizadoras. No caso de TEF, o sistema deve tratar de forma diferenciada a impressão dos comprovantes, neste deve ser impresso as vias e após cada impressão perguntar para o usuário se a impressão foi impressa com sucesso, caso a resposta seja não, o sistema deve perguntar se quer retentar, se não, o sistema deve cancelar a transação. Não uso o acbr para transações TEF Não! Uso outro componente. Mais a NFC-e é toda feita com o acbr.

Só por desencargo tenta fazer o load assim: ACBrNFe.NotasFiscais.LoadFromString(ACBrNFe.WebServices.DownloadNFe.retDownloadNFe.retNFe.Items[0].procNFe) Está usando o trunk2 mesmo né?

function Tf_Mov_NFEnt.DownloadXML(const pChave: String; var pXml: WideString): Boolean; begin Result := True; if pChave = '' then Exit; ACBrNFe.DownloadNFe.Download.CNPJ := DM.cds_empresaCNPJ.AsString; ACBrNFe.DownloadNFe.Download.Chaves.Clear; ACBrNFe.DownloadNFe.Download.Chaves.Add; ACBrNFe.DownloadNFe.Download.Chaves.Items[ACBrNFe.DownloadNFe.Download.Chaves.Count-1].chNFe := pChave; ACBrNFe.Download; ACBrNFe.NotasFiscais.Clear; if not ACBrNFe.NotasFiscais.LoadFromString(ACBrNFe.WebServices.DownloadNFe.retDownloadNFe.XML) then begin Result := False; raise Exception.Create('Falha ao baixar o XML: ' + ACBrNFe.WebServices.DownloadNFe.retDownloadNFe.XML); end; if ACBrNFe.NotasFiscais.Items[0].XML = '' then begin Result := False; raise Exception.Create('Erro ao baixar o XML'); end; pXml := ACBrNFe.NotasFiscais.Items[0].XML; end;

Obrigado pela informaçao Daniel, realmente devia ser algum problema na rede pois , pedi para o pessoal que da suporte ao cliente na parte de hardware e pedi que refizessem a parte de rede e internet so para o sat, e entao a luz acesa apagou e voltou ao normal, quanto as letras em maiusculas, desculpe-me , mas e mania....as vezes esqueço disso... quanto a sequencia deste problema segue para ajudar alguem que passar por isso: - os cupons nao foram enviados por mais de 20 dias - o cliente nao observou a luz acesa a tempo - os cupons nao puderam ser enviados para sefaz apos os 10 dias, erro 276 - conforme instrucao da propria sefaz , se nao conseguir por algum motivo tecnico enviar os cupons dentro do prazo, os mesmos devem ser escriturados pelo Contador da empresa para o fisco atraves do SPED. fica prejudicado a nota fiscal paulista, mas o Contador sabe o que fazer nestes casos, pois me parece que um jeito de enviar os cupons com (n.f.p) criando uma especie e serie e enviar atraves de cfop 5929.... isso foi um contador que me passou...

Obrigado já está no svn!

Ricardo verifique no outro post o arquivo que anexei com o possível acerto:

Houve uma alteração no ACBr hoje a tarde quanto a isso, pode ser que tenha causado esse efeito colateral, efetuei uma possível correção, tente novamente com o arquivo anexado por favor. ACBrMonitor.zip

lucioam, é possível baixar os XMLs a partir do SGRSAT manualmente no site da SEFAZ, o contribuinte entra no site da SEFAZ com seu certificado digital e lá tem a opção de consultar lote de CFes enviados, lá pede a data/hora inicial e data/hora final e número de série do SAT, aí aparece os lotes enviados/processados do período informado, aí é só baixar. Sds, Ricardo.

Daniel.. olha lá no exemplo. acredito agora funcionar em ambos!

De qualquer forma o cliente vai ter que cadastar o CEST produto a produto.. Até da para sugerir um baseado no NCM, mas vai ter que fazer um por um.. Não vejo como ser diferente

Bom dia Se entendi direito essa sua sugestão, vc vai atrelar o CEST ao NCM. Nesse caso vai ter problemas para aqueles casos citados no início do post onde dois produtos com o mesmo ncm vão ter CEST diferentes. Acho que não vai ter saida.. o código CEST vai ter que estar vinculado ao produto e não ao ncm. Isso vai dar um trabalhão para os clientes ajustarem. Vão ter que entrar produto por produto e vincular o CEST correto ! Já to até vendo a choradeira !! kkkkk

Homologação sim, mas produção não, são ambientes diferentes, veja que a NT foi prorrogada para 01/12/2015 com cobrança a partir de 01/01/2016, então em produção eles ainda não colocaram.

Seria lindo, no caso de Brasília é simples porque é uma "cidade/estado" então tudo fica mais simples internamente imagino.

Para Remover o Fortes4Lazarus e instalar o Fortes Report CE Package -> Install/UnInstall package Ache o Fortes4Lazarus clique nele e em: "Uninstall selection" Save and Exit Package -> Package Links Ache o Fortes4Lazarus Selecione o Fortes4Lazarus Clique em "Delete Selected" Package -> Open Package file Abra o arquivo "frce.lpk" Compile Use -> Install Reconstrua o Lazarus Os Pacotes do ACBr para Lazarus, que faziam usam do Fortes4Lazarus, já foram migrados para o Fortes Report CE (frce.lpk)

Olá Pessoal, consegui resolver este problema colocando uma contra_barra "\" no fim do diretório de instalação na janela de configurações do instalador ficando assim "c:\delphi\acbr\". Obrigado a todos. Nilson.