Painel de líderes

RESOLVIDO MEU AMIGO! Só para ficar claro para quem passar por esse problema, foi uma série de acertos que foi feito! Atualização do ACBr, Atualização de Schemas, inclusão da TAG infCTeSupl Obrigado a todos pela ajuda fundamental que me prestaram! Abraço a todos, Deus abençoe!

Boa tarde, Muito obrigado pela contribuição, vamos analisar a sua alteração e caso esteja tudo OK enviaremos para o repositório.

Isso acontece porque nas versões mais novas do Firebird é exigido um charset e collate. Se você não passa um, ele assume o padrão da conexão. Se não existe um definido na conexão, acho que ele assume UTF-8. Se seu banco de dados atual não tem charset definido nos campos char e varchar, (quer dizer está NONE), você precisa adicionar um.

Pense no google, ele não te mostra todas as páginas existentes na internet do mundo para que você possa escolher qual vai entrar. Você digita o que quer e pesquisa. Caso ainda existam muitas opções, ele limita a quantidade que vai mostrar em cada página.

Erro meu. Fontes Parcialmente atualizados. Obrigado.

Está informando também a hora de emissão? Anexe o XML. Atualize os fontes.

Olá, Apenas como confirmação, está na nossa lista de afazeres/prioridades.

Bom, acabei falando com o homologador do sistema e ele me falou o seguinte: Até o dia de hoje setembro de 2019 o SEFAZ não está aceitando arquivos de impressoras de testes, então não tem como resolver esse problema. Para poder testar ele me orientou a utilizar o SAT homologação e desmarcar a opção de validar ECF e PAF-ECF. Fazendo isso deu certo, então não precisa receber o recibo de processado com sucesso. Pra quem tiver o mesmo problema que eu tive está ai a solução.

boa noite resolvido with seg.Add do begin respSeg:=rsEmitente; CNPJCPF := ZQryMFDe.FieldByName('RESP_SEGURO_CPF').AsString; xSeg := ZQryMFDe.FieldByName('SEGURADORA_NOME').AsString; CNPJ := ZQryMFDe.FieldByName('SEGURADORA_CNPJ').AsString; nApol := ZQryMFDe.FieldByName('APOLICE_NUMERO').AsString; with aver.Add do begin nAver := ''; end; end;

Obrigado. Era isso mesmo.

Não existe o tipo tpBandeiraCartao nos fontes do ACBr. Provavelmente é um tipo definido no seu próprio código com o mesmo nome bcVisa que está sendo enxergado pelo compilador. Você pode forçar no código a usar o tipo correto: tBand := pcnConversao.bcVisa;

Olá pessoal, Quem atualizou os fontes e reinstalou a Suite ACBr, pode ser que esteja recebendo essa mensagem de erro no momento que vai gerar a NF-e / CT-e / MDF-e / BP-e. Porque esta mensagem esta aparecendo para alguns e para outros não? Simples, quando o XML é gerado com base em alguns dados do documento fiscal é gerado a chave do mesmo. Essa mensagem de erro é devido a uma validação que foi implementada na função que gera a chave. Essa validação visa garantir que a sua Nota (por exemplo) não seja rejeitada pela regra de validação B03-10 que consta na Nota Técnica 2019/001. Como vocês podem ver na imagem acima, a aplicação dessa regra é obrigatória, ou seja, todas as SEFAZ-Autorizadoras devem implementar essa regra. Ela será implementada no dia 01/07/2019 no ambiente de Homologação e no dia 02/09/2019 no ambiente de Produção. A validação que foi implementada ao gerar a chave é exatamente a descrita na regra, ou seja, o valor de cNF não pode ser igual a nNF e a nenhum dos números listados na regra. Por curiosidade resolvi pegar o Manual da NF-e mais antigo que tenho (Março de 2009) veja o que esta escrito na definição do campo cNF: O Manual deixa claro que o numero atribuído a cNF tem que ser um numero aleatório. Portanto quem costuma atribuir a cNF o mesmo numero atribuído a nNF esta fazendo errado e agora não vai ter perdão, pois se insistir a SEFAZ não vai aceitar a nota. Mas a regra B03-10 da Nota Técnica 2019/001 não se refere apenas a NF-e / NFC-e? Sim, mas tenham certeza que essa regra de validação em breve vai ser implementada para os demais DF-e - Documentos Fiscais Eletrônicos. Alguém duvida disso? O que devo fazer para que a minha aplicação não pare com a mensagem de erro: Código Numérico inválido, Chave não Gerada ? Muito simples, vou dar como exemplo o fragmento de código da minha aplicação: Como é hoje, note que eu já gerava o código como sendo um numero aleatório: NotaFiscalVenda := (DM_VEN.NotasDocumento.AsInteger + 1); CodigoChave := Random(99999999) + 1; // +1 para garantir que não seja zero Como vai passar a ser, para ter uma garantia maior ainda: NotaFiscalVenda : =(DM_VEN.NotasDocumento.AsInteger + 1); CodigoChave := GerarCodigoDFe(NotaFiscalVenda); A função GerarCodigoDFe esta definida na Unit ACBrDFeUtil, logo você vai ter informar essa Unit em Uses do seu Form. Note que ela recebe como parâmetro o numero da nota, pois a função vai gerar o código aleatoriamente e vai validar o mesmo e pela regra o código não pode ser igual ao numero da nota. De forma semelhante você terão que fazer o mesmo nas suas aplicações que emitem CT-e, MDF-e e BP-e. É preferível fazer essa correção na aplicação agora do que receber dezenas ou até centenas de ligações de clientes que não estão conseguindo autorizar os seus documentos na SEFAZ. Fica ai a dica.

Boa tarde. Realizei alterações para possibilitar a impressão dos Eventos de Comprovante de Entrega, e Cancelamento de Comprovante. Seguem os fontes para verificação. DACTE_EVENTOS.fr3 ACBrCTeDACTEFR.pas

Boa tarde, Muito Obrigado Italo, aguardo a analise. Me coloco a disposição para quaisquer esclarecimentos.

Se no lugar do clear acontecer o mesmo problema com outros valores então possivelmente é problema na lógica mesmo. Talvez controle transacional.

Boa tarde Ariane, Quem lhe disse que cNF se refere a um numero de controle interno? cNF significa Código da Nota Fiscal que a anos a SEFAZ recomenda que seja um numero aleatório, pois esse numero faz parte da chave. O valor de cNF sendo um numero aleatório a chave fica segura.

Até onde me lembro o código deveria ser algo como: ClientDataset.Edit; ClientDataset.FieldByName('usuario').Clear; ClientDataset.post; ClientDataset.ApplyUpDates(-1);

Isso não me parece ser um erro de banco de dados nem relacionado aos componentes. Provavelmente ficaria melhor na área "Dúvidas não relacionadas ao ACBr".

Boa tarde Rogério, Me parece que o Ambiente Nacional que contem o webservice do DistribuicaoDFe esta com problemas.

Bom dia @igmaster2000 se você atualizou seus fontes, base você abrir o arquivo ACBrNFeServicos.ini, ignorar a linha conforme o print abaixo e designorar a linha abaixo da mesma, tem bem certinho o que fazer nesse próprio arquivo, feito isso basta compilar o arquivo .res e compilar seu executável. Feito isso já vai estar ok.

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

Acabei de fazer assim deu certo.. foi tranquilo, antes eu removia a acbr primeiro mas assim é mais simples.

ok nunca fiz essa atualização, vou tentar qualquer coisa posto aqui. Muito obrigado

A diferença de fuso horário entre a hora de emissão e a hora de recebimento pode causar interpretação diferente do mês de emissão da nota pelo webservice de recepção, o que causaria alteração da chave de acesso. Verifique se a hora de emissão e fuso horário estão corretos, se estiverem tente aumentar a mesma em 01:00 h.

Bom dia, SoftSul Informática. Não vejo problemas para não funcionar.

vou refazer a instalação, mas acredito que não seja isso! Att

Tive esse mesmo problema na sexta e continua hoje. Estou testando EPEC. https://hom.nfe.fazenda.gov.br/NFeRecepcaoEvento4/NFeRecepcaoEvento4.asmx Emiti sexta e hoje sem EPEC ou outro tipo de contingência e foram autorizadas normalmente, não tive nenhum tipo de erro. Acredito que este erro esteja relacionado com o Web Service de Evento.

A sefaz da Bahia estar fora desde de ontem

3.2 - Não faça "bump" de forma excessiva (postar simplesmente para que um tópico vá para o topo da lista). Isso é considerado flooding. Favor leia as regras do fórum.

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.

Moderação: Tópico movido para o local mais indicado.

Veja este tópico:

Bom dia Marcelo, No meu entendimento a foto deve ser armazenada sim em disco ou no banco de dados, pois é uma "informação" que foi utilizada para compor o conteúdo do hashEntrega que foi enviado para a SEFAZ.

Funciona 100% aqui. Não temos nenhum problema. Ela só mostra instabilidade com HUBS USB de má qualidade. Se ligada ao micro diretamente funciona 100%

Aplicada a seguinte correção no relatório:

Boa tarde Rômulo, Muito obrigado pela colaboração, ainda hoje estarei enviando para o repositório.

Boa tarde Douglas, Muito Obrigado pela colaboração, ainda hoje estarei enviando para o repositório.

Boa tarde setei essa propriedade do componente Configuracoes.WebServices.AguardarConsultaRet e resolveu o problema do retorno Obrigado.

Boa tarde Rogério, Movi a sua postagem por ter postado em lugar errado (ACBrMDFe se refere ao componente de Manifesto de Documentos Fiscais Eletrônicos e não Manifestação do Destinatário que é um evento). Por favor preste mais atenção onde postar, pois você poderá ficar sem a resposta. Ao enviar o evento de Manifestação do Destinatários dessas notas que não foi liberado o XML para Download, o evento foi registrado com sucesso?

Boa tarde, Por favor anexe o XML. Att.

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 há um tempo específico... mas no momento todos estão ocupados com outras atividades Por favor anexe também, o manual que descreve o protocolo da balança..

Agora é oficial... o CADE, autorizou a compra Publicação no DOU - Despacho SG n° 1116

Funcionou belezinha @Italo Jurisato Junior, muito obrigado pela ajuda.

Publicado em 28/08/2019 Foram disponibilizadas as Minutas dos Leiautes da EFD-Reinf versão 2.1 e seus anexos. Para ter acesso, clique aqui. Conforme Nota Conjunta da Secretaria Especial de Previdência e Trabalho, Secretaria Especial da Receita Federal e Secretaria Especial de Desburocratização, Gestão e Governo Digital SEPRT/RFB/SED nº 01/2019, o evento de remuneração de segurados vinculados ao Regime Geral de Previdência Social (S-1200) fará parte de um ambiente compartilhado entre a RFB e a SEPRT, especificado com base em portaria conjunta entre os órgãos, a ser publicada em ato distinto da EFD-Reinf e do sistema simplificado que substituirá o eSocial. Portanto, o evento de remuneração a ser compartilhado, não mais será inserido na EFD-Reinf. Dessa forma, não haverá mais republicação da versão 3.0 com a estrutura apresentada na minuta publicada em 01/08/2019. Este ambiente compartilhado com o evento de remuneração será construído com objetivo de não onerar os contribuintes que já tenham seus sistemas de TI desenvolvidos para o eSocial. http://sped.rfb.gov.br/pagina/show/4141 Volta o cão arrependido...