BigWings

Qual UF?

https://mdfe-portal.sefaz.rs.gov.br/Site/DownloadArquivoNovo/?tipoArquivo=3&nomeArquivo=MDFe_Nota_Tecnica_2018_001.pdf

O WS de consulta de cadastro realmente não retorna informação do ambiente, homologação ou produção. Estranho, já que pela consulta no cadastro centralizado de contribuintes essas informações podem ser divergentes... Incluí as URL no repositório:

Já no repositório:

Faça o teste com o arquivo anexo, sem a alteração no DANFSE. pnfsNFSeR.pas

Me parece que essa alteração vai causar efeito colateral nos demais provedores. O mais indicado seria alimentar a propriedade ValorIssRetido na leitura do XML, especificamente para esse provedor.

Nenhum motivo, apenas não se tinha conhecimento de as URL já terem sido divulgadas. Notei diferença nas URL do QRCode para NFCe do arquivo postado pelo @Felipe E. Resende Mesquita para NFCe 4.00 e as divulgadas no portal da SEFAZ e no site do ENCAT. Qual arquivo ACBrNFeSevicos.ini você usou?

Veja se a configuração IncluirQRCodeXMLNFCe está marcada.

Veja com a SEFAZ sobre essa rejeição, ela foi alterada a partir da versão 1.20 da NT 2016.002, permitindo a informação do transportador, como o André comentou.

O certificado á A1 ou A3? Já testou o mesmo pra ver se consta a chave privada?

Segundo a NT, o máximo de atraso é de 24 horas. Estão informando a hora e fuso horário de emissão corretos no XML?

Recomendo a criação de uma chave estrangeira nessa coluna, o FB já cria o índice automaticamente. Sem o índice, ele precisa ler todos os 100.000 registros, 50.000 vezes... um for select linha a linha na tabela de contas a receber seria mais rápido.

Qual o banco? Você precisa atualizar TODA a tabela de clientes? São 50.000 selects e updates, é normal demorar... Tem índice para a coluna CODCLI na tabela ARECEBER? Tem triggers before update ou after update na tabela de clientes que possam estar executando desnecessariamente?

Você não está informando na sua rotina os valores totais da nota. <total> <ICMSTot> <vBC>0.00</vBC> <vICMS>0.00</vICMS> <vICMSDeson>0.00</vICMSDeson> <vFCP>0.00</vFCP> <vBCST>0.00</vBCST> <vST>0.00</vST> <vFCPST>0.00</vFCPST> <vFCPSTRet>0.00</vFCPSTRet> <vProd>0.00</vProd> <vFrete>0.00</vFrete> <vSeg>0.00</vSeg> <vDesc>0.00</vDesc> <vII>0.00</vII> <vIPI>0.00</vIPI> <vIPIDevol>0.00</vIPIDevol> <vPIS>0.00</vPIS> <vCOFINS>0.00</vCOFINS> <vOutro>0.00</vOutro> <vNF>0.00</vNF> </ICMSTot> </total>

Na NFe 4.00 não é mais permitido informar esses dados para operações interestaduais. Conforme NT 2016.002 v. 1.42: Em operações internas, fica a critério de cada UF. Dados do transportador, caso haja, já são vinculados à nota na emissão do CTe. Dados dos veículos e condutores são vinculados na emissão do MDFe, de emissão obrigatória em operações interestaduais.

Os boletos acima de 800,00 precisam ser registrados no banco. Você está fazendo o processo de geração de remessa e envio dela para o banco?

Não entendi... Na NFe 3.10 existia apenas a tag indPag que determinava pagamento à vista a prazo ou outros. Na NFe 4.00 a tag indPag foi removida e foi incluído a obrigatoriedade do grupo de pagamentos, sem previsão de impressão desses pagamentos no DANFE.

Você tem a URL?

Para Daruma na USB o baud rate tem que ser 115200.

Fazendo a validação do XML contra os XSD do ISSNet pelo Notepad++ acusa erro no schema: Unable to parse schema file. Parsing error at line 262: Element '{http://www.w3.org/2001/XMLSchema}pattern': The value '^20(?:09|[1-9]\d)(?:0[1-9]|1[0-2])$' of the facet 'pattern' is not a valid regular expression. Essa restrição consta no arquivo tipos_simples.xsd. <xsd:simpleType name="tsCompetencia"> <xsd:restriction base="xsd:nonNegativeInteger"> <xsd:pattern value="^20(?:09|[1-9]\d)(?:0[1-9]|1[0-2])$"></xsd:pattern> </xsd:restriction> </xsd:simpleType> Não tenho familiaridade com expressões regulares pra dizer se ela está correta ou não, mas se você comentar essa linha, a validação passa: <xsd:simpleType name="tsCompetencia"> <xsd:restriction base="xsd:nonNegativeInteger"> <!-- xsd:pattern value="^20(?:09|[1-9]\d)(?:0[1-9]|1[0-2])$"></xsd:pattern --> </xsd:restriction> </xsd:simpleType> Minha sugestão é que entre em contato com a prefeitura ou o provedor e peça schemas atualizados, se é que há. PS: Definindo a configuração SSLXmlSignLib como xsMsXML a validação funciona sem alterações no XSD. Provavelmente essa é a razão de deixar de funcionar após atualização, recentemente houve a alteração do padrão dessa propriedade para xsLibXML2 quando SSLLib = libWinCrypt.

Apenas GTIN cadastrados poderão ser informados nas tags cEAN e cEANTrib. Leia a NT 2017.001 v. 1.20 que trata das validações do GTIN.

O ACBr apenas não vai gerar o grupo se informar a tag pICMSInterPart zerado. Informando como no XML anexado deve funcionar sim.

Tentou passar true no quarto parâmetro?

Correção enviada ao repositório. Obrigado pela colaboração.

Este é o arquivo enviado ao webservice. Este é o arquivo supostamente retornado pelo webservice. Tem muito pouca informação nele, apenas inscrição do prestador, número e série do RPS, número e chave de verificação da NFSe. Não identifiquei nos fontes como é feito a leitura do retorno nesse caso. Você disse que o problema é no envio de 1 RPS, enviando mais de um o problema não ocorre? Para enviar 1 RPS ou enviar mais de 1 você está usando métodos diferentes do ACBrNFSe? Respondeu a minha pergunta. Faça o teste... creio que pelo método Gerar o componente esteja ignorando alguma peculiaridade desse provedor.