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.

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.

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

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.