BigWings

Qual o retorno da SEFAZ? Está fazendo tratamento de consumo indevido?

Para os modelos 21/22, veja o componente ACBrConvenio115.

- Baixar os fontes do ACBr pelo SVN: https://svn.code.sf.net/p/acbr/code/trunk2 - Compilar e instalar os pacotes no Lazarus: Modo manual: https://www.youtube.com/watch?v=rxZdI4UI51o Usando script: https://www.youtube.com/watch?v=o5oyqk-3kns

Não tem essas pra download. Elas são compiladas junto com o programa exemplo.

Pra usar em .net você vai precisar de uma camada adicional, que está disponível nos fontes do ACBr no SVN. Compilando o projeto exemplo você vai ter a ACBrLib.Core.dll, ACBrLib.NFe.dll, entre outras, essas sim tem código gerenciado .net que você deve ser capaz de importar. Link para a pasta demos em C#: https://svn.code.sf.net/p/acbr/code/trunk2/Projetos/ACBrLib/Demos/C%23 https://projetoacbr.com.br/fontes/

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

Pra atualizar a chave do QrCode é preciso assinar novamente. Mas a tua rotina não está correta, de acordo com o manual, não se deve alterar o XML onde houve falha no envio, e sim gerar uma outra NFCe com nova numeração, em contingência offline. Isso porque quando houve a falha existe a possibilidade de ter sido autorizada, e você não teve o retorno. Então você precisa em outro momento fazer a consulta dessa chave, e se foi autorizada, fazer o cancelamento por substituição, se a chave não existir, inutilizar a numeração. Leia o manual de contingência da NFCe disponível no portal nacional.

Pelo header do arquivo parece ser Cobol. Não consegui abrir, pelo que já li sobre, precisa conhecer a estrutura da tabela.

Na sua requisição você informou o último NSU 3604: <nfeDadosMsg> <distDFeInt versao="1.01"> <tpAmb>1</tpAmb> <cUFAutor>52</cUFAutor> <CNPJ>23156990000157</CNPJ> <distNSU> <ultNSU>000000000003604</ultNSU> </distNSU> </distDFeInt> </nfeDadosMsg> O webservice respondeu com consumo indevido, e com o último NSU esperado por ele que devia ser 3870: <retDistDFeInt versao="1.01"> <tpAmb>1</tpAmb> <verAplic>1.6.0</verAplic> <cStat>656</cStat> <xMotivo> Rejeicao: Consumo Indevido (Deve ser utilizado o ultNSU nas solicitacoes subsequentes. Tente apos 1 hora) </xMotivo> <dhResp>2022-09-28T08:24:26-03:00</dhResp> <ultNSU>000000000003870</ultNSU> <maxNSU>000000000000000</maxNSU> </retDistDFeInt> Isso quer dizer que o webservice já entregou para esse CNPJ até o NSU 3870, é esse que devia ser informado como último NSU na consulta pra não ter consumo indevido. De acordo com a NT 2014.002 v1.15, a consultas por último NSU devem ser feitos sempre informando o último NSU retornado na última resposta. Se não foi a sua aplicação que recebeu os NSU 3605 a 3870, então tem outra aplicação ou algum terceiro (o contador, por exemplo) fazendo uso do certificado da empresa e recebendo os documentos. Veja o tópico abaixo:

Nesse caso não aceita where. Não entendi o propósito do mesmo, pode explicar o que quer fazer?

O RJ não implementa esse serviço. https://www.nfe.fazenda.gov.br/portal/webServices.aspx?tipoConteudo=OUC/YVNWZfo=

FPC (Free Pascal Compiler) São DLLs nativas Windows/Linux, tem versões de 32 e 64 bits, e convenção de chamada stdcall ou cdecl.

Desculpe, mas aumentar "porque o cliente quer", não tem nada que eu possa sugerir quanto a isso. Expliquei acima.

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

Porque quer aumentar? O DANFE tem campos obrigatórios, que me lembre não tem nenhum no DANFE do ACBr que possa ser removido. As configurações de "tributos" são referentes ao valor aproximado dos tributos da lei 12741/12, que podem ser informados diretamente no DANFE, não tem a ver com os impostos destacados na nota.

Para cumprimento da Lei 12.741/12, não esqueça de atualizar sua tabela de alíquotas - Versão 22.2.E Sua vigência é de 20/09/2022 até 31/10/2022 Integre o seu sistema à API De Olho no Imposto e não se preocupe mais com as atualizações da tabela Fonte : https://deolhonoimposto.ibpt.org.br/

O manual explica melhor, mas depende da linguagem usada. O VB creio suportar apenas a StdCall, 32Bits. Sendo uma aplicação Desktop pode usar a padrão single thread mesmo. (MT = Multithread).

O ACBr vai gerar o grupo do ICMS Efetivo no XML desde que pelo menos algum dos campos do grupo for maior que 0. if (NFe.Det[i].Imposto.ICMS.pRedBCEfet > 0) or (NFe.Det[i].Imposto.ICMS.vBCEfet > 0) or (NFe.Det[i].Imposto.ICMS.pICMSEfet > 0) or (NFe.Det[i].Imposto.ICMS.vICMSEfet > 0) then begin Gerador.wCampo(IIf(FUsar_tcDe4,tcDe4,tcDe2), 'N34', 'pRedBCEfet', 01, IIf(FUsar_tcDe4,07,05), 1, NFe.Det[i].Imposto.ICMS.pRedBCEfet, DSC_PREDBCEFET); Gerador.wCampo(tcDe2, 'N35', 'vBCEfet ', 01, 15, 1, NFe.Det[i].Imposto.ICMS.vBCEfet, DSC_VBCEFET); Gerador.wCampo(IIf(FUsar_tcDe4,tcDe4,tcDe2), 'N36', 'pICMSEfet', 01, IIf(FUsar_tcDe4,07,05), 1, NFe.Det[i].Imposto.ICMS.pICMSEfet, DSC_PICMSEFET); Gerador.wCampo(tcDe2, 'N37', 'vICMSEfet ', 01, 15, 1, NFe.Det[i].Imposto.ICMS.vICMSEfet, DSC_VICMSEFET); end; Basta informar o valor do ICMS efetivo. Lembrando que o ACBrNFe não faz cálculos, apenas gera o XML de acordo com o informado e seguindo o layout da NFe.

A libxml2 tem problemas caso o path dos schemas esteja nesse formato. Quando o .xsd em questão referencia outro (xs:include), como é o caso da manifestação, a libxml2 não consegue carregar o xsd referenciado. <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns="http://www.portalfiscal.inf.br/nfe" xmlns:ds="http://www.w3.org/2000/09/xmldsig#" targetNamespace="http://www.portalfiscal.inf.br/nfe" elementFormDefault="qualified" attributeFormDefault="unqualified"> <xs:include schemaLocation="leiauteConfRecebto_v1.00.xsd"/> Você pode contornar esse problema copiando os arquivos para um diretório local, mapeando unidade de rede, ou criando um link simbólico para a pasta de rede, o importante é que a configuração PathSchemas não esteja no formato \\servidor\compartilhamento.

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

Você não deve usar o índice do enumerado como valor. Use os métodos de conversão da mesma unit: function FormaPagamentoToStr(const t: TpcnFormaPagamento): string; begin result := EnumeradoToStr(t, ['01', '02', '03', '04', '05', '10', '11', '12', '13', '14', '15', '16', '17', '18', '19', '90', '98', '99'], [fpDinheiro, fpCheque, fpCartaoCredito, fpCartaoDebito, fpCreditoLoja, fpValeAlimentacao, fpValeRefeicao, fpValePresente, fpValeCombustivel, fpDuplicataMercantil, fpBoletoBancario, fpDepositoBancario, fpPagamentoInstantaneo, fpTransfBancario, fpProgramaFidelidade, fpSemPagamento, fpRegimeEspecial, fpOutro]); end; function StrToFormaPagamento(out ok: boolean; const s: string): TpcnFormaPagamento; begin result := StrToEnumerado(ok, s, ['01', '02', '03', '04', '05', '10', '11', '12', '13', '14', '15', '16', '17', '18', '19', '90', '98', '99'], [fpDinheiro, fpCheque, fpCartaoCredito, fpCartaoDebito, fpCreditoLoja, fpValeAlimentacao, fpValeRefeicao, fpValePresente, fpValeCombustivel, fpDuplicataMercantil, fpBoletoBancario, fpDepositoBancario, fpPagamentoInstantaneo, fpTransfBancario, fpProgramaFidelidade, fpSemPagamento, fpRegimeEspecial, fpOutro]); end;

Explique melhor, então. Que biblioteca? Como está o código?

Não é particularidade, todos os estados vão aceitar apenas o modo síncrono no envio quando só houver 1 NFCe no lote, e o assíncrono quando houver até 50 NFCe no lote. O que existe de particularidade em SP é na NFe, que não permite o modo síncrono. Apenas SP e BA exigem o modo assíncrono na NFe, mesmo para 1 NFe apenas.

O código do PIX é 17, e não 12. Leia a NT 2020.006 v1.10. Ou a tabela disponível no portal: https://www.nfe.fazenda.gov.br/portal/exibirArquivo.aspx?conteudo=0cu/yBLKrCs=

Oficialmente, o Delphi 11 não suporta mais o Windows XP. Você ainda consegue alterar nas opções do projeto os "PE Headers" para que funcione, mas pode ter problemas com threads por exemplo, conforme o tópico abaixo. https://en.delphipraxis.net/topic/5536-delphi-11-windows-xp-compatibility-tweak/ O Windows XP já tem mais de 20 anos, devia estar morto e enterrado.