Painel de líderes

Quadrilhas de estelionatários estão usando dados dos portais de consulta a documentos fiscais para emitir boletos falsos para os destinatários. Se conseguirem acesso aos XML dos Documentos Fiscais vai ficar pior ainda ( Sefaz permite essa aberração ). O criminosos geram o boleto e enviam para o e-mail do destinatário oferecendo alguma vantagem para que se antecipe o pagamento, ex: desconto ( possui dados do documento fiscal, emissor, destinatário, etc... ), obviamente o crédito vai para uma conta do crime organizado. Como tem brasileiro que gosta de levar vantagem em tudo, tem esperto pagando isso sem nem consultar o crédor ( mesmo o falso documento sendo diferente do recebido junto do DANFE ). Fica a dica, e se possível repassem o aviso para seus amigos e clientes

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

https://www.sefaz.rs.gov.br/NFE/NFE-VAL.aspx O XML não está correto. Faltam os dados do emitente, por exemplo. Verifique também a sintaxe correta de como informar serviço no .INI, você está informando como se fosse produto. Também se o município aceita a emissão de NFe conjugada. É possível que você tenha que emitir a NFSe.

Estava procurando por tópicos como este. Obrigado pela ajuda Ricardo

Boa tarde, recentemente, aconteceu este caso Att Ricardo

Boa tarde, veja mais na Nota Técnica 2012.002 que define as especificações técnicas para a implementação dos eventos da Manifestação do Destinatário. Att Ricardo

Bom dia Kiko. Realmente se colocar o caminho do certificado sem apertar o botão resolve o problema. Valeu pela dica. Daniel imaginei mesmo que o problema seria na maquina. Inclusive esses dias eu estava com problemas para abrir uma NF-e em PDF utilizando o adobe em um windows server 2008 e dava erro (somente nessa maquina). Então mudei a propriedade dos arquivos pdf para abrir no browser dessa maquina e pronto... problema solucionado. Mas é cada uma que aparece né.

Bom dia Thiago, acredito que seja possivel. Quanto ao prazo de emissão da Carta de Correção Eletrônica temos uma certa controversa. Vejam que na Nota Técnica 2011.004, item 6.2 – Regra de validação da CC-e, que o prazo máximo é de 720 horas (30 dias) da autorização e uso da NF-e. Entretando, se formos analisar a legalidade da limitação deste prazo através da interpretação do o Art. 138 combinado com o Art 173 do Código Tributário Nacional, o prazo para a emissão da Carta de correção é de cinco anos. Até mesmo por ser a carta de correção uma espécie de denúncia espontânea, permitindo ao contribuinte sanar qualquer irreguladidade antes de intervenção fiscal. Para convalidar sobre esta interpretação, temos também o Manual de Orientação do Contribuinte – Versão 5.0, de março de 2012 que não menciona mais o prazo para emissão da Carta de Correção Eletrônica (CC-e), podendo erros em campos específicos de NF-e,acima citados, serem sanados a qualquer tempo.

Quero agradecer a todos que tiveram paciência comigo ao longo desses 20 dias, até que cheguei a algo que me parece ser viável, Vou deixar um histórico dos meu problemas para que sirva a outros que passarem por algo semelhante O problema Inicial descrito neste Post um ERP em Delphi 7 com ACBr Trunck 1 para emitir NFCe. Após rodar para lá e pra cá a resposta final do Juliomar Marchetti foi que não funcionaria tendo que passar para o ACBr Mais Novo. Tentei faze-lo no Delphi7, onde estou amarradíssimo com o Fast Report 4 em quase todos meus relatórios, a orientação ainda do Juliomar Marchetti foi usar o Fast Report "Enterprise" ou o Fortes Report, porém em ambos casos não consegui fazer funcionar no Delphi 7, Dai sob a orientação dos senhores Daniel Simoes, André Ferreira de Moraes e EMBarbosa a solução era somente se removesse todo o meu Fast 4 talvez o teria conseguido o que no meu caso não era uma possibilidade viável, até receber uma negativa final ao meu IDE (Delphi 7), onde Mudei de foco então e resolvi partir para o XE7, e como tenho que dar continuidade ao meu ERP em Delphi 7 resolvi criar apenas um módulo de transmissão no XE7, Questionando e sendo respondido pelo EMBarbosa permaneci com o Delphi 7 usando o ACBr trunck 1 funcionando e transmitindo minhas NFe ainda perfeitamente e estou aplicando testes com sucesso no XE7 usando o ACBr mais recente para o NFCe, tive problemas e deixo a dica do Isaque Pinheiro para se alguém quiser usar os dois simultaneamente 1) Entre na IDE de cada Delphi instalado em sua maquina 2) Vá no menu Tools->Options-> Environment Variables, 3) Procure na lista "System Variables" a opção "Path" e remova o Path da outra IDE, de fato em nenhuma das minhas IDE o caminho foi exatamente esse mas enfim localize o path principal de sua IDE e remova o da outra. Ambos os ACBr estão funcionando embora eu esteja tendo o incomodo de ter que reinstalar o ACBr mais novo para o XE7 a cada nova execução desse IDE, o que para mim é dos males o menor. A médio prazo passarei também minha NFe para este módulo que desenvolverei a partir do próprio ACBrNFe_demo, removendo a versão antiga e isso não mai me perturbará. Agradeço novamente a todos mencionados aqui, pela paciência até o presente momento.

Bom dia! No caso do OpenSSl vc pode tentar colocar direto o caminho do arquivo e a senha, sem necessariamente ter que clicar no botão, ai penso que não precisaria ficar tentando até funcionar. O primeiro caso, que bom que detectou. Sempre pareceu mesmo ser algo com o antivírus. O que percebi é que uma vez que os Exes estão vindo assinados, o problema de conflitos com os sistemas de bancos diminuíram.

Eu voltei a revision como mencionei acima, @FSoftware, mas ainda tenho dúvidas se está correto a maneira que está gerando o XML, porém as MDF-es estão sendo aceitas pela SEFAZ.

Não altera. Ela foi emitida em contingência, e autorizada posteriormente.

Boa Tarde Pessoal, alguem que conseguiu implementar para o provedor 4R pode me passar um exemplo do XML do envelope completo para fazer uma comparação com o meu ? se eu pego o meu xml gerado pela aplicação e coloco no painel de homologação deles, a Nota é aceita, porém no envio através do webservice está apresentando um erro. estou desenvolvendo para a prefeitura de Itanhaém, mais acredito que o envelope seja igual de outras cidades.

Alteração já feita, disponível no SVN Rev.: [13204]. A versão semanal deverá conter a alteração. Deve ser liberada amanhã.

Removi o suporte a diretiva "DFE_SEM_NCRYPT", pois não é mais necessária, com a Carga dinâmica em ACBr_NCrypt.pas

Nos componentes, seria necessário, diminuir o tamanho do Buffer de envio da Serial ... algo como: ACBrPosPrinter1.Device.SendBytesCount := 8192; // 8KB No MonitorPLUS ainda não há configuração para isso... mas não é difícil de implementar... o @Celso, já está analisando o caso...

Boa noite! Fiz as alterações nos fontes e arquivo "boletonovo.fr3" para imprimir o nome do sacador avalista e seu CNPJ que não estavam no layout e o campo do CNPJ não tinha suporte. Unit alterada = ACBrBoletoFCFR Arquivo fr3 alterado = BoletoNovo.fr3 Em anexo os arquivos para analise e atualização. Marcos Softbox Informática Ltda BoletoNovo.fr3 ACBrBoletoFCFR.dfm ACBrBoletoFCFR.pas

Bom dia! Testado e funcionando. Obrigado. Marcos

No svn a mudança! favor testar!

@Fabio Souza Obrigado pela contribuição, devo analisar os fontes e subir assim que possível no SVN.

Bom dia a todos, Quando eu salvo no banco de dados uma nova nota, utilizo o Randomize para gerar o cNF e guardo esse numero junto com os demais dados da nota no banco de dados. Randomize; CodigoNFChave := Random(999999999) + 1; // é somado 1 para garantir que esse código nunca seja zero. Na rotina que é lido os dados da nota para alimentar o componente tenho a seguinte linha: Ide.cNF := DM_VEN.NotasCodigoNFChave.AsInteger; Se cNF for alimentado com um valor diferente de zero, o componente se utiliza desse numero para compor a chave, por outro lado se for zero que vai gerar o código de forma aleatória é o próprio componente. Da forma que fiz nuca corro o risco de uma nota ter 2 chaves distintas quando se faz necessário gerar novamente o XML por motivo de rejeição de algum dado informado de forma errada.

Existe uma tag no XML da NF-e/NFC-e a cNF, conforme nota técnica e manual, ela DEVE ser um um número aleatório, porque? Ela faz parte da geração da chave da NF-e, ela traz segurança não permitindo esse tipo de prática, já que fica muito complicado alguém gerar uma chave desconhecendo o número aleatório gerado no momento da criação da chave. Muitas empresas adotam a prática de utilizar um número fixo ou o próprio número da NF-e/NFC-e, isso leva a este tipo de problema. A tag XMLAut não serve para isso, ela serve para restringir o download, veja, um usuário de posse da chave pode consultar a NF-e/NFC-e e fazer parsing da página de consulta gerando um XML ou lendo os dados que necessitar, o correto é utilizar a tag que foi criada para isso, ou seja, cNF, basta gerá-la corretamente como manda o manual e a seguranças será incrementada e dificultará em muito o acesso aos dados.