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.

Bom dia a todos, 18/06/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 CT-e/CT-e OS e seus anexos. Reforçamos que esta nova versão prevista para entrar em homologação a partir do dia 22 de Julho de 2019 e em produção a partir do dia 26 de Agosto de 2019, contempla a atualização do schema do CT-e, criação do Evento Comprovante de Entrega dentre outras modificações. Relativamente à definição dos padrões do QRCode previstos no arquivo XML do CT-e, cuja especificação das configurações para impressão no DACTE estão detalhadas no Anexo II – Manual de Especificações Técnicas do DACTE, 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 DACTE. Da mesma forma, as RV G238 a G243 e N135 a N140 passarão a ser aplicadas em 02/09/2019 no ambiente de homologação e somente em 07 de Outubro de 2019 no ambiente de produção.

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.

Enviado ao repositório. Obrigado pela contribuição.

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

Boa tarde, Obrigada pela contribuição, adicionada para validação. 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 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 !

Bom dia Sergio, Muito obrigado pela colaboração, já enviei para o repositório.

Bom dia. Adicionado para validação. Att.

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

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

Bom dia, Fiz uma alteração no arquivo Recife.ini, favor atualizar os fontes e faça novos testes.

Bom dia, Por favor anexe seu XML. Att.

Bom dia ALA, Por favor vamos seguir as regras do fórum. Não poste conteúdo de arquivos como parte do texto e sim como anexo. O que você postou não é um XML e sim um WSDL. Esse WSDL apresenta a estrutura do XML que ele espera receber. Na falta de um manual que apresente o layout legível de como é o XML, você pode usar o WSDL para escrever a unit pnfseNFSeW_SigISS, que é a responsável por gerar o XML.

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).

Bom dia! Como a Juliana informou: "... você deve utilizar uma NFe" Como é de um consumidor final e se for pessoa física ou não tem identificação no cupom, a nota de devolução será emitida pela empresa que emitiu o cupom e iniciará com o CFOP 1_seguido do restante conforme a classificação fiscal do item. Exemplo: Referenciar o cupom SAT. Para maiores informações como impostos e regras a ser seguidas de acordo com o enquadramento da empresa no Simples ou não, seria bom você solicitar ajuda do escritório de contabilidade.

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.

Boa tarde, Não entendi como essa alteração pode impactar a leitura desta informação, uma vez que em nenhum momento a propriedade fpTamanhoMaximoNossoNum tem seu valor padrão(8) alterado para a leitura do retorno 240. Att.

Perfeito, mestre! Funcionou redondinho. Muito obrigado, abraço!

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

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

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

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

Bom dia. Recomendo que verifique os arquivos do svn na pasta exemplos se o existe um arquivo ini ´para este provedor. Att.

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

Bom dia. No caso o banco rejeitou o arquivo ou seria somente o validador disponibilizado pelos mesmos? Considerando que não temos relatos de problema, pode ser algo do validador. Att.

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

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.

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;

Boa tarde, Conforme pôde ser observado por um grande número de membros da comunidade, desde os últimos dias de abril vinha ocorrendo na maioria das UFs a rejeição Endereço do site da UF de Consulta por chave de acesso diverge do previsto ao tentar enviar a NFCe em ambiente de homologação. Motivo da Rejeição Conforme foi divulgado posteriormente pela SEFAZ, de forma não oficial, ou seja, sem a publicação de NTs ou outras informações nos portais relativos a NFCe, esta rejeição passou a ocorrer devido a implementação da regra ZX03-20 existente na NT 2016.002 versão 1.61, a qual determina a validação da URL de Consulta por Chave de Acesso conforme tabela disponibilizada no portal do ENCAT. Estas validações entraram em vigor em ambiente de homologação no dia 22/04/2019 e em produção entrarão em 20/05/2019. Solução Os fontes do ACBr e por consequência o ACBrMonitorPlus SAC, foram atualizados com as URLs corretas conforme documentação disponível na página do ENCAT. Porém, em alguns casos, os endereços indicados pelo ENCAT ainda sim estavam incorretos. Com base no feedback de diversos usuários de nossa comunidade, novos ajustes foram enviados para o SVN do ACBr, no arquivo ACBrNFeServicos.ini Dicas para Minimizar o Impacto em seus clientes Se você utiliza o componente ACBrNFe para emissão da NFCe, procure sempre disponibilizar na mesma pasta do seu binário (executável) o arquivo ACBrNFeServicos.ini. Desta forma, o componente ACBrNFe, irá fazer uso do arquivo ACBrNFeServicos.ini existente no diretório, ao invés de usar as URLs internas, que são compiladas como "Resource", e anexadas ao componente... Isso é extremamente vantajoso, pois lhe confere grande agilidade na resolução de problemas de URLs... Caso sejam detectadas novas alterações de URLs, basta realizar a substituição do arquivo ACBrNFeServicos.ini, evitando portanto a necessidade de atualizar toda a aplicação. Eu não distribuo o ACBrNFeServicos.ini em meus instaladores? Preciso recompilar e atualizar meus clientes para que as novas URLs entrem em vigor ? Se você não quer ou não pode distribuir o ACBrNFeServicos.ini, na mesma pasta da sua aplicação, então não há outra maneira a não ser disponibilizar um novo binário para o seu cliente... Porém antes , faça um teste, é simples e rápido... Apenas copie o arquivo ACBrNFeServicos.ini no mesmo diretório de sua aplicação, e observe que as novas URLs serão utilizadas, pois o componente ACBrNFe irá priorizar o arquivo em disco. Ainda tem Dúvidas? Acesse os sub-fóruns sobre NFCe e crie um novo tópico relatando seu questionamento. Lembre-se que se for usuário do SAC Anual você também pode falar conosco pelo chat ACBr.

Que saiba não tem a mesma opção de NF-e para baixar os xml. tu precisa colocar logs no seu sistema pra entender o que está ocorrendo. uma solução que posso sugerir é em sua aplicação remontar o xml, bastando preencher o componente com todos os dados exatos da nota e depois mandar consultar ela no sefaz e ver se recria o mesmo

Verifique se durante a instalação do certificado no windows, esta marcada a opção "Chave privada exportável"

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