Italo Giurizzato Junior

Boa tarde Magnu, Nessa ultima versão do ACBrMonitor já é para estar corrigido o problema de imprimir indevidamente o DABPE quanto o BP-e não é autorizado. Por favor faça esse teste para nós.

Boa tarde Natan, Por favor anexe a unit alterada, assim fica mais fácil de nós analisarmos. Desde já muito obrigado pela colaboração.

Boa tarde Juliana, As alterações nos fontes do Monitor já foram feitas, se faz necessário agora disponibilizar uma nova versão do mesmo e por fim realizar novos testes. Em anexo as units alteradas. ACBrLibBPeRespostas.pas DoACBrBPeUnit.pas

Boa tarde Carlos, A SEFAZ-MG é campeã em gerar problemas para os seus contribuintes, com certeza andaram (como de costume) alterando alguma coisa que esteja provocando essa demora no processamento. Aguarde mais alguns minutos e realiza a consulta do CT-e enviado.

Obrigado por reportar. Fechando. Para novas dúvidas, criar um novo tópico.

Boa tarde Magnu, Analisamos o problema e já encontramos onde esta o problema. Ainda hoje estaremos disponibilizando uma nova versão do Monitor.

Bom dia Magnu, Acredito que seja necessário fazer alguns ajustes no Monitor, pois o envio do BP-e é síncrono, portanto no retorno não temos o numero do recibo mas temos o numero do protocolo caso o bilhete venha a ser autorizado. Qual é o método que você esta executando?

Bom dia Magno, Como você utiliza o monitor, acredito que o comando que você utiliza deve possuir um parâmetro onde você defini se deseja que o bilhete seja impresso automaticamente ou não. A principio esse parâmetro tem como valor padrão True, ou seja, o bilhete vai ser impresso. Outra coisa, se não me falha a memória se o bilhete for rejeitado a sua impressão não é realizada. O que deve esta ocorrendo, a sua rotina esta gerando e enviando o bilhete para SEFAZ, e em seguida executando o método para imprimir. Se o bilhete é autorizado é impresso duas vezes, uma pelo método Enviar e outra pelo método Imprimir. Se o bilhete não é autorizado esta sendo impresso, porque, esta sendo executado o método Imprimir. Se você remover da sua aplicação a execução do método Imprimir, primeiro se o bilhete for autorizado será impresso somente uma vez, segundo se não for autorizado, não será impresso nada. Faça esse teste.

Boa tarde Marcos, Muito obrigado pela colaboração, vou analisar as suas alterações e estando tudo OK vou enviar para o repositório. Só para deixar claro para todos, os dois fragmentos de código que você postou se refere a sua aplicação, correto?

Obrigado por reportar. Fechando. Para novas dúvidas, criar um novo tópico.

Boa tarde, Não adianta você reclamar com o Ginfes eles não vão resolver o problema, a resposta é sempre clássica: aqui esta tudo normal. Peça para os seus clientes protocolar na prefeitura uma reclamação informando que de uma hora para outra não estão mais conseguindo emitir as notas. Quanto mais reclamações a prefeitura receber melhor será, pois ela vai entrar em contato com o Ginfes e ai eles vão dar um jeito na coisa. Não é você e nem os seus clientes que pagam o Ginfes, logo ele não esta nem ai com você ou com seus clientes. O Ginfes recebe da prefeitura, se chover reclamações na prefeitura, ela vai com certeza tomar uma atitude.

Boa tarde Magnu, Verifica se você não esta executando o método Enviar e depois o Imprimir. Se não me falha a memória o Enviar já se encarrega de imprimir, isso explica a impressão de 2 vias. A impressão do texto "Via Passageiro" e "Via Agência" só ocorre quanto é impresso o BP-e emitido em OffLine.

Boa tarde Natan, Favor atualizar os fontes e faça novos testes. Note que fiz uma alteração no arquivo INI do provedor Betha.

Boa tarde Tailan, Essas tags (vBCSTRet e vICMSSTRet) são geradas quando o CST é 60 ou Rep60 ou CSOSN é 500. No caso de CST = 60 e CSOSN = 500 é aplicado a condição que você mencionou na sua postagem, mas no caso do Rep60 não existe a condição. Favor conversar com um bom contador para saber em qual situação realmente devemos gerar as referidas tags. Se elas devem ser geradas, por exemplo quando o CST for 60, ai acredito que vai ser necessário criar uma propriedade de configuração, pois pelo que vi esse decreto diz respeito a somente a SC, as demais UF continuam da forma que esta hoje.

Boa tarde Rodrigo, É para estar funcionando a versão 1.00 também. Após enviar na versão 1.00 e realizar a consulta o TXT que contem os dados para imprimir a guia não é salvo em disco?

Bom dia Renan Eu entendi o que você deseja fazer, mas o problema é o seguinte: FPIniParamsCarregado é uma variável interna do componente e não uma propriedade que inicialmente vale False e depois muda para True e a qualquer momento você pode novamente alterar o seu valor para False. Portanto o que você deseja fazer não é possível. A solução mais simples é: corrigido o arquivo INI, deve-se finalizar a execução da aplicação e executa-la novamente. Ou você transformar essa variável interna em uma propriedade de configuração.

Boa tarde Júlio, Primeiramente muito obrigado pela colaboração, já enviei para o repositório. Segundo, os seus fontes estão desatualizados. Terceiro, favor utilizar o tópico que aparece em primeiro lugar para enviar colaborações de inclusão de cidades ou troca de provedor.

Boa tarde Camilo, Essa mensagem de erro é porque no Schema que temos não esta previsto o serviço GerarNfseEnvio. Favor testar com o método Enviar em vez do método Gerar. Entre em contato com o provedor/prefeitura para saber se eles possui um novo Schema.

Boa tarde, Muito obrigado pelo retorno. Assim que estiver funcionando os dois ambientes vamos fechar o tópico.

Boa tarde Sérgio, Você esta com todos os fontes de todas as pastas atualizados? Se sim, reinstalou a suíte ACBr usando o ACBrInstall_Trunk2 com a opção de apagar arquivos antigos marcada? Se sim, compilou a sua aplicação com a opção Build? Se sim, na pasta que contem o executável consta o arquivo INI ACBrCTeServicos? Se sim, apague ele, pois possa estar desatualizado.

Boa tarde Paulo, A impressão do QR-Code é obrigatória tanto no DACTE do CT-e quanto do CT-e OS. A questão é, você esta usando o Fortes Report ou o Fast Report?

Boa tarde, Porque você deseja alterar o nome do XML?

Bom dia, Para que você deseja uma tabela completa? Sendo que, se o DF-e for rejeitado é retornado o código e a descrição de rejeição (cStat, xMotivo). Portanto não vejo nenhuma necessidade dessa tabela. Basta você ver no manual quais são os cStat que não são rejeições, como por exemplo: cStat = 100 significa que o documento foi autorizado pela SEFAZ.

Bom dia Rodrigo, Já tentou configurar o componente para a versão 2.00 do GNRE? Lembre-se que nessa versão o webservice retorna através da consulta o XML com as informações da guia. E é este XML que devemos carregar para imprimir a guia.

Bom dia Magnu, Tem certas coisas que há necessidade de perguntar para a empresa que vai emitir o BP-e, pois ela pode lhe ajudar nas questões que você tem duvida. Eu não tenho nenhum cliente que emite BP-e, mas vou colocar aqui o meu entendimento. infViagem é uma sessão onde devemos passar as informações sobre a viagem a ser realizada. cPercurso e xPercurso trata-se do código e da descrição do percurso, infelizmente o manual que traz o layout do XML não contem uma explicação sobre esses dois campos. Eu imagino que a empresa de ônibus deve oferecer aos seus usuários viagens para vários destinos. Pode acontecer que da cidade A até a cidade B a empresa ofereça 2 percursos diferentes. Vamos a um exemplo: cPercurso = ARALIM01 xPercurso = Araraquara/São Calos/Limeira cPercurso = ARALIM02 xPercurso = Araraquara/Ribeirão Preto/Limeira Resumindo, você vai ter que ter na sua aplicação uma tabela de percursos no banco de dados, tabela esta com dois campos: Código de percurso e descrição do mesmo. Essa tabela vai ter que ser preenchida pela empresa, onde ele vai cadastrar todos os percursos referentes as viagens que ela realiza. Espero ter ajudado.