Pesquisar na Comunidade

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! 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

Alguém está com problemas para emitir NFe 3,10 na SEFAZ SP hoje ?

boa tarde.. ao tentar enviar uma carta de correção do CTe para SP ele reclama do erro: "525 Rejeicao: Carta de correcao invalida (campo/grupo [CFOP] informado nao existe no schema do CT-e ou nao existe no grupo informado)" ja em MG o mesmo teste não acontece, em ambiente de homologação, alguem passou por isto ? Atencipadamente agradeço a atenção... segue anexo os arquivos gerados pra MG e tambem SP MG - 1-eve.xml MG - 1-ped-evento.xml SP - 1-eve.xml SP - 1-ped-evento.xml

Bom dia. Estamos com problemas para autorizar os CTes para o estado de São Paulo, começou esta madrugada e os CTes estão rejeitando com o erro: "Erro Interno: 0 Http: 403 - Forbidden: Access is denied " Alguém mais esta tendo algum problema semelhante? Agradeço desde já, Diego.

olá bom dia estava realizando testes com a NFce 400, para o estado de São Paulo, mas estava recebendo a seguinte rejeição, "Rejeição: Endereço do site da UF da Consulta via QRCode diverge do previsto", depois de alterar o valor da tag arquivo "ACBrNFeServicos.ini" tirei este URL-QRCode_4.00_Original=https://www.homologacao.nfce.fazenda.sp.gov.br/NFCeConsultaPublica/ e coloquei este URL-QRCode_4.00=https://www.homologacao.nfce.fazenda.sp.gov.br/NFCeConsultaPublica/Paginas/ConsultaQRCode.aspx esta funcionando bem. só pra constar se alguem estiver com o mesmo problema.

Prezados, alguém já teve problemas de enviar RPS de serviços de tomador no exterior para o WebService da Cidade de São Paulo, e teve retorno de erro "1206 - Assinatura Digital do RPS incorreta"? Não tive problemas para tomadores nacionais, ele funciona corretamente. Para tomadores no exterior, tenho que informar as seguintes diferenças em relação aos tomadores nacionais, para fazer a cadeia de caracteres para assinatura: Item 5) Tipo de Tributação do RPS - Tomador Nacional: T - Tributado em São Paulo - Tomador Exterior: P - Exportador de Serviços (conforme lei 13.701/03, Artigo 2, Inciso I) Item 11) Indicador de CPF/CNPJ do Tomador - Tomador Nacional: 1 (CNPJ) ou 2 (CPF) - Tomador Exterior: 3 (Não Informado, pois não existe) Item 12) CPF/CNPJ do Tomador - Tomador Nacional: CPF/CNPJ com 14 dígitos - Tomador Exterior: preenchido com 14 zeros Obrigado, Thiago.

Boa tarde, Precisei fazer um ajuste na unit pnfsNFSeW_SP para impressão correta do percentual de carga tributária para a cidade de São Paulo pois estava arredondando o valor percentual. Exemplo: perc. carga tributária = 18,45 % no XML do RPS precisa enviar 0,1845 mas enviava 0,18 e aparecia 18,00 % na NFSe. A alteração foi na GerarListaServicos ficando desta maneira: procedure TNFSeW_SP.GerarListaServicos; begin Gerador.wCampoNFSe(tcStr, '', 'Discriminacao', 1, 2000, 1, NFSe.Servico.Discriminacao, ''); Gerador.wCampoNFSe(tcDe2, '', 'ValorCargaTributaria', 1, 15, 0, NFSe.Servico.ValorCargaTributaria, ''); //Gerador.wCampoNFSe(tcDe2, '', 'PercentualCargaTributaria', 1, 5, 0, NFSe.Servico.PercentualCargaTributaria, ''); // alterado de tcDe2 para tcDe4 Gerador.wCampoNFSe(tcDe4, '', 'PercentualCargaTributaria', 1, 5, 0, NFSe.Servico.PercentualCargaTributaria, ''); Gerador.wCampoNFSe(tcStr, '', 'FonteCargaTributaria', 1, 10, 0, NFSe.Servico.FonteCargaTributaria, ''); end; Segue anexo, se puderem avaliar para correção. pnfsNFSeW_SP.pas