Painel de líderes

Olá, bom dia! Já há um aviso no site da SEFAZ/SP https://www.fazenda.sp.gov.br/nfe/

Estou fechando o tópico para evitar de se estender no assunto em que não será resolvido pela equipe do ACBr e sim pela SEFAZ/SP. Já houve a ciência e a afirmação que o problema é do lado deles. Obg. a todos que contribuíram e se surgir outro problema na resolução a gente reabre o tópico.

Acabamos de conseguir contato por Telefone com a Sefaz / SP eles confirmaram que o problema é na própria SEFAZ e já estão verificando, dentro das próximas horas o problema deve ser corrigido por eles. Não deram "prazo" para ser corrigido.

Bom dia a todos, Complementando o que o Kiko escreveu, entrem em contato com a SEFAZ para relatar o problema. Peçam para os seus clientes (que utilizam os seus sistemas) também entrarem em contato com a SEFAZ. Quanto mais pessoas reclamarem, mas rápido eles arrumam a kaka que fizeram.

Bom dia! Eu entendo o teu cliente, mas acredito não ser justificável o que ele deseja. Pois no caso de DANFE qualquer via é via. Se alguém imprimir em site, será via, se alguém imprimir por sistemas de terceiro, será uma via considerada como Doc. Auxiliar da Nota Fiscal Eletrônica e terá o mesmo valor que a primeira mesmo que não venha ter o logo do emissor por exemplo (para casos impressos através do XML). Portanto eu vejo que mesmo o cliente argumentando que seria para facilitar um controle interno eu não consigo ver utilidade. Uma vez que imprimir 2 ou 10 cópias todos teriam a mesma função e somente se tem a certeza que que o DANFE corresponde a NOTA FISCAL ELETRÔNICA (XML) se fazendo uma consulta aos portais eletrônicos.

Obrigado Willian. Já havia marcado como resolvido o texto do colega @elrond que afirmou ter conseguido contato telefônico e eles avisaram que já estavam cientes.

Ligar no SEFAZ, já fez?

Boa tarde, Aqui geralmente cada 1 tem seu próprio software e utiliza a suite de componentes da ACBr, em geral todos aqui são desenvolvedores/software house

Achei esse site aqui: https://dfe-portal.svrs.rs.gov.br/NFE/CCC Consultei o CNPJ de um destinatário de nota que está dando denegada e aparece: "Contribuinte não localizado no Cadastro Centralizado de Contribuintes."

@Fernando Rodrigo, eu analisei o Demo que você me enviou no PV. Nele, tem alguns detalhes que modifique (colocações, posicionamento e informações). Gerei com os mesmos dados e para mim não deu nenhum problema. Estou enviando (PV) o que fiz no seu exemplo para você comparar com a sua aplicação. Abaixo está a imagem que gerou da Remessa (com os dados fornecidos por você). Fábio Gabriel

Em resposta a todos que pesquisarem sobre o assunto: Foi feito reunião entre a PayGo, ACBr e eu, nela foi constatado que um software destinado à B2B, onde não há iteração com consumidor, o PIX (no primeiro momento) não é o mais indicado. Isto porque num ambiente onde uma indústria vende para outra indústria, o procedimento mais utilizado é o faturamento da mercadoria e a emissão de boletos para pagamentos futuro (14DD, 28DD, 15FM, ect...). O PIX é um produto para pagamento imediato, onde o emissor aguardará o pagamento, se não naquele instante da venda; no mesmo dia! Um assunto também discutido na reunião foi que o PIX não é um possível gerador de um protesto, caso não for pago. Diferentemente do boleto, onde ele é um meio para protesto e muitas empresas utilizam o mesmo para o devido fim, caso não tenham uma confirmação do pagamento de seus clientes (empresas). A PayGo, caso não seja possível a utilização do TEF do ACBr, possui um Gateway de Pagamento onde é possível ser utilizado num ambiente B2B por exemplo. Mas os cuidados acima deverão ser levados em consideração! @Daniel Simoes, acho que é isto né? Tem algo a mais a contribuir que eu não mencionei? Podemos fechar o tópico?

Olá pessoal, Para quem ainda não sabe estou promovendo um Refactoring no componente ACBrNFSe. Ele praticamente foi reescrito do zero e infelizmente teremos algumas quebras de código quando ele for liberado. Mas vamos falar de coisas boas. Hoje temos que disponibilizar para os nossos clientes além do executável, DLLs, os famosos arquivos INI, o arquivo Cidades.ini e os arquivos INI dos provedores. Pois bem, isso acabou. Os arquivos INI referente aos provedores se transformaram em Unit, ou seja, fazem parte do fonte do componente. O conteúdo do arquivo Cidades.ini migrou para o arquivo ACBrNFSeServicos.ini que é transformando no ACBrNFSeServicos.res através do BAT: Compila_RES. O arquivo ACBrNFSeServicos.res é incorporado ao executável, logo vocês só vão precisar distribuir o executável e as DLLs para os seus clientes. O que vocês acharam dessa mudança? Ainda não esta 100%, em função das diferenças dos provedores, mas criei um novo método chamado Emitir que tem por finalidade gerar o XML do RPS, assinar se necessário, gerar o Lote e assinar se necessário, enviar, aguardar o retorno do XML da NFSe. Independente do serviço que o provedor se utiliza para recepcionar o XML do RPS. Vou dar um exemplo: O provedor 4R que segue a versão 2 do layout da ABRASF implementou somente o método EnviarLoteRpsSincrono para recepcionar o RPS, sendo que no Manual da ABRASF versão 2 estão previstos os métodos: EnviarLoteRps, EnviarLoteRpsSincrono e GerarNfse. Por outro lado o provedor ISSJoinville que também segue a versão 2 do layout da ABRASF implementou somente o método EnviarLoteRps. Se vocês tem clientes cujas cidades utilizam o provedor 4R e tem clientes em Joinville, ou vocês tem duas aplicações ou a aplicação tem uma tela de configuração para definir qual método a ser utilizado. O método Emitir vem para tentar resolver esse problema da seguinte forma: se o provedor for 4R ele vai se utilizar do método EnviarLoteRpsSincrono automaticamente, agora se for ISSJoinville vai usar o EnviarLoteRps. Desta forma não precisamos de nos preocuparmos com qual o método devemos usar para enviar o RPS para o webservice. Acredito que vai ficar muito bom e pratico. O que vocês acham? Muita coisa já foi feita e muito mais precisa ser feito. Para que vocês tenham uma ideia foi criado 32 Units, ou seja, uma para cada provedor que segue a versão 1 do layout da ABRASF, mais 53 Units para os provedores que seguem a versão 2 do layout da ABRASF e mais 19 Units para os provedores que tem o seu próprio layout. Até o final deste mês de outubro estarei disponibilizando o programa exemplo compilado para que vocês possam fazer mais testes. Em breve vou explicar como vão ser os testes e como reportar os resultados. Antes que eu esqueça, esse Refactoring visa poder incluir a emissão da NFS-e no ACBrMonitor Plus e a criação do ACBrLibNFSe (DLL). Um forte abraço a todos.

O A1 sempre é o recomendado, evita muita dor de cabeça... Mas para o A3 configure apenas o campo "NumeroSerie" do certificado e a senha. O Windows precisa estar totalmente atualizado e o certificado A3 devidamente instalado na máquina...

Boa tarde, na Seção [DFe] do .ini basta configurar o path do arquivo .pfx do certificado no campo "ArquivoPFX" e informar a senha, veja o exemplo pelo Demo da lib de como gravar a esses dados... https://acbr.sourceforge.io/ACBrLib/DFe.html

O problema é que a dll nativa não le as configs do IIS, então ele segue o padrão do OS se o OS esta com formato americano ele espera a data neste formato. Eu vou lançar uma nova versão forçando o formato BR mesmo se o OS não seguir este formato.

Bingo BIG!!! Era isso mesmo! Nossa, não sei como agradecer. Muito obrigado mesmo! Era um arquivo que eu estava trabalhando nele e havia sido desenvolvido no XE. Mas, como eu atualizei o ACBR, havia me esquecido dele porque estava compilando normal antes da atualização. Valeu BigWings! Suas "Grandes Asas" te levarão onde quiser! Agradeço imensamente também ao Juliomar que teve paciência e também dedicou seu precisos tempo para me ajudar e me ensinar! Vocês são demais! Valeu pessoal do ACBR! Por isso, cada dia que passa eu uso ainda mais a ferramenta. Grande abraço! Daniel

Vou fazer e aviso. Muito obrigado pela ajuda. Assim que terminar eu reporto se deu certo. Valeu!

O ACBrMonitor precisa estar instalado no terminal onde está plugado o SAT, quanto a integração se o seu TS "enxerga" os diretórios de monitoramento não haveria problemas com a integração via troca de arquivos. Sua aplicação precisa gerenciar bem a comunicação com cada terminal (PDV)

bom dia. abre o exemplo do ACBrNFe e com ele faz as configurações e testa

Sim seria via mapeamento para funcionar

Vou conferir a forma que está sendo utilizada e ver se fica igual.

Tópico movido para a área do SAC, para que o SLA de respostas seja considerado

na verdade aqui é um fórum de desenvolvedor, nós desenvolvemos as soluções

Perfeito @Juliomar Marchetti, mais uma vez obrigado pela ajuda.

Bom dia a todos. Também estou com o mesmo problema em diversos clientes, peguei alguns CNPJs, fui na "Consulta Pública ao Cadastro ICMS" do estado de SP, e não constam os CNPJs. Os mesmos também pesquisei no "Cadastro Centralizado de Contribuinte (CCC)" e também não constam. O que mais está parecendo é que colocaram em prática uma regra e ainda não existe uma base de dados completa e confiável para executar o mesmo. Boa sorte para nós. Atenciosamente, Emerson Crema.

Nilton, Não existe nenhuma NT que determina a criação de um novo campo no XML. Esse cSitCNPJ me parece ser um campo do CCC-Cadastro Centralizado do Contribuinte. Existe uma noticia no Portal da NF-e SVRS que diz o seguinte: 27/10/2020 DF - Ativação da Regra de Validação N12-98 em Produção A Secretaria de Economia do Distrito Federal informa a seus contribuintes emitentes de NF-e (Nota Fiscal Eletrônica) e NFC-e (Nota Fiscal ao Consumidor Eletrônica) contemplados com benefício fiscal que, em 03/11/2020, a regra de validação N12-98, prevista na versão 1.51 da Nota Técnica 2019.001, será ativada em produção. As demais Regras de Validação previstas na Nota Técnica mencionada serão exigidas posteriormente, conforme cronograma a ser publicado. https://www.receita.fazenda.df.gov.br/aplicacoes/noticia/detalhada.cfm?codNoticia=12293 A ativação desse regra acima pode estar provocando essa rejeição. Em vez de acusar a falta do cBenef que se refere a regra N12-98, deve estar gerando de forma equivocada a rejeição de denegação.

Recebi a seguinte informação de um cliente. Isso está ocorrendo em clientes que já excederam sua faixa de compra, de acordo com seu regime. Exemplo, o cliente é MEI e pode comprar até o valor X por mês ou por ano, e esse limite já foi excedido, por isso está denegando. Nesse caso o destinatário terá que mudar de regime. Não sei se procede, mas estou registrando aqui... Estamos tentando contato com a SEFAZ de SP para ter uma resposta deles.

Bom dia! Quando ocorrem erros que fogem a lógica e de forma simultânea alcançam mais contribuintes os colocando na mesma situação, geralmente é problema do lado da SEFAZ. Porém é bom sempre ver se passaram a validar alguma informação antes não validada. Não percebi nada de novo no site da SEFAZ/SP que indique que parâmetros novos estão sendo validados. Provavelmente é problema com algo que tentaram incrementar. Vamos aguardar.

http://legislacao.sef.sc.gov.br/html/Atos_Diat/2020/atodiat_20_038.htm

veja se resolve SELECT I.CODPRODUTO, SUM(I.QUANT) AS QTDTOTAL, SUM(SELECT SUM(E.QUANT) FROM ITENS E WHERE E.CODPRODUTO = I.CODPRODUTO AND E.CODVENDA = I.CODVENDA AND E.CODTAMANHO = 'P') AS P FROM ITENS I GROUP BY I.CODPRODUTO

Bom dia, pode utilizar o emulador de SP para realizar os testes preliminares, como a geração e validação dos dados por exemplo. Com o aparelho o que muda é a dll, mas os métodos são os mesmos por isso é possível utilizar o mesmo componente, só precisará utilizar a dll do fabricante do aparelho MFe.

Ok ! obrigado Vou baixar o novo exemplo. Obrigado Aristarco

Muito bom @Rodrigo Reis Mattos, obrigado pelo resumo...