BigWings

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.

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.

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?

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.

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?

Verifique se a impressora padrão definida no Windows está numa impressora de bobina.

Validando o XML de envio do evento 1-ped-eve.xml, no validador da SEFAZ-RS, validou normalmente: https://www.sefaz.rs.gov.br/NFE/NFE-VAL.aspx Nesse caso, é preciso entrar em contato com a SEFAZ e perguntar o motivo da rejeição.

Movido.

A vírgula no logradouro do emitente faz com que o ACBr entenda que ali é o final do texto do .ini. Use a sintaxe correta: delimite o conteúdo do texto com aspas duplas: NFe.CriarEnviarNFe(" [infNFe] ... vTroco= " ,,,,COMANDA,1,,1,)

https://www.fazenda.sp.gov.br/nfe/perguntas_frequentes/respostas_VIII.asp Neste sentido também o artigo 41 da Portaria CAT 162/2008: Artigo 41 - Na hipótese em que o contribuinte credenciado a emitir NF-e exerça atividade sujeita à incidência do Imposto Sobre Serviços de Qualquer Natureza - ISSQN, poderá utilizar os campos da NF-e relativos ao ISSQN, desde que a legislação municipal assim lhe permita. Parágrafo único - O emitente deverá disponibilizar o arquivo digital da NF-e ou o respectivo DANFE a Administração Tributária municipal, conforme o disposto na respectiva legislação. http://www.sped.fazenda.mg.gov.br/spedmg/nfe/Perguntas-Frequentes/respostas_vii/index.html Na minha interpretação, sem uma autorização expressa da prefeitura, não se deve fazer emissão da NFe ou NFCe conjugada , ou apenas com serviços, em SP ou MG, e sim emitir a NFSe apenas. Omitir informação gerada em documento fiscal no SPED pode ser visto pela fiscalização como sonegação por parte da empresa.

Que saiba a permissão de emitir NFe ou NFCe com serviços sujeitos ao ISS depende de legislação municipal. Mesmo que a SEFAZ do estado autorize uma nota contendo serviços, isso não significa que a prática é permitida pelo município. Os municípios sempre vão dar preferência à NFSe.

Além da configuração indicada pelo Italo, veja também o seu arquivo ACBrNFeServicos.ini, se contém as URL para a versão 4.00 da NFCe.

O código atual faz o esperado, caso seja configurado a versão do componente como veqr000 e usada versão 4.00 do XML, ele será ajustado para veqr100. Para usar o QrCode 2.00, basta configurar a propriedade ACBrNFe1.Configuracoes.Geral.VersaoQrCode = veqr200. Com a sua alteração fica impossibilitado o uso do QrCode 1.00 (que não é mais usado, mas mantido por compatibilidade, para recriar um XML antigo, por exemplo).

No teu XML falta a versão do evento. with ACBrCTe1.EventoCTe.Evento.New do begin infEvento.cOrgao := 41; infEvento.versaoEvento := '1.00'; Tanto cOrgao quando a configuração ACBrNFe1.Configuracoes.WebServices.UF deve ser a UF do emitente do CTe, no caso, o PR.

Está confundindo causa/efeito. O XML com a tag nfeProc é montado pelo ACBrNFe após o recebimento do protocolo de autorização, ele não é o XML enviado para o webservice. Configure o componente para gravar os arquivos de envio e retorno e anexe aqui os arquivos *-env-lot.xml e *-env-lot-soap.xml onde houve a rejeição.

O fórum é voltado a desenvolvedores, o ACBr não lida com usuários finais, nem desenvolve software destinado a usuários finais, e sim uma suíte de componentes e um aplicativo de integração (ACBrMonitorPLUS). Sugiro que direcione essas questões para o suporte da aplicação usada pelo teu cliente.

O método GerarXML gera o conteúdo do arquivo apenas internamente, o arquivo XML de envio de evento é gerado caso você use o método EnviarEvento. Para visualizar o XML como é feito no demo do componente, usando o GerarXML, experimente trocar as linhas acima por: ACBrCTe1.EventoCTe.GerarXML; MemoResp.Lines.Text := ACBrCTe1.EventoCTe.Gerador.ArquivoFormatoXML; LoadXML(MemoResp, WBResposta); Se estiver usando EnviarEvento: ACBrCTe1.EnviarEvento(1); MemoResp.Lines.Text := ACBrCTe1.WebServices.EnvEvento.RetWS; LoadXML(MemoResp, WBResposta);

Verifique a configuração das margens no componente DANFE.

É um problema conhecido. Quando você não define o espaçamento entre linhas o PosPrinter usa o espaçamento padrão da impressora, mas o componente não conhece esse valor. Então na impressão do QRCode lateral e informação do consumidor, é usado a altura do QRCode como altura máxima dessa região. Como o QRCode agora está reduzido acaba cortando as informações do consumidor + NFCe. Para resolver você só precisa informar um espaçamento entre linhas: ACBrNFeDANFeEscPos1.PosPrinter.EspacoEntreLinhas := <xxx>; Alterar a disposição das informações do consumidor e identificação da NFCe vai contra o manual de especificações do DANFe NFCe e QrCode.

Já tentou o "Find in files" do Delphi?