kartter
Membros-
Total de ítens
29 -
Registro em
-
Última visita
Últimos Visitantes
O bloco dos últimos visitantes está desativado e não está sendo visualizado por outros usuários.
kartter's Achievements
-
@João Antônio Funcionou 100%. Você está conseguindo emitir a nfse? Porque o protocolo só retorna que já foi aceito.
-
Ei @Luciwagner bom dia. Conseguiu algo? O erro de validação ocorre tanto em homologação quanto em produção.
-
No componente já está configurado corretamente. [3147105] Nome=Para de Minas UF=MG Provedor=ISSDigital ProRecepcionar=https://parademinas.mg.issqn.quasar.srv.br/nfe/snissdigitalsvc HomRecepcionar=https://parademinas.mg.issqn.quasar.srv.br/nfe/snissdigitalsvc
-
Consegui emitir. Porém tive que fazer uma alteração na unit PadraoNacional.GravarXml; function TNFSeW_PadraoNacional.GerarXMLPrestador: TACBrXmlNode; //movi para fora do IF. esta tag tem sempre que ser enviada Result.AppendChild(AddNode(tcStr, '#1', 'xNome', 1, 300, 0, NFSe.Prestador.RazaoSocial, '')); Estou vendo com o suporte deles como pegar as informações do DPS depois que enviamos, pois eles retornam apenas um XML com um numero de protocolo. Tentei usar a função consultar situação do exemplo do ACBR porém recebo o xml em anexo de retorno. 20260016246-sit.xml 20260016246-con-sit.xml
-
kartter started following IISDIGITAL e Provedor Quasar
-
Ao tentar emitir uma nfse pelo ACBR para a prefeitura de Pará de Minas (MG) recebo o seguinte retorno: Quando possíve analisem a possibilidade de implementação da adequação deste provedor. Segue abaixo os dados técnicos retornados pelo suporte da QUASAR Prezado, boa tarde Informamos que o Web Service (WS) antigo foi descontinuado, uma vez que não está em conformidade com o padrão definido pela Nota Nacional da NFS-e. Ressaltamos que o modelo baseado em RPS não segue o padrão nacional vigente, motivo pelo qual o WS antigo precisa ser desativado. A Nota Nacional adota o fluxo e os leiautes oficiais definidos pelo Governo Federal, não sendo compatível com integrações baseadas em padrões legados. Atualmente, o Web Service encontra-se com algumas instabilidades, e nossa equipe técnica já está atuando para corrigir os pontos identificados, com o objetivo de garantir maior estabilidade e plena conformidade com o padrão nacional. Os modelos oficiais de integração e leiautes que deverão ser utilizados são aqueles disponibilizados pelo Governo Federal, sendo esta a única documentação oficial válida para fins de adequação ao padrão nacional da NFS-e. Os documentos podem ser acessados nos links abaixo: https://www.gov.br/nfse/pt-br/biblioteca/documentacao-tecnica/documentacao-atual/anexo_i-sefin_adn-dps_nfse-snnfse-v1-00-20251226.xlsx https://www.gov.br/nfse/pt-br/biblioteca/documentacao-tecnica/rtc-producao-restrita-piloto/anexovi-leiautesrn_rtc_ibscbs-v1-01-03-nt004.xlsx Informamos ainda que o sistema segue a Lista Nacional de Serviços, conforme disponibilizada pela Nota Nacional da NFS-e, disponível no endereço abaixo: https://www.gov.br/nfse/pt-br/biblioteca/documentacao-tecnica/documentacao-atual/anexo_b-nbs2-lista_servico_nacional-snnfse.xlsx No ambiente de produção, o link de integração permanece o mesmo, bem como a obrigatoriedade de observância às documentações técnicas oficiais, sempre em conformidade com o padrão nacional. Para a continuidade dos testes de emissão da DPS, solicitamos que estes sejam realizados utilizando o link do ambiente atual de testes: https://parademinas.mg.des.issqn.quasar.tec.br/nfe/snissdigitalsvc?wsdl Em caso de erro durante os testes, pedimos a gentileza de encaminhar o arquivo de envio e o arquivo de retorno, para que possamos realizar a análise técnica de forma mais ágil e precisa. Por fim, para facilitar o acompanhamento e evitar qualquer desencontro de informações, solicitamos que todas as tratativas sejam concentradas neste mesmo e-mail. Permanecemos à disposição para quaisquer dúvidas ou esclarecimentos adicionais e pedimos desculpas desde já por eventuais transtornos. Atenciosamente, Suporte Quasar
-
Fiz a alteração no arquivo ini para apontar para url de testes e configurei o componente para ler o arquivo o INI. Porém pelo programa de teste recebo o retorno:
-
A prefeitura de Pará de Minas (MG) continuará usando o provedor proprio do municipio, utilizando o padrão nacional. Acredito que o ACBR precisa ser ajustado ainda certo? Segue retorno do suporte da quasar Os modelos oficiais de integração e leiautes que deverão ser utilizados são aqueles disponibilizados pelo Governo Federal, sendo esta a única documentação oficial válida para fins de adequação ao padrão nacional da NFS-e. Os documentos podem ser acessados nos links abaixo: https://www.gov.br/nfse/pt-br/biblioteca/documentacao-tecnica/documentacao-atual/anexo_i-sefin_adn-dps_nfse-snnfse-v1-00-20251226.xlsx https://www.gov.br/nfse/pt-br/biblioteca/documentacao-tecnica/rtc-producao-restrita-piloto/anexovi-leiautesrn_rtc_ibscbs-v1-01-03-nt004.xlsx Informamos ainda que o sistema segue a Lista Nacional de Serviços, conforme disponibilizada pela Nota Nacional da NFS-e, disponível no endereço abaixo: https://www.gov.br/nfse/pt-br/biblioteca/documentacao-tecnica/documentacao-atual/anexo_b-nbs2-lista_servico_nacional-snnfse.xlsx No ambiente de produção, o link de integração permanece o mesmo, bem como a obrigatoriedade de observância às documentações técnicas oficiais, sempre em conformidade com o padrão nacional. Para a continuidade dos testes de emissão da DPS, solicitamos que estes sejam realizados utilizando o link do ambiente atual de testes: https://parademinas.mg.des.issqn.quasar.tec.br/nfe/snissdigitalsvc?wsdl
-
Ei @Italo Jurisato Junior Então para validar com base no xsd do esocial, obrigatoriamente este tem que estar assinado?
-
Olá @Alisson Souza Pereira! Se no caso nós fossemos o terceiro, teríamos que enviar para a empresa o XML dos eventos de saúde de trabalho. (Estou colocando o caso de sistemas de medicina que usam o ACBR para gerar os eventos). Então a clínica de medicina simplesmente gera os arquivos sem assinatura e os remete para a empresa contratante. Pelo que entendi, a indagação do @Daniel de Queiroz é neste sentido.
-
Também daria certo. Mas não resolveria a seguinte situação: As clinicas de medicina do trabalho geram os arquivos de saude e segurança do trabalhador (1060,2220....). Ela gera os eventos e não necessariamente precisa assiná-los, pois ela apenas gera o XML e envia para a empresa do funcionário, que se encarrega de recepcionar este arquivo, assinar e enviar ao eSocial.
-
Olá Ítalo! A questão seria o seguinte: Os eventos podem ser gerados por diversos setores da empresa. Por exemplo: O setor de saúde e segurança gera os eventos referentes a saúde do trabalhador (1060,2220,2240,2245). Este setor, não necessariamente tem o certificado para poder assinar. Ele apenas gera os eventos e os envia para o outro setor. Este outro setor que se encarrega de assinar os eventos e enviar ao eSocial. Por isto acho interessante a possibilidade de se poder gerar os eventos sem assinatura e sem ter que ter o certificado digital instalado na maquina que está gerando o evento.
-
Ei Ítalo. Nos demais clientes, eu uso a CAPICOM Neste cliente, quando uso CAPICOM, ele retorna CLASSE não registrada quando tento enviar o RPS Aí mudei para wincript Com esta configuração, eu consigo enviar, porém retorna o erro E174
-
Bom dia, Estou com um problema que não estou conseguindo solucionar. Utilizando o servidos BHSISS (Prefeitura de Belo Horizonte), quando tento enviar um RPS, ele sempre retorna o erro E174 - Arquivo enviado com erro na assinatura. O estranho é que isto ocorre em apenas um cliente. Os demais enviam sem problemas neste mesmo provedor para a prefeitura de B.H. Já testei em 3 máquinas deste cliente e sempre retorna o mesmo erro. Será que é alguma configuração do tipo de certificado dele? O certificado dele é A3 da Certisign Alguém já passou por isto e tem alguma solução para me auxiliar? Obrigado a todos!
