Nelson A Sousa

Olá, Os percentuais são determinados pela norma. IBSUF= 0.10 IBSMun = 0.00 CBS = 0.90 Os descontos vão variar conforme o cClassTrib, mas também são determinados.

Olá, Não haverá recolhimento dos novos impostos. Quando muito, caso o xml emitido não atenda aos requisitos da norma, os impostos serão aplicados porém poderão ser compensados no PIS e COFINS. Caso não tenha PIS e COFINS para compensar poderão ser utilizados outros impostos para isso ou mesmo pedir a restituição dos valores.

Olá, Estava tendo esse mesmo problema. Descobri que era devido à geração incorreta do arquivo INI. Poste seu arquivo INI para que possamos analizar.

Olá @Juliomar Marchetti, Eu acho que acabei descobrindo. Ao salvar no arquivo de configurações o Ambiente=0 equivale a ambiente de produção, e, Ambiente=1 ambiente de homologação. Porém, ao gerar o arquivo INI da nota ou o XML, o ambiente deve ser somado +1, ou seja, tpAmb=1 equivale a produção e tpAmb=2 homologação. Seria isso mesmo?

Olá @Juliomar Marchetti, Obrigado pela resposta. Eu não expliquei corretamente: Eu tenho as configurações no AcbrLIb.INI. Essas configurações são feitas num janela específica para configurações e as mesmas são salvas antecipadamente à emissão de notas. Ao gerar os arquivos da NF-e (faço em arquivo INI), eu pego o valor de tpAmb já previamente cadastrado. Ao gerar uma NF-e o valor de tpAmb em produção é 1, como eu disse, já salvo previamente e replicado na NF-e. Nota emitida sem problemas. Porém, ao gerar um NFC-e, o valor 1 de tpAmb previamente salvo, provoca o erro acima, não emitindo o NFC-e. Ressalto que no arquivo INI e no XML do cupom, tpAmb=1, exatamente como no arquivo de configurações. Então, vou até o ACBrLib.INi, e faço a alteração de tpAmb para 0(zero) manualmente executo novamente a transmissão e dá certo, o cupom é emitido.

Então, Andei fazendo uns testes aqui e acontece mesmo como eu relatei. Uma mudança manual no valor de tpAmb de 1 pra 0 no INI, ou vice versa, faz com que o erro seja exibido. Pelo que percebi, o Acbr lê o tpAmb=1 corretamente para NF-e em produção, mas exige tpAmb=0 para NFC-e em produção.

Olá, Eu notei uma diferença quando emito uma NF-e com o ambiente setado nas configurações como 1, funciona normalmente e a nota é emitida em produção. Porém, se o tpAmb=1 e vou emitir um NFC-e, é retornado esse erro "Ambiente do XML (tpAmb) e diferente do configurado no Componente (Configuracoes.WebServices.Ambiente)". Aí basta ir no arquivo ACBrLib.INI e setar o tpAmb como 0(zero) manualmente, que o cupom é emitido em produção. Será que não existe uma discrepância entre emissão de NF-e e NFC-e?

Olá @Juliomar Marchetti Obrigado pela resposta. Então, eu posso ter entendido errado nas instruções mas a tag CNPJ está marcada como filho de tpIntegra. Portanto, se tpIntegra está setada como não a tag CNPJ passaria a ser opcional. Esse talvez seria o raciocínio lógico da coisa, mas como estaos lidando com a Fazenda...rsrsrs. Então CNPJ é exigido pra qualquer situação de tpIntegra?

Olá, Estou vendo que a tag tpIntegra está setada como NÃO. Mesmo assim há necessidade de se colocar o cnpj?

@Juliomar Marchetti Obrigado pela resposta, É verdade! A gente quer agradar o cliente mas tem certas coisas que são perda de tempo. Vou fazer um espelho aqui mas não vou fazer uma cópia de NF como a da imagem não. O uso do documento é por conta do cliente é claro, mas não quero dores de cabeça no futuro se é que me entende.

Pessoal, boa noite! É permitido a criação de um espelho de NFe no modelo da foto abaixo? Um cliente me solicitou mas fiquei na dúvida se isso é legal ou ilegal?

@Juliomar Marchetti, você tem razão. Mesmo não estando de posse de uma impressora para etiquetas, eu selecionei minha impressora padrão e o tempo de carga diminuiu muito. Muito grato pela ajuda!!

Olá @Juliomar Marchetti, Obrigado por responder! Então, as configurações são as iniciais da lib. Ainda não alterei nada.

Bom dia! Utilizo a AcbrLib no Visual Studio cm C# e WPF. Tenho em meu sistema uma tela única para as configurações do AcbrLib. Notei há um certo tempo uma demora um pouco exagerada para a inicialização das dlls. Resolvi então separar uma tela para cada uma, ou seja, uma para NFe, outra para NFSe, outra para Escpos e ETQ. Pois bem, ao finalizar a separação, notei que a demora acompanhou a AcbrLibETQ. Ela demora muito a ser inicializada. Vou passar uma imagem abaixo. A demora não prejudica o funcionamento da dll, porém achei estranho porque supera em muito as outras dlls. Fiz a medição em mili-segundos e o resultado foi impressionante. A carga é realizada da mesma forma para todas as dlls: ACBrPosPrinter posPrinter = new ACBrPosPrinter(_PastaIni); ACBrETQ _AcbrETQ = new ACBrETQ(_PastaIni); Vejam a diferença na imagem abaixo.

Na verdade verifiquei que no arquivo INI, se a tag VerificarImpressora for =1, o erro também ocorre. Se desativo no meu código o comando de LerStatusImpressora(), e, coloco a tag VerificarImpressora=0, as impressões são efetuadas sem problema.