Victor H. Gonzales - Panda

Por favor atualize seus fontes, pelo SVN do ACBr... Já subimos para o nosso repositório de fontes, modificações que podem corrigir algum dos itens referentes a esse tópico... Por favor atualize seus fontes, faça testes, e se possível comente em uma nova resposta, se o problema foi resolvido... Dúvidas, sobre o uso do SVN ? Clique aqui e veja um vídeo

TK-5553

O que é a Manifestação do Destinatário? Este conjunto de eventos, como o próprio nome já sugere, permite que o destinatário da NF-e possa se manifestar sobre a sua participação comercial descrita na NF-e, confirmando as informações prestadas pelo seu fornecedor e emissor do respectivo documento fiscal. Este processo é composto de quatro eventos: 1. Ciência da Emissão 2. Confirmação da Operação 3. Registro de Operação não Realizada 4. Desconhecimento da Operação Como funciona o evento Desconhecimento da Operação? Este evento tem como finalidade possibilitar ao destinatário se manifestar quando da utilização indevida de sua Inscrição Estadual, por parte do emitente da NF-e, para acobertar operações fraudulentas de remessas de mercadorias para destinatário diverso. Este evento protege o destinatário de passivos tributários envolvendo o uso indevido de sua Inscrição Estadual/CNPJ. Como funciona o evento Operação não Realizada? Este evento será informado pelo destinatário quando, por algum motivo, a operação legalmente acordada entre as partes não se realizou (devolução sem entrada física da mercadoria no estabelecimento do destinatário, sinistro da carga durante seu transporte, etc.). Como funciona o evento Confirmação da Operação? O evento será registrado após a realização da operação, e significa que a operação ocorreu conforme informado na NF-e. Quando a NF-e trata de uma circulação de mercadorias, o momento de registro do evento deve ser posterior à entrada física da mercadoria no estabelecimento do destinatário. Este evento também deve ser registrado para NF-e onde não existem movimentações de mercadorias, mas foram objeto de ciência por parte do destinatário, por isso é denominado de Confirmação da Operação e não Confirmação de Recebimento. Importante registrar, que após a Confirmação da Operação pelo destinatário, a empresa emitente fica impedida de cancelar a NF-e. Apenas o evento Ciência da Emissão não inibe a autorização para o pedido de cancelamento da NF-e, conforme o prazo definido na legislação vigente. Como funciona o evento Ciência da Emissão? O evento de "Ciência da Emissão" registra na NF-e a solicitação do destinatário para a obtenção do arquivo XML. Após o registro deste evento, é permitido que o destinatário efetue o download do arquivo XML. O Evento da "Ciência da Emissão" não representa a manifestação do destinatário sobre a operação, mas unicamente dá condições para que o destinatário obtenha o arquivo XML; este evento registra na NF-e que o destinatário da operação, constante nesta NF-e, tem conhecimento que o documento foi emitido, mas ainda não expressou uma manifestação conclusiva para a operação. Todas as operações com o evento de solicitação de "Ciência da Emissão" deverão ter na sequência o registro do evento com a manifestação conclusiva do destinatário sobre a operação (eventos descritos nos itens 5.2, ou 5.3, ou 5.4). É possível reconsiderar o registro de um destes eventos? O destinatário poderá enviar uma única mensagem de Confirmação da Operação, Desconhecimento da Operação ou Operação não Realizada, valendo apenas a última mensagem registrada. Exemplo: o destinatário pode desconhecer uma operação que havia confirmado inicialmente ou confirmar uma operação que havia desconhecido inicialmente. O evento de "Ciência da Emissão" não configura a manifestação final do destinatário, portanto não cabe o registro deste evento após a manifestação final do destinatário. O que fazer quando a operação se realizou de forma diferente do descrito na NF-e, porém a mercadoria já foi recebida pelo destinatário? Caso a operação tenha se realizado, mas o conteúdo da NF-e não descreva corretamente da operação, o destinatário deverá se manifestar utilizando o evento "Confirmação da Operação", e adotar os procedimentos fiscais cabíveis de acordo com a legislação da unidade federada onde estiver estabelecido. Os eventos "Registro de Operação não Realizada" e "Desconhecimento da Operação" não devem ser utilizados nesta hipótese. Onde podemos consultar os eventos de Manifestação do Destinatário? A consulta pública na Internet foi alterada para exibir os eventos registrados na NF-e e pode ser realizada diretamente no Portal da NF-e (www.nfe.fazenda.gov.br) ou portais das Secretarias de Fazenda da circunscrição do emitente, a partir da informação da chave de acesso da NF-e. Os arquivos XML dos eventos também serão disponibilizados para os emitentes/destinatários constantes no documento fiscal. Uma vez que o destinatário tomou Ciência da Emissão é obrigatória a sua manifestação? Sim. Toda nota informada ao contribuinte tem que ter registrada a sua respectiva manifestação até um prazo máximo de 180 dias, contados da data da ciência. Este prazo máximo será reduzido gradativamente, conforme o interesse das Administrações Tributárias. O destinatário deve apresentar uma manifestação conclusiva dentro de um prazo máximo definido, contados a partir da data de autorização da NF-e, conforme tabela abaixo: A distribuição ocorrerá para os atores que desempenham papéis de emitente, destinatário, transportador e terceiros (informado na tag autXML), e englobará os documentos que estiverem com “SIM” na linha correspondente, conforme tabela abaixo: A geração de NSU, a partir da versão 1.10 da Nota Técnica 2014.002, irá considerar somente os usuários do serviço nos últimos 60 dias. É importante ressaltar que: a) para os usuários do serviço dos últimos 60 dias, a geração de NSU continuará normalmente; b) no caso de novos usuários desse serviço (distNSU), a geração de NSU ocorrerá a partir do primeiro acesso. Não haverá geração de NSU retroativo; c) qualquer usuário que deixar de utilizar o serviço (distNSU) por mais de 60 dias, terá a geração de NSU interrompida e retomada a partir da próxima consulta com este método. Não haverá geração de NSU retroativo ao período de interrupção. OBS: A partir da versão 1.13 da Nota Técnica 2014.002, os eventos gerados pelo Fisco, que forem passíveis de distribuição conforme a tabela acima, serão distribuídos ao emitente independente de manifestação do destinatário, ainda que emitente e destinatário sejam iguais.

tu irá precisar entrar em contato com o faleconosco da sefaz e relatar o caso.

veja se a rejeição é realmente do webservices, caso for, a SEFAZ não está aceitando

a partir do momento da primeira transmissão, assine o documento, e todas as informações do XML não altere mais.

vamos subir um ajuste removendo o LOperacao. obrigado

Bom dia, A variavel LOperacao não seria nem necessária, visto que o IF só entraria em caso de tpInclui.

Por favor atualize seus fontes, pelo SVN do ACBr... Já subimos para o nosso repositório de fontes, modificações que podem corrigir algum dos itens referentes a esse tópico... Por favor atualize seus fontes, faça testes, e se possível comente em uma nova resposta, se o problema foi resolvido... Dúvidas, sobre o uso do SVN ? Clique aqui e veja um vídeo

envie o arquivo de retorno, se tiver dados sensíveis envie para [email protected] e vincule esse topico ao email

Tipos de pessoa esta como fisica?

Boa tarde, Por padrão a impressão do cupom NFCe possui a configuração de 80mm, caso necessário ajustar essa largura precisamos informar o novo valor na propriedade LarguraBobina: <ACBrNFCeDANFeFPDF>.LarguraBobina := 65; //equivale a 65mm <ACBrNFCeDANFeFPDF>.LarguraBobina := 80; ou 302; //equivale a 80mm <ACBrNFCeDANFeFPDF>.LarguraBobina := 90; //equivale a 90mm Obs: LarguraBobina = 302 equivale a mesma coisa que a configuração de 80mm, somente para compatibilidade do create da classe que o valor padrão é 302 dos componentes.

Boa tarde Comunidade, As alterações do Informe Técnico já foram aplicadas ao componente, Monitor e ACBrLib. A previsão da SEFAZ para vigência Homologação / Produção é 01/07/2024, nesse momento você pode testar os novos meios de pagamento na geração do XML e deixar uma flag no seu sistema para quando chegar a hora de utilizar a nova tabela o seu sistema já está pronto. As classes do ACBr já fazem a escrita do XML, Leitura e impressão. Exemplo : Caso receber a rejeição 436 : Código do meio de pagamento inexistente, é porque ainda não está liberado a nova tabela para o uso. Uma observação ao Meio de Pagamento 05 fpCreditoLoja, que teve sua descrição alterada de Credito Loja para Private Label, isso devido ao fato de agora temos o enumerador 21 fpCreditoEmLojaPorDevolucao Crédito em Loja, que tem a finalidade "Crédito em loja decorrente de valor pago anteriormente, de devolução de mercadoria etc.". Eles possuem nomenclaturas parecidas, mas possuem finalidades diferentes, o que foi alterado foi a descrição e não código ou enumerador dos mesmos. De forma mais explicativa, o enumerador CreditoEmLojaPorDevolucao associa de forma mais clara as ocorrências relacionadas a esta forma de pagamento, tais como quando o cliente teve um crédito gerado por uma devolução de uma compra feita anteriormente, já o já existente CreditoLoja visa ser utilizado nas situações onde de fato é utilizado crediário ou cartão próprio da loja, ou seja, o chamado private label.

Por favor atualize seus fontes, pelo SVN do ACBr... Já subimos para o nosso repositório de fontes, modificações que podem corrigir algum dos itens referentes a esse tópico... Por favor atualize seus fontes, faça testes, e se possível comente em uma nova resposta, se o problema foi resolvido... Dúvidas, sobre o uso do SVN ? Clique aqui e veja um vídeo

Qual o CEP utilizado para testes?

não é o caso de usar o LayoutVersaoArquivo = 002 ?

Então emita nfe e não nfce pois os modelos de impressão são diferentes. A emissão pelo tipo de documento está errada

Fiz um teste de impressão utilizando o FastReport, não foi detectado nenhuma marca dagua, ou mensagem estranha na impressão que não fosse o padrão. porem fiz um ajuste que estava faltando um literal (Quadrado Vermelho).

tenta acessar o discord novamente

tem alguma coisa errada nesse boleto: 1: não existe mais Sacador / Avalista a alguns anos, esse é o Beneficiário Final 2: o intermediário, quando se faz uma transação geralmente boleto vinculado por exemplo, o Banco é o Beneficiário, o emitente é o Beneficiário Final. o que induz que esse intermediário do seu boleto é o beneficiário do mesmo. mas essa ficha sua está fora do padrão da febraban

https://cmsarquivos.febraban.org.br/Arquivos/documentos/PDF/Convenção da Cobrança - 05_02_2021_f.pdf página 27

o envio está sendo feito Sincrono? caso não, a chave consulta é idêntica a enviada originalmente?

Boa tarde Comunidade ACBr, no commit 33681 foi unificado o comportamento do componente ACBrNFe no que diz respeito a geração de PDFs. Desta forma para qualquer um dos geradores suportados, o comportamento de geração dos arquivos em PDF será respeitado igualmente, não havendo distinção de regras entre eles, o que causava problema ao se trocar de gerador e também dificultava o suporte. Esta mudança foi aplicada para preservar a compatibilidade entre os geradores, para que todos tenham a mesma regra de negócios aplicada, e também caso haja uma das configurações abaixo sejam aplicadas com sucesso a cada arquivo gerado de forma individualmente. Configurando : <ACBrNFe>.DANFE.UsaSeparadorPDF := True; <ACBrNFe>.Arquivos.SepararPorAno := True; <ACBrNFe>.Arquivos.SepararPorMes := True; <ACBrNFe>.Arquivos.SepararPorDia := True; <ACBrNFe>.Arquivos.SepararPorCNPJ := True; o sistema irá criar os arquivos com base nas informações do XML como exemplo : [CNPJ] [ANO] [MES] [DIA] C:\ACBr\pdf\9999999000191\2024\05\18\XXXXXXXXXXXXXXXXXXXXXXXXX.pdf C:\ACBr\pdf\9999999000191\2024\05\19\XXXXXXXXXXXXXXXXXXXXXXXXX.pdf C:\ACBr\pdf\9999999000191\2024\05\19\XXXXXXXXXXXXXXXXXXXXXXXXX.pdf C:\ACBr\pdf\9999999000191\2024\05\19\XXXXXXXXXXXXXXXXXXXXXXXXX.pdf C:\ACBr\pdf\9999999000191\2024\05\20\XXXXXXXXXXXXXXXXXXXXXXXXX.pdf Como era Antes O PDF era gerado usando como base o primeiro arquivo carregado ou conforme o gerador selecionado, eram gerado todos os PDF dentro do mesmo arquivo. Como ficou Agora É gerado um arquivo único com seu respectivo documento na respectiva estrutura conforme a configuração do componente, não há a possibilidade de gerar um arquivo com vários PDF juntos, o sistema irá gerar vários PDF cada um com seu documento fiscal respectivo. Eventos Para a impressão correta dos eventos, é necessário que a nota fiscal esteja também carregada no componente, e não somente o evento, pois existem informações que são necessárias abstrair do XML do Documento Fiscal. O não carregamento da NFe que originou o evento, pode ocasionar erros no fluxo de impressão ou campos faltando o preenchimento.

exato... quase todos os relatórios exigem o FastScript de alguma forma, pode não subir algum raise, mas ele não é executado com todos os recursos que ele é programado, podendo não ter o resultado como o esperado. os Exportadores só estão disponíveis na versão comercial do Fast, estamos pensando talvez em mudar isso, porem como o @EMBarbosa falou, o relatório pode não funcionar com a versão do Getit (versão basic) por falta de carregar todos os scritps, então pode ocorrer erros silenciosos. Dificil o FR3 hoje ou componente que não está com FastScript ativo.

o CaracTitulo você vai usar para informar se é carteira Vinculada ou Carteira Normal.