Agnaldo Prates

Faltando informar a modalidade e o número do título/boleto.

Estou lhe enviando um Demo que utilizo aqui, faça as configurações conforAcbrBoletoDemo.rarme o banco solicita e teste.

É muito estranho estas posições 38 a 42. Por qual manual você está tomando esta informação como base, poderia disponibilizá-lo?

Não seria ACBrBancoNordeste.pas ?

Comigo ainda não. Você verificou se o layout do banco sofreu alguma alteração? Talvez seja isso. Entre em contato com o setor de TI do banco para saber mais informações a respeito.

Consegue. Eu faço exatamente assim faz bastante tempo.

Não tem nenhum problema se não informou o desconto nos itens, porém, na hora de gravar o pedido deverá ratear este percentual nos itens e consequentemente na nota, agora a forma como será concedido o desconto não importa. Pode ser por item ou no final da venda. O certo é que, deverá ser rateado para os itens na NFe/NFC-e, senão haverá rejeição.

Depende. Vamos analisar o cenário. A indústria fabrica e vende para sua empresa, neste caso ela se for substituta tributária, recolhe o ICMS que incidiria em toda cadeia posterior, ou seja, substituição para frente. Ocorre que no seu caso, não ficou claro mas pode ser entendido como distribuidora, que pagou o imposto do qual faz jus ao creditamento assim que vender a mercadoria citada. Entretanto, tal operação será para não contribuinte do ICMS de outra unidade da federação, o que requer uma análise mais aprofundada sobre o convênio 81/93 bem como a legislação pertinente ao tema, tanto do estado origem quanto do destino, tendo em vista as novas regras sobre o DIFAL. Oportuno salientar ainda que, a venda sendo para não contribuinte, há incidência do ICMS, e neste caso, o CFOP será o 6403 e não o 6404, isso porque, caso a venda seja feita para contribuinte regular do ICMS, supostamente haverá a venda para o consumidor final, justificando-se assim a substituição tributária para frente. Portanto, pelo exposto, parece prudente analisar os dispositivos legais aplicáveis ao caso.

No meu caso, o path de busca do ACBr é: \Users\Public\Documents\Embarcadero\Studio\19.0\Bpl, o seu aí está buscando no LibD25. Estas .bpl estão nesta pasta?

Procure ACBrBoleto1.ListadeBoletos.CodOcorrenciaToTipo, vai encontrar o retorno.

No mesmo arquivo de retorno, verifique o tipo de ocorrência retornado pelo banco. No manual existe a finalidade do arquivo, geralmente uso o arquivo de retorno e pego qual a ocorrência.

Recomendo você ler o ajuste SINIEF 3 / 2010, disponível em: https://www.confaz.fazenda.gov.br/legislacao/ajustes/2010/aj_003_10

Equivoco meu. Usa CDS sim.

Tem e faz muito tempo.

Para usar tabelas virtuais ClientDataSet, utilizadas na geração dos relatórios de notas fiscais como outros. ACBrBoleto não usa ClientDataSet que eu saiba.

A rejeição refere-se ao Sacado, ou seja, é quem vai pagar o boleto, devendo identificar se, pessoa física = 1 ou pessoa jurídica = 2. ... with Sacado do begin if Length(DocSacaco)=11 then Pessoa := pFisica else if Length(DocSacado)=14 then Pessoa := pJuridica else Pessoa := pOutras; end;

BNB? Qual unit?

ACBrBoleto1.ACBrBoletoFC := ? Fast ou FortesCE?

Esta mensagem é retornada do sistema sicoob?

Veja mais detalhe no tópico abaixo. https://www.projetoacbr.com.br/forum/topic/29083-houveram-alterações-no-svn-do-trunk2/

Bom dia pessoal. Sobre as informações de duplicação dos registros de notas fiscais no SPED Fiscal, depois de testar tudo quanto foi possível e imaginável, descobri o seguinte. Na declaração havia algumas notas fiscais modelo 55 que estavam sem o código do participante, bem como alguns cadastros que faltavam algumas informações, como código do município ou bairro/endereço com excesso de espaços. Corrigi estas inconsistências e ao checar novamente, a escrituração não duplicou mais, ou seja, não sei exatamente o que pode ter ocorrido mas resolveu com o procedimento antes dito. Assim sendo, fica ai o relato para que, caso alguém passe por este desconforto com seu cliente, veja se não é um caso parecido. Aos moderadores, se entenderem pertinente, feche o tópico. Obrigado @EMBarbosa.

Já tinha feito isso, mas não duplica. Somente no relatório mesmo. Se importar com apenas uma não duplica, porém vou testar com mais notas para ver. Obrigado.

Somente para constar, estes erros não ocorrem em todas as datas, somente nos dias, 08/08, 30/08 e 31/08, os demais dia estão corretos. O que de antemão poderia haver alguma informação equivocada nestes dias, porém, não tem, tanto é que o arquivo .txt não tem nenhuma nota duplicada, tampouco há duplicidade no próprio banco do SPED. Por fim exclui todas as notas, deixei apenas uma NFC-e, e ainda assim ela apareceu duplicada no relatório do SPED. Não encontrei nada que pudesse indicar uma possível solução no site da rfb, mas talvez nem eles mesmos sabem disso.

Pois é companheiro, imagino que tem um super "bug" neste validador, veja a imagem em anexo.

Olá pessoal, bom dia. Recentemente um cliente me confidenciou que o movimento fiscal de saída dele no SPED fiscal não estava condizendo a realidade. Analisando o meu código, não encontrei nada que pudesse explicar tal fenômeno. Resolvi fazer a somatória dos valores que vão para o arquivo .txt, o valor é exatamente o que vem do banco de dados, porém, ao importar para o validador, sem explicação aparente, as notas ficais aparecem duplicadas. Resolvi analisar mais a fundo. Entrei no banco de dados do validador, e, as informações que lá estão, são as mesmas que são enviadas pelo sistema através do arquivo .txt, entretanto, no validador, na opção Relatórios de Registros Fiscais -> Documentos -> Saídas de mercadorias e Prestação de serviços, notei que há momentos em que a nota repete até quatro vezes, e não dentro do próprio banco do aplicativo validador. Alguém já passou por isso? Atenciosamente,