ivan_juste
-
Total de ítens
66 -
Registro em
-
Última visita
Tipo de Conteúdo
Blocks
Notes ACBrLibNFe
Fóruns
Downloads
Calendário
Posts postados por ivan_juste
-
-
Entendi, alguém teve algum retorno das empresas de equipamentos? Até o momento não obtive resposta deles.
-
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?
-
-
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?
-
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.
-
-
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?
-
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
-
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.
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
-
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
-
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.
-
7 minutos atrás, Anderson Oliveira disse:
Opa, verifiquei agora que já houve atualização, vou verificar as correções...
Utilize a medida "etqDecimoDeMilimetros"
- 1
-
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.
-
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.
- 1
-
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.
-
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.
-
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:
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
Erro ao transmitir NFe (Schema inválido)
em ACBrNFe
Postado
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?