Italo Giurizzato Junior

Rogério, Desculpa não entendi: Sim claro, estou verificando nesse momento, o que acontece e que geramos o txt igual a sefaz e atraves dele e que mandamos, preciso ver como gerar o xml acho que antes de assinar eu salvo, não e isso. Se você utiliza o componente, basta alimentar o mesmo com os dados da venda ou seja, que é o emitente, o destinatário, os itens, etc. E ao executar o comando: ACBrNFe.Enviar(nlote); onde nlote é uma variável que contem o numero do lote. O XML é gerado, assinado, validado, enviado, protocolado e o DANFE é impresso. Você gera o txt para que? Onde ele é utilizado?

Rogério, Uma coisa não ficou clara para mim, você utiliza o componente ou o ACBrNFeMonitor, uma vez que você diz: "somente ai em uma arquivo Txt" Depois você diz que usou o programa Demo? Eu desenvolvo em Delphi, utilizo o componente e não gero nenhum arquivo TXT os unicos arquivos que a minha aplicação gera são os XMLs das NF-e.

Boa tarde Robinho, Evitar não tem como, mas você deve incluir um campo na tabela de tal forma que ele só vai conter a informação caso houver o retorno. Por exemplo, o campo NumProtocolo, antes do envio o conteudo é vazio, se ocorrer o retorno da SEFAZ você atualiza esse campo com o numero de protocolo de autorização de uso do CT-e. Se após o envio esse campo continuar vazio é sinal que o envio foi feito e não ocorreu o retorno. É interessante neste caso, a sua aplicação apresentar uma lista de CT-e enviados e não protocolados, onde o usuário possa selecionar e realizar uma consulta. Abra o arquivo RotinaCompleta.txt e estude a procedure: procedure TfrmMovEmitirCNT.NaoProtocolados;

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 Rogério, Concordo com você Kiko, é o que seu sempre digo, não basta ler, temos que interpretar o que esta escrito. Interpretação precisa e clara, parabéns. Só ficou faltando dizer que temos dois limitadores, um é a quantidade de notas inseridas no lote ( 50 no máximo ) e a outra já discutida é o tamanho do lote em 500 Kbytes. Eu em particular resolvi limitar mais ainda, baixando para 40 notas no máximo em um lote. Mesmo que o usuário registre 90 vendas e selecione todas para que sejam enviadas, a rotina envia somente as 40 primeiras, obrigando o usuário a disparar um segundo envio e depois um terceiro para completar as 90 notas. Rogério, o que você tem que dizer para essas pessoas é que o seu sistema segue a legislação e as normas estabelecidas nos manuais e notas técnicas. Outra coisa, você disse que a sua aplicação chegou a demorar quase 20 minutos, para enviar um lote, já o programa da SEFAZ foi 10 vezes mais rapido, gastando apenas 2 minutos. Pois bem, você deixou claro que a sua aplicação realiza diversas validações, que por sinal o programa da SEFAZ não realiza, sendo assim quanto mais checagens forem feitas, mais tempo se leva. Você não poderia aplicar essas validações em outros momentos? Por exemplo, em vez de validar o código do municipio no momento do envio, porque não fazer essa validação ao cadastrar o cliente? Será que você não esta validando uma informação que o componente já o faz? Desta forma a sua aplicação estaria validando a mesma informação duas vezes, e isso demanda tempo. São questões para serem analisadas. Se eu consigo validar todos os dados do cliente no ato do seu cadastramento, não vejo motivo de validar esse dados ao enviar a nota. Desta forma diminuo o tempo entre o clicar no botão Enviar e o DANFE impresso. O que você acha?

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 a todos, André a diferença esta na posíção do canhoto de recebimento. O seu esta sendo impresso no cabeçalho e o do Robinho como rodapé. É bem provavel que o componente esteja fazendo o mesmo calculo de documentos independente da posição do canhoto, mas como deve existir uma diferença no tamanho dos mesmos, isso acaba provocando o avanço da página. Vou verificar assim que resolver o problema disponibilizo a correção.

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 Nivaldo, Quando você diz "não tem como ter uma tela no sistema para dar baixa nos produtos" o sistema que você se refere é o emissor gratuito da SEFAZ?

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 Nivaldo, Nunca usei o emissor gratuito da SEFAZ, mas pelo que sei, ele não salva os XML em disco. Mas me parece que existe uma opção para exportar o XML, ou seja salvar em disco o XML da NF-e emitida. Tendo o XML, a amplicação de controle de estoque poderia carregar o arquivo e fetuar a baixa de forma automatica. Desde que os códigos usados para os produtos sejam iguais tanto no programa da SEFAZ quanto no controle de estoque. Como você pode ver, não é impossível, mas trabalhoso. Se o usuário esquecer de exportar um XML o controle fica furado.

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.