Italo Giurizzato Junior

Boa tarde @Diogo Loff, Configure o componente para salvar os arquivos soap. Faça um novo teste e anexe ele aqui no fórum ou envie por mensagem privada para mim o arquivo soap de retorno para que eu possa analisar. Desde já muito obrigado pela colaboração.

Bom dia @Light System Software, No SVN o arquivo ACBrNFSeXServicos.ini no que se refere a cidade de Campinas/SP esta da seguinte forma: [3509502] ; Atualizado em 08/07/2024 Nome=Campinas UF=SP Provedor=ISSCampinas ; Comentar as 3 linhas abaixo para realizar testes com o novo webservice ProRecepcionar=https://issdigital.campinas.sp.gov.br/WsNFe2/LoteRps.jws ProNameSpace=http://proces.wsnfe2.dsfnet.com.br HomNameSpace=http://proces.wsnfe2.dsfnet.com.br ; Descomentar as 3 linhas abaixo para realizar testes com o novo webservice ;Versao=2.03 ;ProRecepcionar= ;HomRecepcionar=https://homol-rps.ima.sp.gov.br/notafiscal-abrasfv203-ws/NotaFiscalSoap Isso indica que ele ainda esta usando o webservice antigo e não o novo, alias não sabemos como é a URL de produção do novo webservice. Como você não informou qual é a mensagem de erro eu não tenho como lhe ajudar. Poderia me informar qual é a mensagem de erro? Ao configurar o componente esta pegando os schemas de qual pasta? Para o webservice antigo que se utiliza de um layout próprio o caminho dos schemas é: ...\Exemplos\ACBrDFe\Schemas\NFSe\ISSCampinas\1.00 Para o webservice novo que se utiliza da versão 2.03 do layout da ABRASF o caminho é: ...\Exemplos\ACBrDFe\Schemas\NFSe\ISSCampinas\2.03

Bom dia Maiquel, Muito obrigado pela colaboração, já foi criado a TK-5925 para realizar a alteração do arquivo INI.

Obrigado por reportar. Fechando. Para novas dúvidas, criar um novo tópico.

Tópico movido para a área do SAC, para que o SLA de respostas seja considerado

Bom dia ao @Raphael Sanini e @Juliomar Marchetti, Desde de agosto de 2023, portanto um mês antes a obrigatoriedade de emissão pelo Padrão Nacional dos prestadores que são MEI o ambiente de homologação continha diversos Bug e pelo jeito eles não foram sanados. Na época cheguei a conversar um servidor da RFB envolvido no projeto da NFS-e Padrão Nacional sobre esses Bug, a resposta foi que o pessoal estavam focados em resolver os Bug do ambiente de produção.

Bom dia @João Antônio, Muito obrigado pela colaboração, já foi criado a TK-5924 para fazer a alteração no arquivo INI.

Bom dia Paula, Veja como esta a minha configuração no programa exemplo: Note que ao definir o caminho eu paro na pasta NFSe e marco a opção para que o componente monte automaticamente o resto do caminho com base na cidade selecionada. Eu não tenho erro de schemas (validação) o XML do RPS foi gerado, assinado, validado e enviado para o webservice do provedor, mas infelizmente esta me retornando o erro L999. Pode ser que eu estou usando um CNPJ de um prestador de serviço que não é de campinas ou esse erro esta relacionado a um bug no webservice deles.

Bom dia @Diogo Loff, Somente o XML esta assim ou a impressão também esta dessa forma? Ao abrir esse XML com o bloco de notas ele indica qual codificação (ANSI ou UTF-8)?

Bom dia @Gabriel Bobello, Muito obrigado pela colaboração, já foi criado a TK-5923 para realizar a alteração no arquivo INI.

Olá Pessoal, Foi publicado a versão 1.64 da NT 2019/001, ela trata do cronograma de ativação de regras de validação para SC da inclusão das regras: N14a-10, N14a-20 e I05h-10 a critério da UF. Publicação de cronograma de ativação de regras de validação para SC. Publicação de cronograma com data de ativação em homologação e produção de regras de validação para o Estado de Santa Catarina, conforme datas estabelecidas no item 3.6.1. Inclusão das regras de validação N14a-10, N14a-20 e I05h-10 a critério da UF. Incluída regras de validação N14a-10, N14a-20 para NF-e, visando validar respectivamente a obrigatoriedade e o correto preenchimento do campo código de benefício fiscal de redução de BC do Grupo Tributação do ICMS= 51 (tag:ICMS51/cBenefRBC). Incluída regra de validação I05h-10 para NF-e e NFC-e, visando validar o correto preenchimento do campo código de crédito presumido (tag: cCredPresumido). Estas regras de validação serão aplicadas neste momento apenas para o Estado de Santa Catarina, conforme datas estabelecidas no item 3.6.1. A regra I05h-10 (facultativa) se aplica a NF-e e NFC-e. Regra: Se informado código de crédito presumido (tag: cCredPresumido): - Verificar se código de crédito presumido existe, está vigente e corresponde a um código de crédito presumido, conforme tabela de código de benefício fiscal por UF publicada no Portal da Secretaria de Fazenda da respectiva UF (NT 2019.001). Observação 1: Implementação a critério da UF, por modelo de DF-e. Rejeição: 664: Informado código de crédito presumido (cCredPresumido) incorreto, inexistente ou incompatível na UF [nItem: nnn] A regra N14a-10 (facultativa) se aplica somente a NF-e. Regra: Se CST de ICMS = 51 (diferimento) e informado tag:ICMS51/pRedBC (id:N14) maior que zero, é obrigatório informar cBenefRBC (id:N14a) (NT 2019.001). Observação: Implementação a critério da UF. Exceção 1: a RV não se aplica quando Finalidade de emissão da NFe (tag: finNFe) igual a Devolução de Mercadoria e Identificador de local de destino da operação (tag: idDest) igual a Operação interestadual ou com o Exterior. Exceção 2: a critério da UF, a RV não se aplica quando Finalidade de emissão da NF-e (tag: finNFe) igual a Devolução de Mercadoria; Rejeição: 665: Não informado código de benefício fiscal de redução de BC (cBenefRBC) quando percentual de redução de BC for maior que zero no grupo de tributação de diferimento [nItem: nnn] A regra N14a-20 (facultativa) se aplica somente a NF-e. Regra: Se CST de ICMS = 51 (diferimento) e informado tag:ICMS51/cBenefRBC (id:N14a): - Verificar se código de benefício fiscal de redução de BC (cBenefRBC) existe, está vigente e corresponde a um código de benefício de redução de base de cálculo (coluna CST 20 = SIM), conforme tabela de código de benefício fiscal por UF publicada no Portal da Secretaria de Fazenda da respectiva UF (NT 2019.001). Observação: Implementação a critério da UF. Exceção 1: a RV não se aplica quando Finalidade de emissão da NFe (tag: finNFe) igual a Devolução de Mercadoria e Identificador de local de destino da operação (tag: idDest) igual a Operação interestadual ou com o Exterior. Exceção 2: a critério da UF, a RV não se aplica quando Finalidade de emissão da NF-e (tag: finNFe) igual a Devolução de Mercadoria; Exceção 3: a critério da UF, a RV não se aplica quando Finalidade de emissão da NF-e (tag: finNFe) igual a NF-e de Ajuste; Exceção 4: a critério da UF, a RV não se aplica quando Tipo de Operação (tag: tpNF) igual à Entrada. Rejeição: 666: Informado código de benefício fiscal de redução de BC (cBenefRBC) incorreto, inexistente ou incompatível na UF [nItem: nnn] Cronograma de ativação:

Bom dia @Diogo Loff, Muito obrigado pela colaboração, já foi criado a TK-5922 para atualização do arquivo INI.

Boa tarde @Renan S, Realmente se faz necessário remover esses códigos de status, já criei a TK-5920 para que seja feita as alterações necessárias. Muito obrigado pela colaboração.

Bom dia @Antonio Alexanadre, Abra em um navegador as duas URLs abaixo e compare: https://ribeiraodasneves.quasar.srv.br/nfe/snissdigitalsvc?wsdl https://issqn.ribeiraodasneves.quasar.srv.br/nfe/snissdigitalsvc?wsdl A segunda URL é a que se encontra no arquivo ACBrNFSeXServicos.ini e a unica diferença é o "issqn" no inicio.

Bom dia @Datacaixa, Eu acredito que o Ambiente Nacional (onde o serviço de Distribuição DF-e) esta implementado deve fazer um controle por CNPJ/CPF e numero do NSU já baixado. Sendo assim se uma empresa já baixou todos os documentos até o NSU 1500, para o Ambiente Nacional não faz sentido essa mesma empresa querer baixar novamente os documentos a partir do NSU 1000, por exemplo.

@Diogo Loff, Apliquei a mesma alteração feita no IPM no Betha, como a cidade mencionada usa a versão 1.00, a alteração foi realizada no TratarXmlRetornado para esta versão. Caso o problema ocorra em outra cidade que use a versão 2.02 vai ser necessário fazer a mesma coisa. Ficou da seguinte forma a alteração: function TACBrNFSeXWebserviceBetha.TratarXmlRetornado( const aXML: string): string; begin Result := ConverteANSIparaUTF8(aXML); Result := RemoverDeclaracaoXML(Result); Result := inherited TratarXmlRetornado(Result); Result := StringReplace(Result, '&', '\s\n', [rfReplaceAll]); Result := ParseText(Result); Result := RemoverPrefixosDesnecessarios(Result); Result := RemoverCaracteresDesnecessarios(Result); end; Faça essa alteração na unit Betha.Provider, reinstale o ACBr e faça novos testes. Caso resolva o problema me avise que eu enviarei para o SVN.

Boa tarde @cdsistemas, Qual é o valor da propriedade de configuração TimeOut configurada? A minha sugestão é atribuir um valor acima de 40 mil. Outra coisa, se ao enviar um evento seja ele de cancelamento ou carta de correção, caso ocorra erro você pode usar o método Consultar da seguinte forma: ACBrNFe1.Consultar(sChaveNFe, True); Você passa como parâmetro a chave da NFe para o qual o evento foi enviado, o segundo parâmetro True faz com que se no retorno dessa consulta constar algum evento o mesmo vai ser extraído e salvo em disco (se estiver configurado para salvar em disco).

Boa tarde @Gabriel Lacerda, Temos que olhar aqui: <xsd:complexType name="tcInfDeclaracaoPrestacaoServico"> <xsd:sequence> <xsd:element name="Rps" type="tcInfRps" minOccurs="0" maxOccurs="1" /> <xsd:element name="Competencia" type="xsd:date" minOccurs="1" maxOccurs="1" /> <xsd:element name="Servico" type="tcDadosServico" minOccurs="1" maxOccurs="1" /> <xsd:element name="Prestador" type="tcIdentificacaoPrestador" minOccurs="1" maxOccurs="1" /> <xsd:element name="Tomador" type="tcDadosTomador" minOccurs="0" maxOccurs="1" /> <xsd:element name="Intermediario" type="tcDadosIntermediario" minOccurs="0" maxOccurs="1" /> <xsd:element name="ConstrucaoCivil" type="tcDadosConstrucaoCivil" minOccurs="0" maxOccurs="1" /> <xsd:element name="RegimeEspecialTributacao" type="tsRegimeEspecialTributacao" minOccurs="0" maxOccurs="1" /> <xsd:element name="OptanteSimplesNacional" type="tsSimNao" minOccurs="1" maxOccurs="1" /> <xsd:element name="IncentivoFiscal" type="tsSimNao" minOccurs="1" maxOccurs="1" /> </xsd:sequence> <xsd:attribute name="Id" type="tsIdTag" /> </xsd:complexType> Se na definição desse tipo não consta as referidas tags isso significa que não é possível. Por outro lado veja esta outra definição: <xsd:complexType name="tcInfNfse"> <xsd:sequence> <xsd:element name="Numero" type="tsNumeroNfse" minOccurs="1" maxOccurs="1" /> <xsd:element name="CodigoVerificacao" type="tsCodigoVerificacao" minOccurs="1" maxOccurs="1" /> <xsd:element name="DataEmissao" type="xsd:dateTime" minOccurs="1" maxOccurs="1" /> <xsd:element name="NfseSubstituida" type="tsNumeroNfse" minOccurs="0" maxOccurs="1" /> <xsd:element name="OutrasInformacoes" type="tsOutrasInformacoes" minOccurs="0" maxOccurs="1" /> <xsd:element name="ValoresNfse" type="tcValoresNfse" minOccurs="1" maxOccurs="1" /> <xsd:element name="ValorCredito" type="tsValor" minOccurs="0" maxOccurs="1" /> <xsd:element name="PrestadorServico" type="tcDadosPrestador" minOccurs="1" maxOccurs="1" /> <xsd:element name="OrgaoGerador" type="tcIdentificacaoOrgaoGerador" minOccurs="1" maxOccurs="1" /> <xsd:element name="DeclaracaoPrestacaoServico" type="tcDeclaracaoPrestacaoServico" minOccurs="1" maxOccurs="1" /> </xsd:sequence> <xsd:attribute name="Id" type="tsIdTag" /> </xsd:complexType> Note que ela tem a definição da tag OutrasInformacoes, mas esse tipo se refere a InfNfse, ou seja, a definição do layout da NFS-e, como o XML da NFS-e é gerado pelo provedor a tag poderá existir no XML caso a prefeitura peça ao provedor gerar essa tag com algumas informações.

Boa tarde @Diogo Loff, Qual é a cidade que esta ocorrendo o erro de UTF-8 com o provedor Betha e com o provedor IPM? No caso do IPM foi feita uma alteração na função TratarXmlRetornado visando converter o XML retornado para UTF-8.