BigWings

Acho que faz sentido carregar o endereço da NFe. O que não faz sentido pra mim é o destinatário da mercadoria ficar no RJ e a mercadoria estar sendo enviada pra SP.

Realmente tinha um erro no programa exemplo, nessa rotina. Enviei correção para o repositório, rev. 19955. Favor atualizar os fontes e testar novamente.

Aparentemente está informando o município de descarregamento errado:

Os dois XML que você anexou estão validando normalmente, pela opção "Validar XML" do programa exemplo. Tem certeza que está selecionando o XML correto ao selecionar a opção "carregar XML e enviar"?

Aqui sempre vai ler o mesmo arquivo. Use: ACBrSAT1.CFe.LoadFromFile(OpenDialog1.Files[a]); A linha abaixo também vai te gerar um erro de index out of bounds.

Pela opção "Subject Name" ou "Leitura de X509"

No programa exemplo do componente ACBrNFe tem exemplo de como obter as informações do certificado.

Pelo layout o CST 60 não é aceito para o CTe-OS. Os CST aceitos são 00, 20, 40, 41, 51, 90 - Outros, 90 - ICMS devido a outra UF e 90 - Simples Nacional.

Você pode fazer algo assim: No arquivo SigIss.ini: [URL_P] RecepcaoLoteRPS=https://%URL_P%.sigiss.com.br/%URL_P%/ws/sigiss_ws.php [URL_H] RecepcaoLoteRPS=https://teste%URL_H%.sigiss.com.br/%URL_H%/ws/sigiss_ws.php No arquivo Cidades.ini: [3127701] Nome=Governador Valadares UF=MG Provedor=SigIss URL_P=valadares URL_H=valadares [3529005] Nome=Marilia UF=SP Provedor=SigIss URL_P=marilia URL_H=marilia Dessa forma creio atender ambas as cidades. PS: Me parece que a URL de homologação para Governador Valadares está errada ou offline, retorna erro 404.

SL := TStringList.Create; try SL.Text := StringReplace(AStr, '@', sLineBreak, [rfReplaceAll]); SL.SaveToFile('C:\TEMP\RESULTADO.TXT'); finally SL.Free; end;

O ACBr sempre vai formatar novamente o nosso número de acordo com o manual do banco. Com alguns testes consegui chegar no mesmo nosso número e linha digitável gerados pelo banco, informando: - Convenio: 61461 - Nosso número: 33814

O nosso número impresso no boleto é formatado, incluindo o código do convênio e em alguns casos o dígito verificador. Você precisa informar para o componente apenas o nosso número sequencial. E veja o que o Juliomar comentou, nem sempre é possível replicar um boleto que o próprio banco emitiu, eles podem usar algoritmo não disponível pra quem emite por software próprio.

No XML apareceu \n\n então está correto de acordo com o que foi te orientado. Tem um exemplo de XML e geração do DANFSE em que a quebra é feita?

Provavelmente sim. Faça o teste.

Desde a versão 4.00 não existe mais duplicatas na NFe, o grupo agora é denominado "Parcelas". Você pode informar em informações complementares se desejar.

Creio que nesse trecho falta transferir o número de série do certificado selecionado para o objeto ACBrNFe1. ACBrNFe1.Configuracoes.Certificados.NumeroSerie := A.NumeroSerie;

Vou fechar o tópico pois já desvirtuou do assunto inicial.

O número da parcela deve ser sequencial com 3 dígitos: O correto é:

Já foi feita essa alteração para Governador Valadares:

Onde está InfViagens troque para infViagens. Em minúscula.

O PDF é gerado pelo portal da prefeitura ou pela sua aplicação com ACBr? Caso seja na sua aplicação, a impressão pelo portal da prefeitura ficou correta? E na sua aplicação está usando o componente de impressão em Fast ou Fortes Report?

Não faz muito sentido ter esse erro apenas quando informados dados do consumidor... Ele pode acontecer quando os schemas estão num caminho no formato UNC (\\servidor\compartilhamento) ou algum .xsd está corrompido.

Você fez a pré-homologação da planilha pra verificar a diferença? Testei com dados que homologamos uns meses atrás e aparentemente a rotina de cálculo da linha digitável continua igual.

Pela regra já era pra estar obrigatório há anos. Tem comunicado em alguma outra SEFAZ?

Debugando você deve descobrir. Pode ser alguma classe descendente sobrepondo esse método.