[Erro ao transmitir NFe (Schema inválido)]

Após atualizar o componente ACBrNFe, e passar a utilizar as seguintes configurações:

ACBrNFe.Configuracoes.Geral.SSLCryptLib := cryWinCrypt;
 ACBrNFe.Configuracoes.Geral.SSLHttpLib := httpWinHttp;
 ACBrNFe.Configuracoes.Geral.SSLLib := libWinCrypt;
 ACBrNFe.Configuracoes.Geral.SSLXmlSignLib := xsLibXml2;
 ACBrNFe.SSL.SSLType := LT_TLSv1_2;

Passamos a receber o erro de SCHEMA INVÁLIDO, quando a pasta schemas é acessada pela Rede. \\Servidor\schemas.

Houve alguma alteração ou configuração que resolva esse problema?

[SAT Recusando forma de Pagamento Pix]

Entendi, alguém teve algum retorno das empresas de equipamentos? Até o momento não obtive resposta deles.

[SAT Recusando forma de Pagamento Pix]

Boa tarde,

Alguém já implementou as novas formas de recebimento previstas no Especificacao_SAT_v_ER_2_28_05.pdf pagina 100 ?

Sei que existem outros tópicos relacionados mas todos do ano passado. Alguém recentemente teve alguma nova posição a respeito?

[Windows Defender do Windows 10 e 11 bloqueando aplicação Delphi]

Em um determinado cliente, tenho um executável com data de 20/05/2022 que abre normalmente, tanto local como em rede. Ao trocar esse executável por um novo, ocorre o bloqueio. Já tentamos colocar como exclusão a pasta e o executável, mas nada resolve. Mais alguma sugestão?

[Windows Defender do Windows 10 e 11 bloqueando aplicação Delphi]

Gostaria de saber se mais alguém do fórum vem tendo problemas com o bloqueio de seus executáveis pelo Windows Defender do Windows 10 e 11. 

Mesmo adicionando o executável como exclusão no Windows defender não resolve o problema. 

Alguém passando pelo mesmo problema e alguma solução?

 

[danfe impresso errado]

Pessoal, boa tarde.

Apenas a título de informação, estávamos com problemas na impressão da DANFE no fastreport, a numeração de página estava saindo "Folha 1/2" sendo que havia apenas 1 página. Após utilizar o arquivo DANFeRetratoNovo.fr3 o problema foi resolvido.

[Rejeicao: Somatorio percentuais de GLP derivado do petroleo, GLNn e GLGNi diferente de 1]

Em 08/05/2018 at 17:30, Ges-tec Sistemas disse:

Boa tarde, estou com o mesmo problema.

teria alguem que esta emitindo, o exemplo de preenchimento destes campos.

Obrigado!

Também estamos enviando como 100% e esta validando e transmitindo. A soma dos 3 tem que dar 100%

 

[NFe 4.0 CST 60 - Combustível]

14 horas atrás, cefantacini disse:

Aqui, hoje, 18/03, consegui emitir várias, seguindo a orientação acima:

Imposto.ICMS.CST := cstRep60;

Aparentemente o problema está resolvido!

 

Bom dia, cefantacini conseguiu emitir alguma NF-e na versão 4.0 utilizando a cst 500 para empresas optantes pelo Simples Nacional?

 

[Impressão de etiquetas saindo errada depois da atualização]

1 hora atrás, Daniel Simoes disse:

Favor anexar os arquivos, e não as imagens...

A1 e A5 são comandos para impressão normal ou invertida... vou otimizar para não enviar esse comando, quando não for necessário...

Resolvido aqui pessoal, valew pela ajuda de todos.

Obrigado

[NFe 4.0 CST 60 - Combustível]

13 minutos atrás, Anderson Gaitolini disse:

Bom dia

 

Rejeição: Grupo de Tributação informado indevidamente [nItem: 1]

Significa que a rejeição é pelo motivo do grupo de tributação de ICMS não estar compatível, sendo assim não esperado para tal operação

Exemplo: Você está emitindo uma NFe com <ICMS60> e a mensagem 858:   Grupo de Tributação informado indevidamente  conforme as Notas técnicas (Nota Técnica 2016.002 - v 1.10) página 43 e (Nota Técnica 2016.002 - v 1.20), página 47 

Pode ser que esteja sendo esperado ICMS10, ICMS40..., tudo depende da situação, más é o caso a ser visto e interpretado.

Se atentar as notas de combustíveis que  estão sujeitas a exceções de acordo com certos códigos ANP previsto nas NT mencionadas a cima.

 

Env_NFe42180209000218000110550010000000111000260215.xml

Bom dia Anderson, tudo bem?

Por acaso você consegui transmitir alguma nota fiscal na versão 4.0 de um produto que tenha o código da ANP informando CST 60?

Se sim, poderia postar um XML?

Obrigado

[Impressão de etiquetas saindo errada depois da atualização]

10 minutos atrás, leandroaoa disse:

primeiro clica no botao command reset ele vai voltar a impressora pra configuracao de fabrica depois da um Send

Devo informar PPLA? Qual o valor em mm do campo Backfeed offset?

obrigado pela ajuda

[Impressão de etiquetas saindo errada depois da atualização]

34 minutos atrás, leandroaoa disse:

baixe o programa printer utility da argox e configure a opcao backfeed offset. eu sempre utilizo e nao tive problemas com avanco 

Boa tarde Leandro, estamos com a mesma impressora, com a mesma etiqueta, no mesmo computador. Se realizamos a impressão com a versão atual do ACBR a ultima etiqueta impressa fica embaixo do ribbon, se fizermos a impressão com a versão do ACBR anterior a ultima atualização o avanço do papel funciona corretamente.

Fiz a instalação do printer utility da argox, poderia me informar quais parâmetros devo preencher para configurar a opção backfeed offset?

Obrigado.

[Impressão de etiquetas saindo errada depois da atualização]

7 minutos atrás, Anderson Oliveira disse:

Opa, verifiquei agora que já houve atualização, vou verificar as correções...

 

Utilize a medida "etqDecimoDeMilimetros"

[Impressão de etiquetas saindo errada depois da atualização]

23 horas atrás, Daniel Simoes disse:

Analise o resultado de impressão, de ambas as versões...

Modifique a porta para algo como: 'c:\temp\etq.txt'...

Com isso você poderá capturar os comandos enviados na versão anterior e na atual, e apurar a diferença...

Já no SVN...

 

Boa tarde Daniel, realizei  a análise que me sugeriu, salvando os comandos enviados em ambas as versões para um arquivo texto.

A única diferença que na versão atual do ACBR esta sendo impresso o comando "A1" que não existia na versão antes da atualização.

Pesquisei no manual PPLA mas não encontrei a função desse comando "A1", poderia me ajudar?

Segue em anexo a imagem dos dois arquivos textos, antes e após a atualização.

 

 

[Fundo de Combae a Pobreza (CST 60 e 500) - FCP ST RET]

Em 21/02/2018 at 11:26, Nelson Santos disse:

Isto não só impacta na emissão de NF-e, mas também para NFC-e , pois o CST 60 ou CSOSN 500 também pode ser usado para NFC-e, assim temos que realizar os mesmos cálculos.

Ainda agregando à última informação que acabei de citar, imagine que o mesmo produto tenha vários fornecedores em UF's diferentes, com aliquotas diferentes de ICMS/FCP (totalmente possível).

Imagine também que foram feitas várias compras, mas a última compra teve uma aliquota menor que as outras. Como estou propondo guardar somente o último percentual da compra, estaremos usando um percentual menor que todas as outras compras...

 

Ótima colocação Nelson Santos, pelo que estamos vendo, para que as operações com CST 60 ou CSOSN 500 (icms substituição retido) sejam feitas corretamente, é necessário uma certa rastreabilidade desde a entrada do produto na empresa (armazenando as alíquotas e valores do icms st) para poder informar no momento da saída, o que torna o processo extremamente complexo.

 

Qualquer novidade ou forma que encontrar de trabalhar com esta situação poste aqui no fórum.

 

[Impressão de etiquetas saindo errada depois da atualização]

Em 23/02/2018 at 16:53, Daniel Simoes disse:

Faça testes com as propriedades: BackFeed e Avanco

Boa tarde, testamos as propriedades BackFeed e Avanco, após ativar o componente conforme imagem em anexo.

Mas a impressora continua não avançando e depois puxando a última etiqueta para fazer a impressão. Se voltarmos uma versão antes da atualização do ACBR, na mesma impressora com as mesmas etiquetas o avanço funciona corretamente.

Alguma ideia do que pode estar ocorrendo?

Obrigado pela atenção de todos.

[Impressão de etiquetas saindo errada depois da atualização]

2 horas atrás, Daniel Simoes disse:

Deixe zerado

Boa tarde, fizemos alguns testes e com a unidade etqDecimoDeMilimetros voltou a imprimir com o posicionamento correto.

Obrigado aos amigos pela ajuda.

Unica questão é que, realizamos os testes em 2 impressoras Argox os 214 plus, em ambas, antes da atualização a impressora fazia a impressão e avançava 1 etiqueta, ao mandar a próxima impressão ela puxava a etiqueta e depois imprimia, não desperdiçando nenhuma etiqueta. Agora, a etiqueta está ficando embaixo do ribbon, se avançar manualmente quando imprimir a próxima não puxa para depois imprimir.

Obs: São as mesmas impressoras, e o mesmo rolo de etiqueta. 

Alguém tendo o mesmo problema.

[Impressão de etiquetas saindo errada depois da atualização]

38 minutos atrás, Daniel Simoes disse:

Você está informando or90

Notei que o método TACBrETQPpla.ConverterUnidade poderia ficar com um valor indefinido, o que poderia explicar esses problemas.. apliquei uma possível correção..

Para compatibilização com a versão antiga... usem: etqDecimoDeMilimetros

Boa tarde, atualizamos os fontes, alteramos o componente para etqDecimoDeMilimetros. A etiqueta foi impressa, porém desposicionada e após imprimir ela avança muitas etiquetas (até desligar a impressora). Alguém mais já realizou o teste com os fontes atualizados utilizando a opção: etqDecimoDeMlimetros?

Estou usando da seguinte forma, utilizávamos 600 no avanço com a versão antiga:

 

[Impressão de etiquetas saindo errada depois da atualização]

10 minutos atrás, Daniel Simoes disse:

95 e 710 milímetros  ?? deve ser uma etiqueta bem grande...

As etiquetas são pequenas (3,4 cm x 2,3 cm) por exemplo. Então a questão dos milímetros não estava funcionando corretamente, essas medidas foram colocadas fazendo testes de acordo como os tamanhos da demo antiga e posicionando nas etiquetas.

 

Por isso o impacto desse acerto é tão grande, pois não temos como simples alterar as medidas, teríamos que testar etiqueta por etiqueta, e isso se torna inviável devido a grande quantidade. Acredito que o pessoal que postou aqui no tópico estão com os mesmos problemas. O Leandroaoa postou as medidas semelhantes, números bem altos, conforme imagem em anexo.

[Impressão de etiquetas saindo errada depois da atualização]

2 minutos atrás, Daniel Simoes disse:

Ok... como já foi dito.. foi corrigida a conversão de Milímetros para que a mesma se comporte da maneira correta... ou seja... se você informar 5, isso DEVE equivaler a 5 milímetros na etiqueta...

Qual valor você informava ?

Vários tamanhos, pois são inúmeros tamanhos e tipos e etiquetas, que foram criados baseados nos tamanhos de exemplos da demo antiga.

[Impressão de etiquetas saindo errada depois da atualização]

Agora, armando.boza disse:

Entendemos Daniel que sempre existiram as unidades de medida e que elas não eram respeitadas, mas acredito que com essa alteração atrapalhou bastante gente que estava tudo configurado para as medidas que "funcionavam" com a etqMilimetros, então creio que quando foi ajustado o fonte, se fosse possível, deveria ter ficado uma opção de unidade da maneira "antiga" tipo etqMilimetrosAntiga, assim ficava certo pra todos.

Bom dia, isso armando.boza, essa seria uma opção perfeita, pois todos os usuários poderiam ter tempo hábil para ir convertendo suas medidas conforme a necessidade (para a forma correta de milímetros) e não pararia todos os clientes de uma vez.

[Impressão de etiquetas saindo errada depois da atualização]

17 horas atrás, leandroaoa disse:

Daniel acho que o pessoal esta querendo dizer é o seguinte qual unidade de medida usar pois antes nao tinha isso. vou postar aqui o codigo do demo antigo então todos usaram isso como padrão mas qual unidade usar para que não precise alterar. não sei se ficou claro mas tente imprimir por esse codigo que e do demo antigo antes das alteracoes. 

  with ACBrETQ do
  begin
     if Modelo = etqPpla then
      begin
        ImprimirTexto(orNormal, 2, 1, 2, 180, 15, 'BISCOITO REC 335G');
        ImprimirTexto(orNormal, 2, 1, 1, 140, 15, 'CHOC BRANCO');
        ImprimirBarras(orNormal, 'F', '2', '2', 20, 10, '7896003701685', 70);

        ImprimirTexto(orNormal, 2, 1, 2, 180, 315, 'BISCOITO RECH 335G');
        ImprimirTexto(orNormal, 2, 1, 1, 140, 315, 'CHOC BRANCO');
        ImprimirBarras(orNormal, 'F', '2', '2', 20, 315, '7896003701685', 70);

        ImprimirTexto(orNormal, 2, 1, 2, 180, 620, 'BISCOITO RECH 335G');
        ImprimirTexto(orNormal, 2, 1, 1, 140, 620, 'CHOC BRANCO');
        ImprimirBarras(orNormal, 'F', '2', '2', 20, 620, '7896003701685', 70);
      end
     else
      begin
        ImprimirTexto(orNormal, 2, 1, 3, 15, 55, 'BISCOITO REC 335G');
        ImprimirTexto(orNormal, 2, 1, 1, 80, 55, 'CHOC BRANCO');
        ImprimirBarras(orNormal, 'E30', '2', '2', 120, 55, '7896003701685', 080, becSIM);

        ImprimirTexto(orNormal, 2, 1, 3, 15, 365, 'BISCOITO RECH 335G');
        ImprimirTexto(orNormal, 2, 1, 1, 80, 365, 'CHOC BRANCO');
        ImprimirBarras(orNormal, 'E30', '2', '2', 120, 365, '7896003701685', 080, becSIM);

        ImprimirTexto(orNormal, 2, 1, 3, 15, 670, 'BISCOITO RECH 335G');
        ImprimirTexto(orNormal, 2, 1, 1, 80, 670, 'CHOC BRANCO');
        ImprimirBarras(orNormal, 'E30', '2', '2', 120, 670, '7896003701685', 080, becSIM);
      end ;

     Imprimir(StrToInt(eCopias.Text), StrToInt(eAvanco.Text));
     Desativar;
  end;

Bom dia pessoal, alguém já encontrou uma solução para o problema? Estamos enfrentando as mesmas dificuldades, diversos tipos de impressões em equipamentos diferentes, e após a atualização tudo desconfigurado ou não imprime. Acompanhando a discussão neste tópico, vimos que o problema ocorre devido a alterações (acertos) nos padrões de medidas. Nossas impressões estão utilizando as medidas que o amigo leandroaoa postou, que acredito que estavam em "Dots" mesmo o componente passando a unidade como milímetros. As medidas que estamos usando foram baseadas no fonte antigo da demo. Alguém conseguiu fazer a conversão das medidas ou fazer alguma configuração que não necessite alterar todas as impressões?

Tentamos alterar no componente para "Dots" mas não funcionou, acredito que esteja pegando sempre "etqMilimetros" (desconsiderem caso eu esteja equivocado), conforme o pessoal já comentou aqui no tópico mas não teve resposta.

 

 

 

[Fundo de Combae a Pobreza (CST 60 e 500) - FCP ST RET]

1 minuto atrás, Nelson Santos disse:

@ivan_juste, a regra sobre a informação das tagsvBCSTRet, vICMSSTRet quando for CST 60 ou CSOSN 500 estão na NT 2016/002 1.42, inclusive com Regras de Validação:

A minha dúvida é com relação à qual seria o melhor procedimento, menos impactante, para guardar estas informações.

Agregando ao mencionado por @cleitonprogdelphi@hotmail., e já pensando no que citei sobre vários fornecedores, pensei em sempre guardar o percentual de ST e FCP em forma de percentual da última compra.

Assim, posso aplicar o mesmo percentual quando estiver efetuando a venda daquele mesmo produto, na quantidade e valor da venda.

 

Isso mesmo Nelson, me refiro a compra do mesmo item de vários fornecedores.

[Fundo de Combae a Pobreza (CST 60 e 500) - FCP ST RET]

4 minutos atrás, Nelson Santos disse:

Como mencionado por @cleitonprogdelphi@hotmail., temos que guardar a ST e FCP na entrada da mercadoria.

No entanto, suponha que esta mesma empresa citada no exemplo pelo @cleitonprogdelphi@hotmail. compre de um fornecedor em SP, outra compra de ES e outra de MG...com ST e FCP diferentes... Qual será a BC//Percentual à usar ? da última compra ? média das compras ? 

 

 

Boa pergunta Nelson Santos, mais uma vez são lançadas regras sem explicações. Estamos com as mesmas dúvidas.

[NFe 4.0 CST 60 - Combustível]

41 minutos atrás, fpaloschi disse:

Para mim ainda nada de retorno. Alguém possui alguma informação diferente ou prazo para eles liberarem/ajustarem essa validação?

Boa tarde fpaloschi, nós ainda não tivemos nenhum retorno também. Estamos aguardando alguma posição para continuar a implementação da NF-e 4.0.

Qualquer novidade poste no fórum.