Painel de líderes

Isso pode ter sido causado por problemas na restauração. Quando há problemas e o FB não consegue criar os índices, por exemplo, quando há registros faltando, ele deixa o banco de dados em modo "shutdown" que é de manutenção, por isso apenas uma conexão pode ser feita nele. Essa situação é informada no log da restauração, se você não marcou a opção "verbose" na restauração não conseguiu ver essa mensagem. Antes de retornar o banco para "online" como sugerido pelo Rafael você deve verificar os problemas. Para verificar índices inativos: C:\Temp>"c:\Program Files (x86)\Firebird\Firebird_2_5\bin\isql.exe" banco.fdb -user sysdba -pass masterkey Database: banco.fdb, User: sysdba SQL> select rdb$index_name from rdb$indices where rdb$index_inactive = 3; Caso retorne algo você pode tentar reativar cada índice, desta forma: SQL> alter index idx_meu_indice active; O mais provável é que ainda ocorra erro por ser um índice de chave estrangeira onde está faltando registros, então para ativar o índice você vai precisar restaurar o registro com problema, ou se não for possível, apagar os registros que referenciam o mesmo. Após isso tentar ativar o índice novamente. Depois de ativar todos os índices você pode colocar o banco em modo "online" novamente. C:\Temp>"c:\Program Files (x86)\Firebird\Firebird_2_5\bin\gfix.exe" -online banco.fdb -user sysdba -pass masterkey

Olá Maurício, No IBExpert vai em Services, Database Shutdown. Em seguida em Services, Database Online.

Bom dia Obrigado Rafael Moreira Neves, segui o que você sugeriu e deu certo Muito Obrigado!! BigWings Obrigado pela explicação, não sabia desse modo shutdown, ae fiz o procedimento de novo ae observei a questão do verbose, e depois segui a suas instruções antes de deixar online e deu tudo certo certo Muito Obrigado!! Obrigado Rafael e Big Wings vocês me ajudaram Muito!! Muito Obrigado!! Problema Resolvido!! Obrigado a Todos!!

Bom dia. Não consegui reproduzir o erro com o Demo do ACbr, mas seguindo uma outra dica de outra postagem aqui do fórum acabou dando certo. Adicionei a linha de código a seguir e fiz um teste e o problema foi solucionado. ACBrPosPrinter1.ConfigLogo.IgnorarLogo := True; Agradeço pela atenção! Aloisio P. Neto Desenvolvedor

Bom dia Italo! Deu certo! Reconfigurei todo o componente e a NFSe foi enviada com sucesso!

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

O CFe pode ser referenciado na tag NFref.refNFe. Para cupom fiscal ECF referencia-se no grupo NFref.refECF.

Implantação da versão 3.00a em Homologação Foi implantada a versão 3.00a do MDF-e na SVRS no ambiente de homologação às 13h30min do dia 14/06/2019. A versão de produção deverá ser implantada no dia 15 de julho de 2019. O componente ACBrMDFe já contempla essa nova versão. Esta faltando fazer o novo DAMDFE que vai conter além do código de barras o QR-Code, mas o novo DAMDFE só vai passar a ser exigido a partir de outubro de 2019. Comunicado sobre as datas de implantação da versão 3.00a Comunicamos que foi publicado a versão 3.00a do Manual de Orientação do Contribuinte do MDF-e e seus anexos. Reforçamos que esta nova versão prevista para entrar em homologação a partir do dia 14 de junho de 2019 e em produção a partir do dia 15 de julho de 2019, contempla a atualização do schema do MDF-e dentre outras modificações. Relativamente à definição dos padrões do QRCode previstos no arquivo XML do MDF-e, cuja especificação das configurações para impressão no DAMDFE estão detalhadas no Anexo II – Manual de Especificações Técnicas do DAMDFE, serão implementadas a partir de 07 de Outubro de 2019, quando entrará em vigor a obrigatoriedade de exibição do QRCode no layout do DAMDFE. Da mesma forma, as RV (regras de validação) G096 a G101 passarão a ser aplicadas em 01/07/2019 no ambiente de homologação e somente em 07 de Outubro de 2019 no ambiente de produção. Em nossa biblioteca você encontram os 3 Manuais (Visão Geral, Layout e DAMDFE) da versão 3.00a clique aqui para ter acesso.

Isso aconteceu comigo e resolvi. O tamanho do campo no meu banco de dados estava inferior ao tamanho passado pelo ACBrNfe.

Boa tarde Josenilson, Esse provedor ele esta implementado com o nome de NFSeBrasil, no arquivo Cidades.ini temos as cidades: Matozinhos, Conselheiro Lafaiete, Curvelo, Três Marias, entre outras. Procure a cidade em questão no arquivo Cidades.ini que utiliza o provedor, caso ela não consta acrescente aos modelas das citadas acima. Faça os testes utilizando o programa exemplo do componente ACBrNFSe. Se tudo funcionar a contento favor anexar o arquivo Cidades.ini com a cidade que você acrescentou caso houve a necessidade.

Boa tarde. Realmente a questão do DV entrar ou não na leitura do nosso número acaba sendo um problema, estou adicionado sua contribuição para ser analisada pelos demais membros da equipe. Att.

Boa tarde. Pelo teor de sua dúvida, me parece que está usando o ACBrMonitorPlus, neste caso sugiro a leitura do manual do mesmo para entender como trabalhar com essas opções. https://acbr.sourceforge.io/ACBrMonitor/ACBrMonitor.html Att.

Carlos, o "cNF" gerado neste XML é o mesmo número da NF "cNF" isso não será permitido pela SEFAZ em breve, por isso o componente já está bloqueando... Se preferir deixe o campo cNF com zero conforme indicado acima e o componente vai gerar um numero aleatório, evitando esse erro.

Boa tarde, Obrigada pela contribuição, adicionada para validação. Att.

Boa tarde. Obrigada pela contribuição, adicionada para análise. Att.

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

Boa tarde, Otimizy. Movi a sua postagem para um novo tópico, pois o tópico anterior era muito antigo.

Boa tarde, cyber233. Sugiro que entre em contato com a Sefaz.

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

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

Não tem erro na função. A exceção está correta, o problema é você estar informando o cNF (Código numérico) da nota igual ao nNF (Número) da NFe. Desde a NT 2019/001 isso não é mais permitido. Sugiro a leitura do tópico abaixo:

Obrigado pela ajuda consegui resolver em partes o problema , com a data e parcela.

Bom dia Juliano, A rotina de tratamento de resposta da consulta que você alterou no ACBrMDFeWebServices é a mesma na NF-e e CT-e. Note que podemos dividir o XML de retorno a consulta em 3 partes. Na primeira temos a situação atual do documento que segundo o seu exemplo acusa que o mesmo esta cancelado. Na segunda temos o grupo <protMDFe> que contem as informações referente ao protocolo de autorização. A terceira parte só vai constar se o MDF-e possuir eventos vinculados a ele, logo podemos ter uma lista, ou seja, o grupo <procEventoMDFe> pode aparecer diversas vezes. No seu exemplo como o MDF-e foi cancelado temos apenas um evento que é o de cancelamento e suas informações estão dentro do grupo mencionando acima. Pela rotina atual temos o seguinte: // Na linha abaixo temos o protocolo da situação atual do MDFe, // esse protocolo pode ser de autorização ou de cancelamento ou de encerramento numProtAtual := ACBrMDFe1.WebServices.Consulta.Protocolo; // Na linha abaixo temos o protocolo de autorização numProtAutor := ACBrMDFe1.WebServices.Consulta.protMDFe.nProt; // Abaixo temos um loop onde temos o numero do protocolo dos eventos vinculados ao MDFe for i := 0 to ACBrMDFe1.WebServices.Consulta.procEventoMDFe.Count -1 do numProtEvento[ i ] := ACBrMDFe1.WebServices.Consulta.procEventoMDFe.Items[ i ].RetEventoMDFe.retEvento.Items[0].RetInfEvento.nProt; No meu entendimento ao realizar a consulta, dependendo do que deseja você vai ter que escolher uma das 3 formas acima para obter o numero do protocolo (por exemplo).

Olá Daniel, só para te passar o feedback final sobre o assunto. Após levar um aparelho GERTEC "novo" e instalar no estabelecimento do cliente, toda a comunicação ficou normal sem quedas, monitoramos por 3 dias e tudo funcional normalmente. Só por desencargo colocamos novamente 1 dos aparelhos antigos do cliente em uso, as quedas voltaram a ocorrer. Então nesse cenário entendemos que o defeito é dos aparelhos (antigos) e não do nosso sistema ou do componente em si. Mas gostaria de agradecer sua atenção com o assunto !

Obrigado, Ítalo. Vou testar e dou retorno.

Eduardo, Favor atualizar os fones, fiz uma alteração no arquivo INI do provedor.

Leo, Favor atualizar os fontes e faça novos testes.

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

Boa tarde. O curioso é que na remessa são 8 dígitos, então é esquisito o retorno ter 20. Att.

Aparentemente está acessando uma URL que não existe mais, por ser de versão antiga. Então verifique as configurações de versão do componente: ACBrNFe1.Configuracoes.Geral.VersaoDF := ve400; ACBrNFe1.Configuracoes.Geral.VersaoQrCode := veqr2000;

Qual foi exatamente o código e mensagem de rejeição? A rejeição 704 - "NFC-e com data-hora de emissão atrasada" só deve acontecer com NFCe emitidas no modo normal. Para NFCe emitida em contingência a NFCe deve ser autorizada, após o prazo de 24 horas, com o cStat 150 - Autorizado fora do prazo. Então certifique-se que a NFCe sendo transmitida está com o campo tpEmis = 9 (Contingência off-line) e não 1 (Normal).

você não disse de onde é mas se for de minas esta paralisado...

Boa tarde. Agora sim fez sentido, vc altera no componente para o seu caso. Não tem uma regra que diga quando são 8 e quando são 9? Att.

Estou criando a Unit do Boleto, estarei postando aqui assim que Finalizar para analise e aprovação no fórum

Ok Obrigado. Já foi executado validação junto ao Banco Safra.

Que bom que conseguiu resolver. Para quem mais passar por esse problema, o Italo acabou de desfazer as alterações no código, bastando atualizar e reinstalar os componentes. Vamos deixar essa alteração pra daqui a alguns dias quando eu terminar o restante.

Boa tarde. Tente atualizar novamente e realizar novo teste. Att.

Boa tarde, Obrigada pela contribuição, adicionada para validação. Att.

Tente simplificar... ACBrSAT1.CFe.LoadFromFile(xml.AsString); ACBrSAT1.CancelarUltimaVenda; ACBrSAT1.ImprimirExtratoCancelamento;

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

Bom dia, Seus fontes estão atualizados, houve uma revisão recentemente devido as alterações das SEFAZ. Att.

Boa tarde. Não existe este tipo de documento para NFCe, SAT ou ECF... você deve utilizar uma NFe. Att.

Não temos nada nesse sentido...

Bom dia a todos, Devido ao tamanho do projeto com que trabalho, eu possuia muitos problemas relacionados ao code insight (auto complete) do Delphi. Muitas vezes a IDE acabava parando de responder e por fim eu não utilizava esse recurso pelo fato dele mais atrasar a minha vida do que auxiliar. Nos últimos dias acabei tirando um tempo para tentar achar uma solução para este problema e descobri um pacote de correções de bugs que me ajudou bastante, acredito que também possa ajudar outras pessoas que passam pelo mesmo problema. Abaixo coloco dois links, o primeiro possuí uma demonstração de como a perfomance muda após a instalação do bug fix e o segundo que contém os links de download dos pacotes: http://www.delphifeeds.com/go/s/73508 https://www.idefixpack.de/blog/2019/03/ide-fix-pack-6-4-2-released-bugfix-release/

Olá a todos, Para quem não sabe nas configurações do componente ACBrNFe, temos dentro do grupo Arquivos um subgrupo chamado DownloadNFe, que contem as propriedades PathDownload e SepararPorNome. Através dessas duas propriedades definimos o caminho onde os XML retornados pelo método DistribuicaoDFe vão ser salvos e se desejamos separar por nome ou não. A primeira alteração realizada foi a migração da definição dessas propriedades de configuração da unit ACBrNFeConfiguracoes para ACBrDFeConfiguracoes. A motivação para essa mudança é que a definição dessas propriedades também se encontravam nas units ACBrCTeConfiguracoes, ACBrMDFeConfiguracores e ACBrBPeConfiguracoes, agora temos em apenas um lugar, ou seja, na unit ACBrDFeConfiguracoes. Com essa mudança temos uma redução de código e caso futuramente tenhamos alguma correção ou melhoria, elas serão feitas em apenas um lugar, desta forma agilizando o tempo de manutenção do código. Como nem tudo são flores, quem tem em seu código as linhas para configurar o Download deverá fazer a seguinte alteração para que a aplicação seja compilada com sucesso (exemplo no caso da NF-e): Antes: ACBrNFe.Configuracoes.Arquivos.DownloadNFe.PathDownload Alteração: ACBrNFe.Configuracoes.Arquivos.DownloadDFe.PathDownload Falando em melhoria, antes tínhamos uma função chamada GetPathDownload que tem como finalidade gerar o Path final onde será gravado os XML referentes aos Resumos de Notas e Notas Completas. Agora além da função citada acima temos também a função GetPathDownloadEvento que tem como finalidade gerar o Path final onde será gravado os XML referentes aos Resumos de Eventos e Eventos Completos. O que motivou a criar essa nova função é que antes o DistribuicaoDFe ao salvar os XML referentes aos eventos estava usando o mesmo Path dos eventos enviados, ou seja, estava misturando os eventos enviados com os eventos baixados pelo DistribuicaoDFe. Resumindo, a primeira alteração visou a redução de código nos componentes ACBrNFe, ACBrCTe, ACBrMDFe e ACBrBPe e a segunda visou organização dos XML baixados pelo método DistribuicaoDFe. Qualquer duvida ou problemas, favor postar no fórum.

Quais são as mudanças dessa nova versão 3.00a? Um breve resumo. Criação do Web Service síncrono de autorização Disciplina as regras para Uso Indevido Definição do QR Code do CT-e: RV´s 850 a 855 ; Definição da Consulta Pública resumida e consulta completa para atores do CT-e identificados pelo certificado digital; Eliminação do retCancCTe na resposta da consulta situação; Criação da tag ICMSST no evento EPEC e alteração da RV 642; RV 841 para informar fretamento no transporte de pessoas; Alteradas RV´s 837, 838, 839, 840: aplicar somente aos tipos Norm / Subst.; Unificação das regras de validação de chave de acesso: 592-596, 507, 610 => 236 701-708 => 842 (Chave do CT-e da ferrovia de origem) 591, 602-605, 508, 504 = > 843 (Chave da NF-e transportada) 544-549, 480, 538 => 844 (Chave do documento anterior) 450-454, 478, 479, 608 => 845 (Chave do CT-e multimodal) 761-768 => 846 (Chave do CT-e anulado) 769-776 => 847 (Chave do CT-e substituído) 777-784 => 849 (Chave CT-e complementado) 816-823 => 856 (Chave do CT-e cancelado referenciado no CT-e OS) 761-772, 615, 766-768 => 857 (Chave do CT-e OS anulados) 769-772, 616, 774-776 => 858 (Chave do CT-e OS substituído) 777-780, 785, 782-784 => 859 (Chave do CT-e OS complementados) RV 848: Validação chave de acesso do CT-e de anulação informado Criação do evento do comprovante de entrega (grifado no MOC em amarelo), RV´s 860, 863, 864, 865, 869, 870 e 871 Criação do evento de cancelamento do comprovante de entrega (grifado no MOC em amarelo), RV´s 866 RV do cancelamento associada ao comprovante de entrega: 862 RV de validação da IE do tomador na EPEC: Dispensa de validação da IE do tomador quando autorização de um CT-e EPEC RV para implementação a critério da UF para o responsável técnico: 867 Previsão de RV de implementação futura para o responsável técnico: 868 Exclusão da tag pICMSInterPart do leiaute do CT-e e CT-e OS (ver anexo I Leiaute). Em nossa biblioteca você encontram os 3 Manuais (Visão Geral, Layout e DACTE) da versão 3.00a clique aqui para ter acesso.

Bom dia todos, 19/06/2019 Implantações da Consulta QR Code e do WS Sincrono de MDF-e Foram implantados na SEFAZ Virtual RS os serviços de consulta QR Code e Recepção Síncrona de MDF-e no ambiente de homologação. As empresas já podem testar conforme especificado no MOC 3.00a, as URL´s dos serviços contam no menu Serviços deste portal. Obs: A consulta QR Code pelo smartphone poderá apresentar erro de certificado digital, o usuário poderá clicar em avançado e pedir para acessar mesmo assim, ou instalar o certificado raiz brasileira v2 em seu dispositivo pelo link: http://acraiz.icpbrasil.gov.br/credenciadas/RAIZ/ICP-Brasilv2.crt. Só será necessário baixar a primeira vez. Esta foi uma mudança feita pelo próprio ITI, responsável pelo ICP-Brasil, na forma como as raízes são baixadas pelos navegadores de smartphone. Até o final da semana que vem vamos disponibilizar as alterações necessárias no componente ACBrMDFe para que seja possível o envio de MDF-e no modo Síncrono.

Como você não mencionou a mensagem exata de erro que está dando, vou dar outra sugestão; Limpar o componente antes de criar um evento. (Se tiver uma nota fiscal carregada no ACBr e você tentar criar um evento, terá a mensagem abaixo) Por tanto, certifique-se de limpar as notas fiscais e eventos que estão previamente carregados no ACBr. with ACBrNFe1 do begin NotasFiscais.Clear; EventoNFe.Evento.Clear; with EventoNFe.Evento.New do begin InfEvento.cOrgao := 91; //91 - Ambiente Nacional. No caso de evento de manifestação, sempre será 91 InfEvento.chNFe := ''; //Chave de acesso da NFe InfEvento.CNPJ := ''; //CNPJ da empresa que está emitindo o evento (o mesmo do certificado digital) InfEvento.dhEvento := now; //Data do evento InfEvento.tpEvento := ''; //teManifDestCiencia, teManifDestConfirmacao, teManifDestOperNaoRealizada, teManifDestDesconhecimento InfEvento.detEvento.xJust := ''; //Justificativa, caso seja desconhecimento ou op não realizada end; EnviarEvento(IdLote); end;

Já descobri o problema, vou postar aqui caso alguém mais passar por isso. Todo o problema estava na configuração de segurança de acesso a conta, acesse o link Digite no browser https://www.google.com/settings/security/lesssecureapps e clique em ativar. Créditos do Jovanio que postou a solução em outro post aqui do fórum http://www.projetoacbr.com.br/forum/topic/23718-acbrmail-autenticação-do-servidor-de-email/#comment-153055