BigWings

Caso seja necessário imprimir item a item, pode ser usado a tag infAdProd para imprimir as informações. Ou infCpl se for preciso apenas o total.

Sem erros também (parece ser o mesmo arquivo).

Não entendi a parte do número da conta estar vindo formatado com 10 dígitos... Fiz teste desta forma e não notei erros com o seu arquivo: if not OpenDialog1.Execute then Exit; ACBrBoleto1.DirArqRetorno := ExtractFilePath(OpenDialog1.FileName); ACBrBoleto1.NomeArqRetorno := ExtractFileName(OpenDialog1.FileName); ACBrBoleto1.Banco.TipoCobranca := cobBancoob; ACBrBoleto1.Cedente.Agencia := '3064'; ACBrBoleto1.Cedente.AgenciaDigito := '0'; ACBrBoleto1.Cedente.Conta := '000000011885'; ACBrBoleto1.Cedente.ContaDigito := '0'; ACBrBoleto1.Cedente.CNPJCPF := '23.216.110/0001-90'; ACBrBoleto1.Cedente.TipoInscricao := pJuridica; ACBrBoleto1.LerRetorno;

Alguns CST especiais precisam ser informados em alfanumérico, "SN" para o CTe, "60rep" para o CST 60 do grupo de repasse de ICMS são exemplos. O componente trabalha com enumerados para o CST. Por causa de como a linguagem trabalha com enumerados, no método que converte o CST informado no INI para um enumerado vai sempre retornar o primeiro CST (00) caso seja informado um CST incorreto. function StrToCSTICMS(out ok: boolean; const s: string): TpcnCSTIcms; begin result := StrToEnumerado(ok, s, ['00', '10', '20', '30', '40', '41', '45', '50', '51', '60', '70', '80', '81', '90', '91', 'SN', '10part', '90part', '41rep', '60rep'], [cst00, cst10, cst20, cst30, cst40, cst41, cst45, cst50, cst51, cst60, cst70, cst80, cst81, cst90, cstICMSOutraUF, cstICMSSN, cstPart10, cstPart90, cstRep41, cstRep60]); end;

Pelo manual anexado a coluna 58 contém o dígito da agência e não o número da conta...

3.1 - Não faça flooding - Inundar o fórum com posts repetidos, com a mesma dúvida ou as mesmas palavras é chamado de flooding. Isso é proibido. Apenas um post feito no lugar certo é suficiente. Pesquise antes de postar, talvez sua dúvida já está respondida em outro post. Favor leia as regras do fórum.

Testei com o seu txt e os dados do responsável técnico foram gerados normalmente no XML. Verifique a sua versão do ACBrMonitorPLUS.

Pode ser algum problema na migração de dados de um provedor para o outro... Precisa entrar em contato com eles ou a prefeitura e verificar o cadastro do tomador.

E qual a dúvida? A mensagem parece bem clara.

Nesse caso você gera um novo número aleatório...

Veja qual valor está passando para a tag tpEmit. Para o tpEmit = 1 (prestador de serviço de transporte) você deve informar CTe. Para o tpEmit = 2 (transportador de carga própria) ou 3 (transportador que emitirá CT-e globalizado) você deve informar NFe. Caso informe documento divergente do tpEmit o componente vai ignorar o mesmo na geração do XML.

Qualquer linguagem deve ser capaz de gerar um número aleatório... Se você usa o ACBr, pode informar 0 para o campo cNF e deixar o componente gerar o código aleatório. Mas lembre que a sua aplicação deve armazenar esse código para poder recuperar a chave da NFe se necessário.

2.2 - Permaneça no assunto - Quando tiver uma dúvida diferente do assunto no tópico, poste em novo tópico. Não use algo equivalente a "aproveitando o gancho... [dúvida não relacionada com o tópico aqui]". Favor leia as regras do fórum.

Esse erro é de validação local, onde ainda não houve tentativa de comunicação com a SEFAZ. A mensagem está acusando que o campo infRespTec não deveria existir no XML, o que é incorreto. Verifique novamente a pasta de Schemas configurada no componente no momento do envio da NFCe.

A configuração para salvar os arquivos está marcada?

Pelo método DistribuicaoDFe você pode capturar todos os eventos que forem sendo emitidos contra a NFe seja pelo destinatário, terceiros ou o fisco. Não é necessário saber que outros eventos foram gerados para a NFe para a emissão da carta de correção. O número sequencial do evento na carta de correção deve ser de 1 a 20, levando em consideração apenas outras cartas de correção já emitidas para aquela NFe, ou seja, a não ser que tenha sido emitida carta de correção por outra aplicação para a mesma nota, o sistema deveria saber.

Nesse caso, na minha opinião, há uma contradição entre o que diz o manual e como os schemas estão montados: O manual diz que o grupo do FCP-ST é filho do grupo N10h (ICMSSN900), então o grupo poderia ser informado independentemente do grupo referente ao ICMS-ST (que também tem a tag N10h como pai) ter sido também informado. Pelo schema, porém, o grupo FCP-ST está dentro do grupo referente ao ICMS-ST, o que impossibilita informar o FCP-ST separadamente. Só não sei que tipo de operação pode ter FCP-ST sem ter também o ICMS-ST, sendo que o primeiro é apenas um complemento...

Um erro comum é fazer uma segunda chamada a NotasFiscais.Add para preencher uma informação específica, como nesse caso, o responsável técnico. Então verifique pelo debug quantas NFe está tentando enviar.

Uma coisa é a informação do CSOSN, outra é o grupo do XML em que ele deve ser criado. Basta olhar o manual, os CSOSN 102, 103, 300 e 400 devem ser informados no grupo ICMSSN102.

Veja o tópico abaixo:

Pode anexar o XML?

Usando o comando informado no log o ACBrMonitorPLUS está gerando o CST 00 e não o 60. Em vez de: [ICMS001] orig=0 CST=060 Informe: [ICMS001] orig=0 CST=60

Veja que as versões 32/64 bits se referem à arquitetura do teu executável e não do sistema operacional. Se você compila para 32 bits deve copiar as DLLs de 32 bits, independentemente de o SO ser 64 bits.

A regra de exigência do responsável técnico foi ativada hoje pela SEFAZ. Provavelmente no sábado ainda não estava gerando os dados no XML mas estava sendo aceito por ela mesmo assim. Para outro assunto favor abrir novo tópico.

O XML anexado não passa na validação do XML, tanto pelo ACBr como pelo validador da SEFAZ-RS. Fazendo a consulta pelo portal, consta um documento do tipo outros como documento fiscal: Esse XML foi obtido como? Já tentou baixar novamente ele pelo portal pra comparar?