Ir para conteúdo
  • Cadastre-se

Everton M Gava

Membros
  • Total de ítens

    89
  • Registro em

  • Última visita

Últimos Visitantes

1.366 visualizações

Everton M Gava's Achievements

  1. Boa tarde, RS e todos que usam a SVRS não implementaram os schemas ainda do lado deles. Por SP, consegui autorizar.
  2. O mesmo está ocorrendo com o MDF-e, o componente ACBr está removendo as letras da chave de acesso vinculada. Exemplo: a minha chave vinculada teria que ser 4226065GL3CNLB000108550000015014971042839304 e o componente carregou 42260653000108550000015014971042839304 <infNFe> <chNFe>42260653000108550000015014971042839304</chNFe> </infNFe> O problema está aqui: OnlyNumber(MDFe.infDoc.infMunDescarga[Idx].infNFe[i].chNFe). Unit ACBrMDFe.XMLWriter
  3. Entendi. Aqui em SC, que usa a SVRS ainda não está implementado pelo que eu entendi. Vou aguardar.
  4. Autorizou com um CNPJ Alfanumérico ou com um CNPJ "normal" ?
  5. Provavelmente o motivo é que a SEFAZ ainda não atualizou os schemas do lado dela. Em SC (SVRS) também estou tomando rejeição pelo mesmo motivo, com os schemas atualizados do meu lado e tentando mandar a tag <autXML> com um alfanumérico: <autXML> <CNPJ>3WN03YD1000161</CNPJ> </autXML> Rejeicao: Falha no Schema XML da NFe (Elemento: enviNFe/NFe[1]/infNFe/autXML/CNPJ/)
  6. Onde está informado que em base de homologação não será mais aceito o TLS 1.2? Não encontrei nenhum comunicado a respeito disso. Sabe de alguma coisa?
  7. O mesmo começou a ocorrer aqui em SC. Consulta de clientes OK, inclusão de eventos no MDF-e, OK. Já a emissão de NF-e, NFC-e, MDF-e, cancelamentos, etc, todas com o problema abaixo. Na segunda tentativa ocorre a autorização. Erro Interno: 12030 Erro HTTP: 0 URL: https://mdfe-homologacao.svrs.rs.gov.br/ws/MDFeRecepcaoSinc/MDFeRecepcaoSinc.asmx Erro: 12030 - A conexão com o servidor foi redefinida ou encerrada, ou um protocolo SSL incompatível foi encontrado
  8. Boa tarde, pessoal. Os schemas que o ACBr distribui junto com o fonte ainda não estão atualizados para o alfanumérico certo?
  9. Pessoal, fiz a adição dessas tags e alterei no GinfesProvider para DadosCabecalho := '<ns2:cabecalho versao="301" xmlns:ns2="http://www.ginfes.com.br/cabecalho_v03.xsd">' + '<versaoDados>301</versaoDados>' + '</ns2:cabecalho>'; Agora meu erro mudou,: <?xml version="1.0" encoding="UTF-8"?> -<EnviarLoteRpsResposta xmlns:ns3="http://www.ginfes.com.br/servico_enviar_lote_rps_resposta_v03.xsd" xmlns:ns2="http://www.ginfes.com.br/tipos_v03.xsd"> -<ListaMensagemRetorno> -<MensagemRetorno> <Codigo>S63</Codigo> <Mensagem>Erro ao consultar rps. Data da consulta: 15/05/2026 16:14:36</Mensagem> <Correcao>Entre em contato com o atendimento.</Correcao> </MensagemRetorno> </ListaMensagemRetorno> </EnviarLoteRpsResposta>
  10. Boa tarde, veja os meus ajustes como ficaram, seguindo as dicas dos colegas acima: Ainda estou obtendo o mesmo erro...
  11. As empresas que utilizam o Web Service do Ginfes para conversão de RPS no GissOnline V2 podem optar pelo novo modelo da NT 007. Para essa transição, é necessário atualizar a URL de comunicação (WSDL) para o novo padrão municipalizado: https://ws-[MEUMUNICIPIO].giss.com.br/service-ws/nf/nfse- ws?wsdl (exemplo: para o município "Fictício", utiliza-se [https://ws- ficticio.giss.com.br/service-ws/nf/nfse-ws?wsdl](https://ws- ficticio.giss.com.br/service-ws/nf/nfse-ws?wsdl)). exemplo: https://ws-rioclaro.giss.com.br/service-ws/nf/nfse-ws?wsdl em anexo o material que recebi Método de Preenchimento por Variação do Valor Próprio ou Retido PIS-COFINS e CSLL.pdf
  12. Bom dia, ontem (13/05/2026) o erro passou a ocorrer em Rio Claro/SP. O mesmo padrão de arquivo que foi autorizado normalmente no dia 12/05/2026 passou a simplesmente ser rejeitado no dia posterior Alguém tem alguma solução para isso?
×
×
  • Criar Novo...

Informação Importante

Colocamos cookies em seu dispositivo para ajudar a tornar este site melhor. Você pode ajustar suas configurações de cookies, caso contrário, assumiremos que você está bem para continuar.

The popup will be closed in 10 segundos...