Luiz Sodré

Obrigado.

@Diego Foliene, boa tarde. Não realizei nenhum tipo de altera de código fonte do provedor "SpeedGov", somente apontei o município para este provedor. Segue anexo os dados fornecidos pelo próprio provedor "SpeedGov" WEB SERVICE.rar Abaixo, foram as orientações passadas pelo provedor para a implementação de Juazeiro do Norte/CE: "Seguem as orientações para acessar o webservice. É preciso que você siga as instruções descritas abaixo para que o teste seja um 1º Passo - Realizar a adaptação do seu sistema para uso da ferramenta seguindo o manual de adequação (em anexo). 2º Passo - Link de cadastro http://servicos2.speedgov.com.br/modelo/precadastro/new 3º Passo - Link de homologação http://speedgov.com.br/wsmod/Nfes?wsdl 4º Passo - Link para visualização de erros e correção iss.speedgov.com.br/modelo Caso o processo de homologação já tenha sido feito segue o link para produção: http://speedgov.com.br/wsjun/Nfes?wsdl" Só consegui realizar teste de envio de lote e retorno de lote, ambos em ambiente de homologação. Espero ter ajudado, mais informações que essas, não possuo.

Prezados, A prefeitura de Juazeiro do Norte/CE alterou o provedor para "SpeedGov", não tive retorno do uso em produção, porém para utilizar em homologação, só realizei alteração no arquivo "ACBrNFSeXServicos.ini". http://servicos2.speedgov.com.br/juazeirodonorte Segue anexo o arquivo alterado Fontes.zip.

@Italo Giurizzato Junior Bom dia! Segue anexo, melhoria no arquivo "ISSDSF.Provider.pas" para a classe "TNFSeConsultaLoteRpsResponse" receber a data de envio do lote, retornado na TAG "DataEnvioLote". Melhoria também para a propriedade "Link" do item de resumo "TNFSeResumoCollectionItem", para receber a URL de visualização da nota fiscal emitida, através da TAG "URLNotaFiscal". Belém/PA é provedor Siat (herança layout IssDSF), para não gerar muita alteração, realizei os pontuais ajustes para minha necessidade. Fontes.zip

Italo, bom dia. No arquivo que enviei, não retirei a variável "aPath" do método "Gravar", pois utilizo do padrão de pasta do próprio componente, através do "aPath := aConfig.Arquivos.GetPathNFSe;". Caso retire a variável "aPath", o método gravar deverá ficar desta forma TACBrNFSeX(FAOwner).Gravar(aNota.NomeArq, aNota.XmlNfse); Poderia ajustar? Desde já, obrigado.

Bom dia! Realizei alteração para passar a informação do caminho do arquivo XML pra a propriedade "NomeArq" da classe "TNotaFiscal", através do salvamento do arquivo na classe "TACBrNFSeXProvider". Fiz a alteração por necessitar do local do salvamento e que não encontrei em outro lugar, somente se eu refizer o caminho. Por garantia, realizei a alteração neste ponto e meu intuito foi deixar conforme o método "SalvarXmlRps", que atribui caminho e nome de arquivo juntos. Mudei o mínimo para evitar grandes impactos. Segue anexo. CaminhoXmlNfse.zip

Entendido Italo. Irei rever o sistema para utilizar a nova classe de Resumo, em vista que a classe sempre será preenchida em todos os padrões do componente atualmente.

Bom dia @Italo Giurizzato Junior Quando subiu a alteração do resumo ? Pois mesmo que resumido o retorno, o componente preenchia somente os valores existentes na TNotasFiscais e era somente utilizar os campos existentes para qualquer tratativa que necessitasse. Todos os leiautes estão com essa classe de resumo ? Essa classe sempre será preenchida, mesmo com retorno completo ? (já que os existem as informações para preenchimento) Já possui LoadFromFile de arquivo resumido ? (para carregamento aparte) Estou perguntando pois acabou mudando o método de trabalho do componente para o retorno e não parece que não está em fluxo padrão.

@Italo Giurizzato Junior, bom dia. Realizei a passagem das informações por fora do componente, utilizando as propriedades. Assim não terá a necessidade de subir os fontes. Obrigado. @Renato Rubinho, bom dia. Referente aos outros problemas, ainda batalho para que melhoremos o processo interno para a leitura de pasta. E o erro no servidor se manteve após atualizar a DLL, mas vou levantar mais informações. Obrigado.

O ideal é conferir no portal da prefeitura, pois, pode ocorrer da prefeitura realizar todos os cálculos através do serviço enviado e ignorar o que foi passado no XML. Como o arquivo de retorno da prefeitura está incorreto, faça o contato com eles, visto que internamente o componente salva o arquivo de retorno sem manipulação.

Já vi reclamações sobre isso, mas tente ajustar o timeout do componente para ver se melhora.

Verifique se a incidência está interna ou não. Verifique também o ISSRetido. Essas informações podem influenciar em alguma validação interna da prefeitura de Sorocaba/SP.

Qual o valor da alíquota está sendo passada ? Quando o NrOcorrAliquota for 1, o componente irá gerar a tag mesmo que vazia. Com o NrOcorrAliquota no padrão 0 (zero), caso a alíquota passada seja 0 (zero) o componente não montará tag. Se não estiver montando a tag, é porque está passando zero e se estiver com uma atividade que possuí alíquota e a prefeitura não se resolveu sozinha, então aconselho realizar a passagem correta da alíquota para forçar a informação na conversão do RPS.

Vi que a tributação é exigível e pelo que tenho de experiência, você teria que passar a informação de alíquota e dependendo do provedor, você pode deixar em branco que ele pega a alíquota cadastrada para a atividade. Tente ver na tabela de atividades da prefeituras qual o valor da alíquota e passe-a para ver se funciona.

bom dia, pelo nome dos arquivos, está utilizando o método síncrono e realmente irá demorar um pouco na resposta, pois dependerá da estrutura do provedor que irá converter as notas e lhe retornar no mesmo momento. realizar o ajuste do timeout é realmente a solução neste caso, mas dependerá da quantidade de RPS contidas no lote. normalmente eu utilizo do método assíncrono e depois consulto, assim acaba tento tempo para as prefeituras converterem as notas. utilizo o método síncrono somente quando as prefeituras levam muito tempo para processamento, pois tem alguns provedores que demoram até 24h para realizar uma conversão assíncrona. O provedor Fiorilli é um desses casos.

@RonBrisola, bom dia. isso é merge não concluído. >>>>>>> .r24825 ; Remover essa linha e as 7 linhas abaixo após o dia 01/04/2022 deve estar com conflito pelo SVN, ajuste o conflito e marque como resolvido.

@Italo Giurizzato Junior, bom dia. Segue a URL de produção para Sorocaba/SP https://notafiscal.sorocaba.sp.gov.br/notafiscal-abrasfv203-ws/NotaFiscalSoap?wsdl

Obrigado @Renato Rubinho Irei verificar e testar.

Estou o problema abaixo e não consigo identificar onde está o problema, pois só ocorre no servidor. The server committed a protocol violation. Section=ResponseHeader Detail=CR must be followed by LF Passou a ocorrer quando passei a utilizar a LibXml2. Poderiam passar uma dica ?

Obrigado @Renato Rubinho Irei me reunião amanhã para discutir a melhor solução e levarei sua sugestão para debater.

Vi os relatos aqui na comunidade Italo. Mas como posso proceder com a xsLibXml2 quando tiver casos de estruturas com endereços de rede "\\Servidor\Arquivos\Schemas" por exemplo ? Por existir o risco da perda do certificado A3, não seria a solução adequada o que passei. Como ainda existe a possibilidade de uso e estou aos poucos migrando para ACBrNFSeX, pensei que poderia contida a utilizar, em vista que no ACBrNFSe estava assim. Vou conversar internamente para verificar outras possibilidades pois ao menos a validação terei que fazer quando houver caminho de rede.

Boa tarde, Italo. Maior parte das vezes utilizamos o xsLibXml2, mas dependendo da estrutura do cliente, utilizamos o xsMsXml que funcionava normalmente no ACBrNFSe. Um problema por exemplo, seria a identificação de caminho de rede pela xsLibXml2, onde tivemos problema e tivemos que voltar em alguns casos para o xsMsXml.

Realmente @Italo Giurizzato Junior boa noite. Tenho períodos de fechamento de fonte para atualizar o componente e quando realizei o merge para o trunk2 para enviar aqui, acabei não me atentando. Reparei que realizou alterações no que enviei, irei testar com suas alterações para validar.

Boa noite, estou com problema na validação de Schemas quando utilizo a propriedade SSLXmlSignLib = xsMsXml. O que analisei comparando com o componente anterior ACBrNFSe, é que o NameSpaceURI é preenchido com o NameSpace que era montado através dos arquivos ini. Hoje o NameSpace é preenchido diretamente nas classes dos provedores e não são mais passados para o NameSpaceURI e desta forma ocorre erro de validação do schema, conforme abaixo: " nfse.xsd#/schema The '' namespace provided differs from the schema's 'http://www.abrasf.org.br/nfse.xsd' targetNamespace" Como solução para utilização da propriedade SSLXmlSignLib = xsMsXml, voltei a realizar a passagem para NameSpaceURI com a informação do NameSpace contido em ConfigMsgDados.LoteRps.xmlns (sendo LoteRps a classe do processamento do momento de validação de schema). Testei esta validação para os municípios Dourados/MS, Ponta Porã/MS, Corumbá/MS, Três Lagoas/MS, Ipatinga/MG e Itajubá/MG, onde, todas passaram a validar normalmente dentro da unidade "ACBrDFeXsMsXml". Segue um erro forçado após o ajuste da validação: "Erro de Validação: Content for element '{http://www.abrasf.org.br/nfse.xsd}EnviarLoteRpsEnvio' is incomplete according to the DTD/Schema. Expecting: {http://www.w3.org/2000/09/xmldsig#}Signature." Segue anexo a unidade alterada. Fontes.zip

Também tive problema com os processos para a prefeitura de Joinville/SC. Realizei alterações nos arquivos em anexo "Fontes", segue abaixo as alterações: ISSJoinville.GravarXml.pas => realizada a inclusão do GerarIDRps como true, para enviar o "Id" juntamente a tag de RPS; ISSJoinville.LerXml.pas => realizada nova leitura, para obter a informação da tag NumeroRps, pois não está no padrão de retorno ABRASF; ISSJoinville.Provider.pas => realizada a retirada do alias do namespace no método "GetNamespace"; Realizada também a herança do método "TratarRetornoConsultaLoteRps" para tratar o retorno com erro e utilizamos o método "ProcessarMensagemErros" passando as tags de lista de erro e mensagem de erro corretos, conforme o retorno não padronizado do ABRASF. No anexo "Arquivo_SOAP", estão os arquivos gerados em comunicação de envio e consulta de lote para Joinville/SC. Fontes.zip Arquivos_SOAP.zip