Agnaldo Prates

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,

Não estou tendo problemas nem com certificados A3 ou A1, certificadoras diversas inclusive da SERASA. Porém, chamo o selecionar certificado apenas uma vez, atribuo o número de série apenas uma vez, inclusive a senha no caso do A1, para o A3, não atribuo nenhuma senha, isso quem faz é o app da certificadora. Me parece que, se for informado a senha para o A3, não vai funcionar, visto que a mesma é validada apenas se digitada ao solicita o PIN.

Bom dia. Já tentou depois da consulta pegar o retorno? ACBrNFE1.WebServices.Retorno.Protocolo

Qual Windows e certificado? Tive um problema parecido, porém, não havia nenhuma relação com o ACBr, embora o Access Violation apresentava no momento de assinar a NFe. Solução: No atalho do meu sistema, o rapaz colocou para executar em modo de "compatibilidade", pedi para apagar o atalho e executar o sistema diretamente pelo executável. Resolveu o problema. Talvez seja isso, pois compilo tanto no D7 quanto no D2010.

Me parece que o DANFE não sofreu nenhuma alteração, apesar das informações estarem no .xml, estas até poderiam ser apresentadas no DANFE, entretanto, pensou eu que, se fosse para colocar todas as informações do xml no ali, daqui a pouco esta representação em papel do xml seria impossível de ler, mas, cada empresa pensa de um jeito, e a sefaz de outro. Fonte: NT_2016_002_v1.20, p.55

O Delphi está reclamando que a unit foi compilada com uma versão diferente. Apague os .dcus ou use o ApagarACBr.bat, que dá certo.

Então. O fisco não foi pensado com o objetivo de prever todas as possibilidades que possam advir de uma relação compra/venda. Na verdade "pensam" os especialistas quem tais informações devem estar corretas no momento do envio da informação ao Estado. Por outro lado, como isso não foi configurado, existe a possibilidade de desfazer a transação comercial, isso porque, não existe nada blindado a erro, pois a operacionalidade é feita por seres humanos, e estes, por mais que tentem, podem cometer algum equívoco desprovido de qualquer maldade, salvo algumas raras exceções. Imagine que, se não fosso possível cancelar esta transação, não seria salutar que numa venda com cartão de crédito fosse informados administradora, bandeira e NSU, não seria razoável que o fisco recebesse um tributo de uma operação que não fora concluída, isso seria uma causa de enriquecimento sem causa do Estado. É o que ocorre nas vendas efetuadas por comércio eletrônico, pois o consumidor poderá desistir se optar por isso no prazo de sete dias. Isso posto, não há razão para tal preocupação, uma vez que, é o próprio Estado quem permite tal procedimento.

Bom dia. Vamos começar do zero. RICMS/RJ. DO SUJEITO PASSIVO. Segundo o que dispõe o título IV, capítulo I, art. 15, contribuinte é qualquer pessoa, física ou jurídica, que realize, com habitualidade ou em volume que caracterize intuito comercial, operação de circulação de mercadoria ou prestação de serviços descritas como fato gerador do imposto, observado o disposto no § 2.º, deste artigo. Note-se que, ao remeter para o §2º, este remete para os itens 6, 7, 8, 17 e 18 do § 1.º, ou seja, nestes referidos itens, não importa quem é a pessoa, ela será legalmente contribuinte do ICMS. Assim sendo, o consumidor final, se não estiver nos itens antes citados, ele por não ser contribuinte do referido imposto, o responsável tributário será o remetente, isso porque, para o fisco é mais fácil receber do remetente e não do destinatário, portanto o primeiro deverá recolher o ICMS incidente na operação. Quanto à primeira circulação, isso já é disciplinado também no respectivo título, onde, se a posteriori não houver a comercialização da mercadoria, haverá a incidência do ICMS, pois se o contrário fosse, não teria sentido tal incidência, ressalvados os casos de substituição tributária, conforme previsão do mesmo diploma legal, Livro II, art. 4º, §2º. Portanto, a CST e CFOP a serem utilizados são os mesmos corriqueiramente utilizados, ou seja, CST 00..90 e CFOP 5.101, 5.401, 6.107 etc...

Bom dia. Veja bem. Não há nenhum impedimento legal que vede a venda da indústria para o consumidor final ou dito "não contribuinte regular do ICMS". Assim sendo, a CST é a normal, não há qualquer benefício resultante de tal operação. O que na verdade muda são alguns parâmetros comerciais e fiscais. Se a indústria vende para um contribuinte regular do ICMS, deve-se voltar os olhos para o que estabelece o RICMS/RJ, no sentido de identificar se há substituição tributária. Para o consumidor final, o responsável tributário é a indústria..

Obrigado pela informação. Assim sendo, podemos avaliar se no caso de uma NF-e antiga, para emissão da CC-e, podemos no momento da emissão configurar o ACBrNFE1 para 2.0. Vou fazer este teste.

Boa tarde. Parece que o agente Fiscal está interpretando o dispositivo legal de forma restritiva, senão vejamos: Segundo o disposto no Art. 1º 12.741, pode ser total ou separadamente, pois se fosse para concatenar, o próprio legislador já teria deixado claro no referido artigo. Mas isso tem um sentido legislativo. Conforme disposto no Art. 24, inciso I, §º CRFB/88, a União limita-se a estabelecer normas gerais, e como a referida Lei 12.741/2018, é uma lei federal, ela poderá ser complementada pelos estados. Assim sendo, cada unidade da federação poderá interpretá-la tanto de forma expansiva ou restritiva, talvez seja o caso do RS. Portanto, quanto tratar-se de norma federal em matéria concorrente, como é o caso do direito tributário, é necessário avaliar qual é verdadeiramente o seu sentido e alcance. O ACBrNFe atende todos estes requisitos, tanto o restritivo quanto o expansivo, basta para tanto setar a variável "TributosSeparadamente := True/False".

Entendi. Não destaquei que para A1 eu uso o OpenSSL e não WinCrypt.

Desculpe-me, parece que você não entendeu a resposta do André. Quando ele diz: " O demo para NF-e possui uma aba NFC-e. O componente é o mesmo e as funções tbm ", certamente reportou à dúvida de Gerar e imprimir na Guia do ACBrNFe_Demo que está na pasta Exemplos\ACBrDFe\ACBrNFe\Delphi, nela, coloque um ACBrPosPrinter1 e um ACBrNFeDANFeESCPOS, ligue os. No ACBrNFe1 na opção Danfe = ACBrNFeDANFeESCPOS, neste a opção PosPrinter = ACBrPosPrinter1 ; Sobre a Guia NFCe vide imagem em anexo, tem no ACBrNFe_Demo, pelo menos aqui tem. Se sua dúvida for quanto à configuração, veja a pasta "Demo Exemplos\ACBrDFe\ACBrNFe\ACBrNFeDANFeEscPos".

Outro detalhe. Talvez a linha 188 da Unit ACBrSantander.pas deva ficar assim: PadRight(Nome, 30,' ') + // 074 - 0103 / Nome do Cedente e não como está atualmente PadRight(Nome, 30) + // 074 - 0103 / Nome do Cedente

Este erro ocorre por diferenças do FR. Eu estava utilizando o FR 5.2 estava tudo ok. Quando atualizei para o FR 5.4 apareceu este erro. Solução: Abra o seu form e anote a linha que ocorre o erro, faça um backup do respectivo .dfm e feche o .pas, por um editor qualquer vá até a linha onde aponta o erro e exclua-a, save e pode abrir que funciona.

Certamente em algum local espera-se 0 (zeros) e está indo espaços.

Pode fazer sentido. Note que o componente está correto, o que não está em consonância com o que está querendo o "obscuro" manual é: 19.3P Uso Exclusivo CAIXA Filler 74 77 X(004) "Preencher com espaços" Então, quando dispara a inconsistência, "19.3P deve ser igual ao início de 35.3P Para -> NN: 14/000000140000032 SeuN: 123/1 ", fica evidente que na linha 622 da unit ACBrBancoCaixa.pas, ao invés de PadRight(NumeroDocumento, 11, ' ') + //63 a 73 - Número que identifica o título na empresa Deverá ser PadLeft(NumeroDocumento, 11, ' ') + //63 a 73 - Número que identifica o título na empresa Ou seja, espaços à esquerda. Somente não sei onde ele está encontrando o Segmento "S", tendo em vistat que o componente não o gera.

Você já tentou pelo Demo do ACBrBoleto?

Como você está alimentando o ACBrBoleto, ACBrTitulo? A depender das informações alimentadas irá gerar inconsistência no arquivo de remessa. Outro fator importante, é justamente a atualização dos fontes. Pelo seu relato " Campo inválido na linha 5. Tipo de registro [Detalhe - Segmento R]. O campo [Valor/Percentual a ser aplicado], posição 75 a 89, deve ser [Numérico, alinhado à direita, preenchido com zeros à esquerda, sem máscara de edição (ponto, vírgula, barra)]. Valor atual [0000000 ]." não parece prosperar, sendo que, na linha 586 da unit ACBrBancoSantander está expresso: IntToStrZero(round(ValorDocumento * PercentualMulta), 15), ou seja, se não houver nenhum valor, serão disparados 15 zeros. Talvez seja uma questão de atualização nos teus fontes.

Bom dia. Você não precisa saber "tudo" sobre legislação tributária, mas com certeza necessitará de um conhecimento básico pra tal, em especial no que diz respeito à integração dos teus sistemas às regras fiscais. Mas nem tudo está perdido. Ainda bem que aqui mesmo existe uma solução, e o melhor, preparada por grandes especialistas tanto em programação de altíssimo nível quanto às adequações às normas legais. Lhe indico ler a respeito do ACBrMonitorPlus. Você precisa apenas configurá-lo, gerar os arquivos TXT obedecendo os comandos necessários e pronto. Penso que, pelo caminho que parece que você precise percorrer, esta solução é a menos dolorosa.

Se for no componente ACBrNFE1, utilize: ACBrNFE1.Configuracoes.Geral.SSLCryptLib := cryWinCrypt; ACBrNFE1.Configuracoes.Geral.SSLHttpLib := httpWinHttp; ACBrNFE1.Configuracoes.Geral.SSLXmlSignLib:= xsMsXml; ** Não colocar a senha no componente. Instalar as DLLs Capicom. Passei por isso e resolvi desta maneira. Emito NFE com certificados A1 e A3 sem problemas.

Bom dia. Tente assim: ACBRNFe1.NotasFiscais.Items[0].NFe.Pag.Add do begin tPag := fpCartaoCredito vPag := 100; end;

Não seria uma opção o ACBrMonitorPlus? Já pensou nisso? Se o projeto ainda está no D5, penso que o SAC vá lhe ajudar muito, especialmente no quesito atualizações.