BigWings

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.

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>

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.

Tentou deletar tudo e fazer um check out do zero?

O componente é open-source e colaborativo, então só depende de alguém fazer. Se desejar contribuir com essa implementação, basta anexar os fontes alterados aqui que será analisado e se aprovado, enviado ao repositório.

O retorno em branco geralmente acontece quando houve algum retorno do webservice, mas o componente não conseguiu interpretá-lo para exibir a mensagem. Você pode configurar o componente para gravar os arquivos de envio e retorno, e analisar o XML de retorno para descobrir o que está errado. Anexe eles aqui se desejar.

Difícil dizer, sem ver o código. Falta de chamada ao Application.ProcessMessages pode causar essa sensação de travamento da aplicação.

Me parece que o componente já faz o tratamento das duas formas de retorno, então não há necessidade de alterações. function TNFeEnvEvento.TratarResposta: Boolean; var Leitor: TLeitor; I, J: integer; NomeArq, PathArq, VersaoEvento, Texto: String; begin FEvento.idLote := idLote; FPRetWS := SeparaDadosArray(['nfeRecepcaoEventoResult', 'nfeRecepcaoEventoNFResult', 'nfeResultMsg'],FPRetornoWS ); Unit: ACBrNFeWebservices.pas