Italo Giurizzato Junior

Boa tarde Volnei, Exatamente, isso pode ocorrer, basta o webservice receber uma quantidade enorme de requisições e não conseguir dar conta de tudo dentro de um tempo pre estabelecido. A solução neste caso é realizar uma consulta para saber se os respectivos RPSs foram processados.

Liandro, Uma coisa é o certificado da empresa, a outra são os certificados da UF em questão, que chamamos de cadeia de certificados.

Boa noite Robson, Devemos incluir a cidade na unit: pnfsConversao e na unit referente ao provedor. No caso GovBR como você já identificou. Na unit: pnfsConversao procure por: function CodCidadeToProvedor(const ACodigo: Integer): string; E na unit: ACBrProvedorGovBR é onde você já identificou. Implemente e realize os testes, funcionando poste as suas implementações aqui no forum.

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.

Robinho, Se você tem no banco de dados os conhecimentos não protocolados, é facil montar um loop e automatizar a consulta. Você não baixa o CT-e, você consulta e obtem o protocolo de autorização. Devemos carregar o XML para que o componente realize a atualização do mesmo ou seja inclua as TAGs referentes ao protocolo de autorização.

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?