BigWings

Esse assunto é complexo, faça uma busca no fórum que tem vários posts sobre isso.

Já verificou se essa pessoa jurídica realmente não tem inscrição estadual? Alguns estados conseguem validar caso tenha inscrição e seja informado não contribuinte.

Existe pessoa física com inscrição estadual (Produtor Rural), nesse caso ele pode ser contribuinte.

Segundo o manual de integração, até 500 documentos referenciados.

Obrigado, Italo. Vou aguardar disponibilizarem a URL para testar.

Bom dia, Gostaria de saber se há suporte no componente para o provedor Agili. Olhando o Cidades.ini não vi nenhuma cidade configurada nesse provedor. Em minha cidade (Ariquemes-RO) está sendo implantada a NFS-e usando esse sistema, pelo que conversamos com o pessoal da técnica, o webservice será hospedado no próprio servidor da prefeitura, mas ainda não está disponível a URL, tenho apenas os manuais e o arquivo XSD.

O tipo de emissão no XML tem que continuar como em contingência, e não há necessidade de reimprimir a NFC-e.

Caso o campo IND_ESCRI do registro C010 seja 1, os itens são gerados por consolidação (C180), caso seja 2, serão individualizados (C100 e C170). Não há como identificar cada nota no arquivo SPED caso seja por consolidação.

O DACTE.fr3 ainda funciona no FR4. Só precisa abrir o fr3 e salvar novamente.

O campo EXTIPI deve ter 2 ou 3 caracteres. É o que diz a mensagem de erro e o Manual de Integração. Olhando a tabela do IBPT o EX para esse NCM é 01.

Você postou apenas a mensagem de retorno na Consulta e o retorno de simulação do validador. Na transmissão, qual o código de retorno cStat?

O XML está sem o protocolo de autorização, o que significa que não foi transmitido com sucesso. Qual a mensagem de rejeição na transmissão?

Teus schemas estão desatualizados.

Essa rejeição quer dizer que o destinatário é contribuinte ICMS e tem inscrição estadual, então deve-ser informar a inscrição e tipo como Contribuinte.

Testei o DANFE.fr3 da pasta exemplos aqui e mostrou as duplicatas sem problema.

O tópico era sobre o demo do ACBrNFe, que já foi compatibilizado. Algumas propriedades foram alteradas, por exemplo PathCan e PathCCe agora é PathEvento. Verifique o demo para fazer os ajustes no seu programa.

O IncluirQRCodeXMLNFCe é uma propriedade do componente, não precisa mexer no código do ACBr, basta configurar ele no seu código. procedure TForm1.FormCreate(Sender: TObject); begin ACBrNFe1.Configuracoes.Geral.IncluirQRCodeXMLNFCe := True; end;

Aparentemente, o contador está correto. A Nota Técnica 2015/002 v. 1.30 incluiu uma exceção na validação do campo do QR-Code para validar apenas as NFC-e com data de emissão a partir de 01/04/2016.

Acho que algumas SEFAZ ainda não obrigavam a incluir a informação. No PR por exemplo só a partir de 01/04. http://www.fazenda.pr.gov.br/modules/noticias/article.php?storyid=665&tit=NFC-e-autorizada-deve-ter-a-informacao-valida-do-QR-CODE

-- no método de transmitir a nfce já gerada em contingência ACBrNFe1.Clear; ACBrNFe1.LoadFromFile('C:\CAMINHO\DO\ARQUIVO-nfe.xml'); try ACBrNFe1.Enviar(0, False, True); // rotinas de tratamento do cStat except on E:Exception do // ativo a opção do usuário editar os dados da nota e gerar novo XML end; No caso do tópico precisaria chamar ACBrNFe1.NotasFiscais.Assinar para gerar nova assinatura antes de enviar.

Não precisa lançar as vendas novamente, apenas carregar o XML incorreto, assinar novamente com o novo certificado e transmitir. Não alterar nada no XML, nem data de emissão, nem tipo de emissão (manter como contingência). O XML deverá ser autorizado com o cStat = 150 (autorizado fora do prazo). Esse é o procedimento padrão para qualquer erro de rejeição na transmissão de uma NFC-e offline, carregar o XML novamente, corrigir apenas o que causou a rejeição e transmitir novamente.

Sim, basta carregar o logo na impressora.

Se começaram a emitir certificados A3 com criptografia 2048bits, vai ficar complicado, já que o CAPICOM não dá suporte a esse protocolo e o OpenSSL não funciona com certificados A3. Talvez a única forma seja exportando o certificado do chip para um .pfx, correndo o risco de perder o certificado.

Que tal implementar uma propriedade para configurar o numero de casas decimais no percentual de desconto? Se colocar em 0 ou 1 casa já resolve o problema exemplificado.

Já existe a condição para não gerar a tag ICMSUFDest, basta não preencher com valor maior que zero a tag pICMSInterPart. procedure TNFeW.GerarDetImposto(const i: Integer); begin Gerador.wGrupo('imposto', 'M01'); Gerador.wCampo(tcDe2, 'M02', 'vTotTrib ', 01, 15, 0, nfe.Det[i].Imposto.vTotTrib, DSC_VTOTTRIB); if (( NFe.Det[i].Imposto.ISSQN.cSitTrib <> ISSQNcSitTribVazio ) or (( NFe.infNFe.Versao > 3 ) and ( nfe.Det[i].Imposto.ISSQN.cListServ <> '' ))) then begin if NFe.infNFe.Versao >= 3 then (**)GerarDetImpostoIPI(i); (**)GerarDetImpostoISSQN(i); end else begin (**)GerarDetImpostoICMS(i); (**)GerarDetImpostoIPI(i); (**)GerarDetImpostoII(i); end; (**)GerarDetImpostoPIS(i); (**)GerarDetImpostoPISST(i); (**)GerarDetImpostoCOFINS(i); (**)GerarDetImpostoCOFINSST(i); if nfe.Det[i].Imposto.ICMSUFDest.pICMSInterPart > 0 then (**)GerarDetImpostoICMSUFDest(i); Gerador.wGrupo('/imposto'); end;