Italo Giurizzato Junior

Boa noite Liandro, Você disse que realizou testes utilizando a SEFAZ-SP e RS. A rejeição ocorre nas duas SEFAZ ou somente na do RS? Se a rejeição ocorre em apenas em uma delas, o problema pode ser a cadeia de certificados.

Boa tarde Pedro, Que eu saiba, não. Pelo que eu pude ver esse provedor não segue o padrão ABRASF e nem o DSF.

Boa tarde Fabiano, Não, o ACBrNFeMonitor só atende a NF-e. Existe a intensão de criar um monitor para NFS-e ou fazer com que o ACBrNFeMonitor emita a NFSe. Isso vai depender do pessoal que cuida do monitor, vamos aguardar.

Boa tarde Daniel, Alteração realizada e disponibilizada. Agora é só disponiblizar uma nova versão do ACBrInstall.

Boa tarde Jander, Como o manual não deixa claro qual é a finalidade dessa informação, podemos ter variais interpretações. Uma transportadora que eu conheço, para eles: Pago => Remetente é o Tomador do serviço A pagar => Destinatário é o Tomador do serviço Sendo que existe uma outra TAG onde nós informamos quem é o tomador do serviço. O que nos faz interpretar diferente: Pago é quando o valor do frete já foi pago pelo Tomandor do serviço, mesmo antes do serviço de transporte ter sido realizado. A pagar é quando o Tomador do serviço só vai pagar o valor total do frete quando o serviço de transporte for concluido. Outros poderiamos dizer que o pagamento vai ser feito de forma parcelada. Veja bem isso é uma interpretação.

Boa tarde, Se você utiliza o componente ACBrNFe, favor ter em mãos o Manual versão 5.0 da NFe, nele você encontra a estrutura completa do XML. As propriedades do componente que recebem os dados seguem a mesma nomenclatura do manual. Portanto não tem segredo é só procurar no manual que você vai achar. Detalhe, que você ja deve saber, o valor do frete deve ser informado em dois lugares: 1. o valor do frete do item 2. o valor total do frete ou seja a soma dos fretes dos itens que compõe a nota. Antes que eu me esqueça, ao postar favor prestar mais atenção, você postou no tópico que trata do componente ACBrNFSe (nota de serviço).

Bom dia EFV, Você esta passando errado, pois dessa forma você esta informando o RNTRC do proprietario do veiculo quando o mesmo não é da transportadora. No quadro IDENTIFICAÇÃO DO CONJUNTO TRANSPORTADOR devemos informar o RNTRC da transportadora e a forma correta é: rodo.RNTRC := qryAuxiliar.fieldbyname('rntrc').AsString; Outra coisa, o DACTE que você se refere é o que foi feito em Quick Report ou Fast Report? A carga é fracionado ou lotação? O DACTE feito em Quick Report, muda a sua aparencia quando mudamos de carga fracionada para lotação.

Bom dia leufmt, Sim, a explicação esta correta. No caso da NFe podemos enviar um lote de eventos, até 20 eventos, cada evento poderar fazer referencia a uma nota diferente e consequentemente cada uma vai ter o seu numero sequencia de evento. Dentro do lote sempre vamos ter: [EVENTO001] mas poderemos ter também: [EVENTO002], [EVENTO003], (...) [EVENTO020]

Bom dia Wislei, O DACTE feito em Quick Report possui o segundo código de barras conforme o manual. No que diz respeito ao DACTE feito em Fast Report, não sei lhe dizer, pois não utilizo. Fica ai a sugestão, utilize o DACTE feito em Quick Report.

Bom dia Liandro, Primeiramente precisamos saber se o programa da bSoft utiliza ou não o componente ACBrCTe. Vamos supor que não utiliza, sendo assim nos resta a desconfiar de duas coisas: O Certificado, já que você utilizou o mesmo, eu em particular não acredito que seja ele. O WebService, que esta com algum problema e esta retornando essa rejeição. Se eles utilizam o ACBrCTe, não acredito que seja o componente, pelo simples fato dos testes que realizei, nenhum ocorreu rejeição. A minha sugestão é entrar em contato com a SEFAZ e expor o problema.

Bom dia Liandro, Sim, temos um programa exemplo, dentro da pasta: ...\Exemplos\ACBrCTe\Delphi. Basta você alterar a rotina que alimenta o componente, colocando dados ficticios.

Bom dia Pavani, Desculpe, não entendi o titulo do seu post, por favor seja mais objetivo e claro.

Boa tarde Daniel e Isaque, Verificando o ACBr.inc notei que quando a versão do Delphi é inferior a 7 ou seja a 6, é definido as diretivas de compilação ACBrNFeOpenSSL e ACBrCTeOpenSSL, vejam:

Boa tarde Carlos, O que estava errado?

Boa tarde Medreis, A chamada: ACBrNFSe1.CancelarNFSe(sCodigo); pressupõe que o XML da NFSe que pretende-se cancelar foi carregado usando o LoadFromFile. Note que o CancelarNFSe executa uma função definida em ACBrNFSeWebServices chamada CancelaNFSe que possui 2 parametros sendo que o segundo é CarregaProps. É passado para esse parametro o valor True, indicando desta forma que o componente deve se utilizar das propriedades que foram carregadas ao Ler o XML. Note também que em ACBrNFSeWebService temos uma outra função com o mesmo nome, mas esta possui muito mais parametros, parametros estes necessários para efetuar o cancelamento. No meu post #11 eu apresento a sintaxe desta segunda chamada, apesar dela possuir mais parametros, não há necessidade de carregar o XML. Note também que essa função chama a outra e passa o valor False no segundo parametro, informando que não é para carregar as propriedades, visto que elas foram informadas.

Bom dia Robson, Se o seu cliente necessita com uma certa urgencia, por que nesse primeiro momento, você não utilzia o emissor gratuito da SEFAZ? Após a emissão, me parece que ele possui uma opção para exportar o XML. Aqui mesmo no fórum existem vários post que contem XML de CT-e anexados.

Bom dia Liandro, Ontem a noite, usando a minha aplicação, lancei dois conhecimentos, emiti o primeiro sem nenhum problema, mandei emitir o segundo, sem nenhum problema. Depois solicitei o cancelamento do primeiro, também o cancelamento foi realizado sem nenhum erro, solicitei o cancelamento do segundo, idem. Nenhum erro foi apresentado, logo o problema deve ser com a sua aplicação. Você esta utilizando as DLLs, que vem junto com o ACBr, principalmente a Capicom ? Depois do XML gerado assinado, não existe algo que por ventura esteja alterado o XML?

Boa noite Luciano, O DACTE em questão é o que foi feito em Quick Report Se sim, até onde eu me lembro, mandei para o SVN uma atualização do DACTE que formata corretamente o CNPJ e o CPF. Inclusive criei uma nova função chamada FormataCNPJCPF que detecta o tipo de documento e formata-o.

Boa noite Mark Apollo O primeiro arquivo se refere ao envio e pelo que eu vi, você esta usando o programa exemplo, inclusive com os dados ficticios dele. O segundo arquivo se refere ao retorno que contem o numero do recibo. Tenta montar usando o programa exemplo ou a sua aplicação, mas com dados um pouco mais reais.

Boa tarde Robson, Porque você não baixa o Manual versão 1.04c do CTe que encontra-se disponivel no Portal Nacional do CT-e. Nele você vai encontrar a estrutura completa do XML, com a indicação dos campos obrigatórios e dos opcionais. Se você já utiliza o ACBrNFe não vai ter dificuldade em usar o ACBrCTe, uma vez que os comandos são os mesmos, a lógica é a mesma, e as propriedades do componente seguem a mesma nomenclatura do manual.

Boa tarde Liandrocs, Hoje a noite vou realizar o seguinte teste: Emitir dois CTe e depois em seguinte efetuar o cancelamento de ambos. Se funcionar sem nenhum problema, podemos concluir que o problema é realmente a sua aplicação.

Boa tarde, A function ACBrNFSe1.CancelarNFSe(sCodigo) onde sCodigo é o codigo de cancelamento da NFSe. Ela requer que você carregue antes o XML da NFSe. Ou você pode utilizar a function abaixo, sem a necessidade de carregar o XML da NFSe: ACBrNFSe1.WebServices.CancelaNFSe(sCodigo, numNFSe, sCNPJ, sIM, sCodMun); Onde temos: sCodigo = código de cancelamento numNFSe = numero da NFSe sCNPJ = CNPJ do prestador de serviço sIM = Inscrição Municipal do prestador de serviço sCodMun = Codigo do Municipio do prestador de serviço Todos os 5 parametros são string.

Boa tarde a todos, Favor atualizar os fontes e testar novamente o cancelamento.

kzarlopes, Se o componente estiver configurado para salvar os arquivos de envio/retorno, existe um arquivo com o seguinte nome: <num>-pro-rec.xml Esse arquivo contem o resultado do processamento do lote enviado. Se o CTe foi rejeitado, o motivo da rejeição esta nesse arquivo.

Boa tarde kzarlopes, Como você pode ver no PDF no quadro N. Protocolo não consta o numero do mesmo, apenas a data e hora, que por sinal é praticamente a mesma da emissão com diferença de 3 segundos. O XML esta assinado, mas não esta protocolado. E ao realizar a consulta na SEFAZ, tanto no ambiente de homologação quanto de produção ele não existe. Isso significa que ele não foi enviado. Se foi, deve ter sido rejeitado.