Pesquisar na Comunidade

Olá pessoal! Como muitos estão cientes, a Sefaz de São Paulo publicou recentemente portaria que determinava que novos SATs não poderiam ser ativados, exceto por aqueles que já faziam uso do mesmo e também determinando uma data final para emissão de CF-e SAT. Ou seja, em poucas palavras, a portaria decretava o fim do equipamento no estado. (Se você não sabia de nada disso, recomendamos que leia mais sobre isso AQUI). No entanto, foi publicado na edição do dia 20/12/2024 do Diário Oficial do Estado de São Paulo a portaria SRE 92, DE 19 DE DEZEMBRO DE 2024, modificando novamente a Portaria CAT147/12 (responsável pela definição do SAT). Esta publicação mais recente revoga o seguinte artigo: Isso significa, que foi liberado novamente para que mesmo aqueles que nunca haviam utilizado SAT, possam ativar o equipamento. Será então que como a famigerada fênix o SAT estaria ressurgindo das cinzas? Apesar da nova portaria, tudo indica que não! Vale lembrar que apesar da revogação do artigo 34-C, o artigo 34-D ainda permanece mantendo assim a data 31/12/2025 como sendo o último dia no qual será permitido a emissão de CF-e SAT.

Não, você não leu errado o título da notícia. A sefaz de São Paulo está dando adeus ao SAT! Foi publicado no dia 31/10/2024 a Portaria SRE 79, DE 31 DE OUTUBRO DE 2024 que modifica a Portaria CAT147/12(responsável pela definição do SAT), acrescentando na mesma os seguintes artigos: Efetivamente impedindo a ativação de novos equipamentos SAT para quem ainda não o tinha o aparelho e estipulando a data de 01/01/2026 para o fim do SAT como um todo. Mas se eu uso o SAT o que eu vou fazer agora? A NFC-e é o documento fiscal que deverá ser utilizado no lugar do CF-e. A muito tempo, esses documentos são "intercambiáveis", com o contribuinte podendo escolher se emite uma NFC-e ou um CF-e através do SAT para acobertar a mesma operação. Eu estou um pouquinho enferrujado, mas o SAT não era a contingência da NFC-e? Não mais! A Sefaz já havia publicado previamente uma portaria autorizando o uso da contingência off-line para NFC-e no estado. Veja mais aqui:

Olá pessoal! Desde o dia 11/12/2024, por volta das 17h50 começamos a receber relatos em nossa comunidade do Discord e também em nosso fórum, de membros recebendo como retorno ao tentar transmitir uma NF-e para a Sefaz de São Paulo a rejeição 590. O volume relatos aumentou exponencialmente na data de 12/12/2024. Os relatos tem em comum as mesmas características: A NF-e transmitida é de um emitente do Simples Nacional. A NF-e transmitida tem um item da gás GLP cujo cProdANP informado consta na tabela de combustíveis sujeitos a tributação monofásica. A NF-e em questão faz uso do CST monofásico 61. A nota é rejeitada com o seguinte retorno: Se conferirmos na descrição da regra de validação, consta a seguinte exceção: Temos relatos de que a rejeição só é devolvida no ambiente de produção, com a mesma nota sendo autorizada normalmente no ambiente de testes e que ao validar o arquivo neste validador disponibilizado pela Sefaz RS o arquivo não acusa o erro da rejeição. Todas estas evidências indicam que o problema esteja no lado da Sefaz. Até o momento não há um parecer oficial por parte dos mesmos. Em casos assim, é muito importante que abram um Fale Conosco relatando o problema a Sefaz, pois quanto maior o volume de relatos, mais cedo eles se dão conta de que há algo errado.

Olá pessoal! Na data de 11/12/2024, por volta das 16h16 começamos a receber múltiplos relatos de membros da nossa comunidade de problemas para consumir os web services da Sefaz de São Paulo. Os relatos tem em comum estarem recebendo como retorno a mensagem: Conferindo no DownDetector, é possível observar que os relatos de problemas passaram a aumentar exponencialmente por volta do mesmo horário. Não, há contingência ativada até a publicação deste tópico.

Olá pessoal! Conferindo no Portal Nota Fiscal, é possível observar que a Sefaz de São Paulo está com a contingência agendada para o dia 08/12/2024 com previsão início às 07h00 e encerramento às 09h00 do mesmo dia. Para utilizar as soluções do ACBr em contingência durante este período, siga as orientações do tópico abaixo: Um agradecimento a membra de nossa comunidade @Maria Gabriele por compartilhar a informação em nosso Discord.

Olá pessoal! Conferindo no Portal da Nota Fiscal Eletrônica, é possível observar que a Sefaz de São Paulo está com contingência agendada para o dia 24/11/2024, com previsão de início às 06h00 e encerramento às 11h00 do mesmo dia. Para utilizar as soluções ACBr em contingência durante este período siga as orientações do tópico abaixo: Um agradecimento ao membro de nossa comunidade @Felipe Mariano por compartilhar a informação em nosso Discord.

Olá pessoal! Conferindo no Portal da Nota Fiscal Eletrônica, é possível observar a Sefaz de São Paulo programou a contingência para dia 10/11/2024 das 06:00 as 16:00. Agrecimento ao amigo @Felipe Michael da Fonseca pela informação.

Olá pessoal! Conferindo no Portal da Nota Fiscal Eletrônica, é possível observar a Sefaz de São Paulo ativou a contingência às 10h01, até o momento sem previsão de encerramento. Para utilizar as soluções ACBr em contingência siga as orientações do tópico abaixo:

Olá pessoal! Conferindo no DownDetector, por volta das 10h00 do dia 28/10/2024, o volume de problemas reportados na Sefaz de São Paulo aumentou exponencialmente. Não há contingência ativada até o momento da publicação deste tópico. Algumas sugestões em casos de problemas: Aumentar o valor da configuração de TimeOut da solução que estiver utilizando. Realizar um teste alterando a configuração de DNS para a possibilidade de ser um problema de rota. Realizar um teste utilizando link de internet alternativo para a possibilidade de ser um problema de rota.

Olá pessoal! Segue na integra aviso disponibilizado originalmente no dia 04/09/2024 no Portal da NFCom informando sobre a liberação do ambiente de homologação para São Paulo. Ativação do Ambiente de Homologação da SVRS para a SEFAZ SP Comunicamos com muita satisfação que o ambiente de autorização da SEFAZ Virtual RS para autorização de NFCom está habilitado para as operadoras de Telecom e contribuintes do estado de São Paulo. O credenciamento no ambiente de testes será realizado pela própria SEFAZ.

Olá pessoal! Conferindo no portal Sobre o SAT, consta um aviso informando que no dia 29/09/2024 entre às 08h00 e às 14h00 será realizada uma manutenção no ambiente de produção do SAT que poderá impactar a ativação de novos aparelhos SAT e também a recepção de CF-es. Devido a isso, a Sefaz de São Paulo recomenda que: Os contribuintes verifiquem se o aparelho SAT possui cupons na memória e caso afirmativo, conecte o aparelho na internet para transmissão fora deste período. Evitem realizar a ativação de novos equipamentos durante esta janela de manutenção e não troquem o código de ativação em caso de falha.

Olá pessoal! Na página Sobre o SAT da Sefaz de São Paulo, consta um recado informando que no dia 01/10/2024 a partir das 08h30 a Sefaz vai iniciar o processo de desligamento do protocolo TLS 1.0, com previsão inicial de o processo durar 2 horas. Durante esse período pode ocorrer instabilidade da comunicação com a Sefaz e por isso orienta que a ativação de novos SATs sejam feitos fora deste período. Também é lembrado que: Após este processo, os somente os SATs que se comunicam usando o protocolo TLS 1.0 não vão mais conseguir realizar comunicação. Esse processo já foi previamente comunicado pela Sefaz em aviso no dia 15/03/2024 (noticiado em nosso fórum no tópico Desligamento dos protocolos SSL 3.0 e TLS 1.0 para SAT nos próximos meses no dia 28/03/2024 e também no tópico ATENÇÃO!!! Desativação de Protocolos inseguros na comunicação dos SATs SSL3.0 e TLS1.0 no dia 13/06/2024). A tabela abaixo mostra os modelos de SAT afetados por este processo: Fabricante Modelo de SAT Versões de Software Básico de SAT Há atualizações de SAT para versão mais segura? Bematech RB-1000 e RB-2000 02.00.00 e 02.01.00 NÃO Jetway JS-1000 03.00.01 SIM Nitere NSAT4200 02.00.03 e 02.01.04 NÃO Tanca TS-1000 e TS-2000 01.00.00, 01.01.00, 01.01.01, 02.00.00, 02.02.00, 02.02.02, 03.00.00, 03.00.03 e 03.00.04 SIM Urano SAT UR e U-S@T 01.00.01 e 01.00.02 NÃO

Olá pessoal! Conferindo na página Sobre a NF-e consta um aviso informando que foi disponibilizado no ambiente de testes um autorizador síncrono para NF-e. Aviso reproduzido na íntegra: Síncrono... Assíncrono... que raios é isso?! Na transmissão de documentos fiscais, o envio para o web service pode ocorrer de duas maneiras. No envio assíncrono, o XML é enviado para o web service, que devolve um número de recibo. Em seguida, o emissor faz uma nova conexão com o mesmo web service para consultar o número de recibo e receber o resultado do processamento. No envio síncrono, o XML é enviado para o web service, que já devolve o resultado do processamento na mesma resposta, ou seja, tudo é feito em uma única conexão. E por que isso é importante? Apesar de existir as duas formas de envio, recentemente alguns documentos fiscais tem adotado exclusivamente o modo de envio síncrono e desativando o modo assíncrono. Isso aconteceu com a NFC-e: Com a versão 4.00 do CT-e: Com o MDF-e: E logo com a NF3e também: Para a NF-e especificamente, ainda existe ambos os métodos, com exceção de SP e BA que não aceitam o modo síncrono. Esse aviso indica que a Sefaz de SP está caminhando para que isso não seja mais o caso e ela passe a aceitar o envio síncrono também. O que pode ser um passo para que a NF-e também mude somente para o modo síncrono futuramente. Está edição do Papo PRO traz considerações sobre as formas de envio: Um agradecimento ao membro de nossa comunidade @Felipe Marianopor compartilhar a informação no canal #sefaz em nosso Discord.

Olá pessoal! No dia 07/08/2024, por volta das 08h35 começamos a receber em nosso Discord múltiplos relatos de membros com problemas ao tentar transmitir NF-e para a Sefaz de São Paulo. O erro que muitos relataram estar recebendo ao tentar realizar uma transmissão era: Conferindo no DownDetector, é possível observar que o volume de relatos de problema aumentou exponencialmente durante esse mesmo período: Alguns colegas relaram sucesso na emissão realizando um teste com um link de internet alternativo ou alterando o DNS. Uma dica que foi compartilhada é utilizar o comando: nslookup nfe.fazenda.sp.gov.br E ir testando qual DNS consegue comunicação.

Bom dia, Ao consultar NFSE por Faixa, número ou período na prefeitura de Sertãozinho/SP, provedor Smarap, é retornado erro ao converter a DataEmissao da RPS e Data de Competencia. Pelo que entendi existe uma rotina que está convertendo no padrão YYYY-MM-DD porém esta vindo no padrão DD/MM/YYYY no xml Procurando no fórum que a solução parece ser a mesma aplicada no link abaixo. * IMPORTANTE: Meu repositório está atualizado! 000000000000660000000000000660000001-con-nfse-fai.xml 000000000000660000000000000660000001-lista-nfse-fai.xml

Ola a todos, tenho duas duvidas e conto com a ajuda dos amigos, primeira duvida, qual a validade do layout 0.07 em SP, e segunda duvida, alguns clientes possuem Sat da Daruma, alguém possui a informação se o Sat vai ter suporte para o layout 0.08 e 0.09

Quando um pedido de consulta é enviado pra prefeitura de Sp é retornado erro que o O CPF/CNPJ da assinatura da mensagem XML não corresponde ao CPF/CNPJ do Prestador de Serviços. Considerações: O CNPJ que consta no remetente é 02685728000120, que é o mesmo CNPJ que consta do certificado; O XML enviado respeita perfeitamente o schema descrito nos XSD's; Tanto a assinatura do RPS quanto a assinatura W3C estão corretas, caso contrário o webservice teria indicado o erro; Para assegurar a afirmação anterior, foram também feitos testes com assinaturas de RPS propositalmente incorretas, e nesses casos o serviço corretamente indicou os erros nestas, demonstrando, claramente que se uma das assinaturas estivesse sendo montada de forma incorreta, o webservice apontaria isto. Retorno da Consulta: <Descricao>O CPF/CNPJ da assinatura da mensagem XML não corresponde ao CPF/CNPJ do Prestador de Serviços.</Descricao></Erro> Xml de consulta que foi enviado: <?xml version="1.0" encoding="utf-8"?> <p1:PedidoConsultaLote xmlns:p1="http://www.prefeitura.sp.gov.br/nfe" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <Cabecalho Versao="1"> <CPFCNPJRemetente> <CNPJ>02685728000120</CNPJ> </CPFCNPJRemetente> <NumeroLote>...</NumeroLote> </Cabecalho> </p1:PedidoConsultaLote>

Boa tarde. Hoje estou tendo uma alta incidência de clientes com rejeição 12002 (time-out) , na emissão da NFe em SP. Alguém está passando por isso. Sugestões ? Obrigado.

[3529302] Nome=Matao UF=SP Provedor=GINFES URL produção=https://producao.ginfes.com.br/ServiceGinfesImpl?wsdl URL homologação=https://homologacao.ginfes.com.br/ServiceGinfesImpl?wsdl Obs: para cancelamento fui informado pelo suporte do provedor que deve ser usado o schemas v2.0 e para envio schemas v3.0 (em anexo) schemas_v300.zip schemas_v200.zip

Olá, estou gerando as notas de serviço eletrônica porém o campo competência, que costumava imprimir corretamente MM/AAAA agora está imprimindo -1/AAAA, conforme na imagem abaixo. Houve alguma modificação na transmissão do RPS que eu não me atentei? Atualizei os fontes pensando que podia ser falta de atualização mas não resolveu. Alguém tem alguma ideia?

Não estou conseguindo enviar, de maneira nenhuma, cartas de correção (através de um sistema próprio). Alguém pode dar uma luz? Acredito que o problema esteja relacionado com as URLs de SP, pois a Carta de Correção é enviada corretamente para clientes de outros estados: URL do Sefaz enviada: https://homologacao.nfe.fazenda.sp.gov.br/ws/nferecepcaoevento4.asmx Obs: a URL de produção retorna o mesmo erro de homologação Detalhes da requisição: XML: <?xml version="1.0" encoding="utf-8"?> <soap12:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soap12="http://www.w3.org/2003/05/soap-envelope"> <soap12:Header> <nfeCabecMsg xmlns="http://www.portalfiscal.inf.br/nfe/wsdl/RecepcaoEvento"> <cUF>35</cUF> <versaoDados>1.00</versaoDados> </nfeCabecMsg> </soap12:Header> <soap12:Body> <nfeDadosMsg xmlns="http://www.portalfiscal.inf.br/nfe/wsdl/RecepcaoEvento"> <envEvento xmlns="http://www.portalfiscal.inf.br/nfe" versao="1.00"> <idLote>153452104877411</idLote> <evento xmlns="http://www.portalfiscal.inf.br/nfe" versao="1.00"> <infEvento Id="ID1101103518070923765800019655001000001710100001710303"> <cOrgao>35</cOrgao> <tpAmb>2</tpAmb> <CNPJ>xxxxxxxxx000196</CNPJ> <chNFe>xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx</chNFe> <dhEvento>2018-08-17T12:50:48-03:00</dhEvento> <tpEvento>110110</tpEvento> <nSeqEvento>1</nSeqEvento> <verEvento>1.00</verEvento> <detEvento versao="1.00"> <descEvento>Carta de Correcao</descEvento> <xCorrecao>CFOP ESTAVA ERRADO</xCorrecao> <xCondUso>A Carta de Correcao e disciplinada pelo paragrafo 1o-A do art. 7o do Convenio S/N, de 15 de dezembro de 1970 e pode ser utilizada para regularizacao de erro ocorrido na emissao de documento fiscal, desde que o erro nao esteja relacionado com: I - as variaveis que determinam o valor do imposto tais como: base de calculo, aliquota, diferenca de preco, quantidade, valor da operacao ou da prestacao; II - a correcao de dados cadastrais que implique mudanca do remetente ou do destinatario; III - a data de emissao ou de saida.</xCondUso> </detEvento> </infEvento> <Signature xmlns="http://www.w3.org/2000/09/xmldsig#"> <SignedInfo> <CanonicalizationMethod Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/> <SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/> <Reference URI="#IDxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"> <Transforms> <Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/> <Transform Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/> </Transforms> <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/> <DigestValue>xxxxxx=</DigestValue> </Reference> </SignedInfo> <SignatureValue>xxxx==</SignatureValue> <KeyInfo> <X509Data> <X509Certificate>xxxx==</X509Certificate> </X509Data> </KeyInfo> </Signature> </evento> </envEvento> </nfeDadosMsg> </soap12:Body> </soap12:Envelope> Headers: Content-Type: application/soap+xml;charset=utf-8;action="http://www.portalfiscal.inf.br/nfe/wsdl/RecepcaoEvento/nfeRecepcaoEvento" SOAPAction: "nfeRecepcaoEvento" Content-length: 5517 Resposta: HTTP/1.1 100 Continue HTTP/1.1 500 Internal Server Error Cache-Control: private Content-Type: application/soap+xml; charset=utf-8 Server: Microsoft-IIS/7.5 X-AspNet-Version: 4.0.30319 X-Powered-By: ASP.NET Date: Fri, 17 Aug 2018 15:52:12 GMT Content-Length: 538 <?xml version="1.0" encoding="utf-8"?><soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema"><soap:Body><soap:Fault><soap:Code><soap:Value>soap:Sender</soap:Value></soap:Code><soap:Reason><soap:Text xml:lang="en">Unable to handle request. The action 'http://www.portalfiscal.inf.br/nfe/wsdl/RecepcaoEvento/nfeRecepcaoEvento' was not recognized.</soap:Text></soap:Reason><soap:Detail /></soap:Fault></soap:Body></soap:Envelope>

Prezados, Sabendo dos prazos da NT 2016.002, e partindo do princípio que em 02/07/2018 sairá a NFe 3.10 do ar, já estou iniciando um cronograma para mudanças dessa versão nos clientes... Assim, gostaria de saber se alguém já migrou para a versão 4.0 em ambiente de produção, e se está enfrentando dificuldades, ou se está bem tranquilo e estável a versão 4.0 no ar. Se possível, gostaria que os que já migraram compartilhassem conosco as experiências. Grato, Michel,

Alguém sabe informar se a tag vDesc está sendo aceita com valor 0.00 no ambiente de produção da SEFAZ-SP ?

Boa tarde pessoal Ao realizar uma NFS-e da cidade de São Paulo, o Erro em anexo é apresentado. Já atualizei os Schemas, os Fontes e mesmo assim o erro ocorre. Segue também o XML para analise. Grato 0000000093RPS-rps.xml