Jump to content

110.png

Curso Gratuito para todos Usuários
+ Super Treinamento Assinando o SAC Anual

botao_campanha_thulio.png

sem_ttulo-620.fw_-e1583866078274.png 

Curso Dominando o ACBrMonitor
Novo Módulo Soluções de Varejo
Assine o SAC ACBr em qualquer plano e tenha acesso

Saiba Mais

Balança SM100 performance surpreendente

Tecnologia Japonesa   Teclado e Visor resistentes a água
Consumo inteligente de etiquetas   Baixo custo de manutenção
Comunicação Ethernet e WIFI independentes

Saiba Mais

Impressora de Etiquetas ELGIN - L42 PRO

Protocolos PPLA, PPLB, ZPL, EPL (automático)
Porta USB padrão Opcionais: Ethernet, Serial, Paralela
Sensor de Etiquetas Móvel Garantia de 18 meses

Saiba mais

EMERSON CREMA

Membros
  • Content Count

    26
  • Joined

  • Last visited

Community Reputation

2 Neutral

About EMERSON CREMA

  • Rank
    Membro

Profile Information

  • Sexo
    Masculino
  • Localização
    SANTO ANDRÉ

Recent Profile Visitors

630 profile views
  1. Você tem razão, tinha ficado verde em algum momento mas voltou a ficar indisponível, vejo que ainda teremos uma longa estrada...
  2. Boa tarde. Estranho, o mesmo está acontecendo em um cliente em Rondonia, estou tentando todas as dicas disponíveis, e nada.
  3. E o pior é q não é a primeira vez, é uma luta sem fim, mas segue a vida, obrigado a todos!
  4. Em ambiente de homologação voltou a funcionar neste exato instante, tinha feito uma a 2 minutos, e deu a rejeição 905, agora tentei novamente e validou. Eu já imaginava q o problema era por lá mesmo.
  5. Parece que não está tão simples assim. Eu tenho o ACBr atualizado hoje, está com CamposFatObrigatorios = True, o campo vDesc é gerado no XML, os Schemas estão atualizados com o que está disponivel no site no Sefaz, e ainda assim é rejeitado com o código 905. Tá me parecendo que é mais uma atrapalhada lá no Sefaz mesmo. Ah, e só mais 1 detalhe, realmente é só em homologação, clientes com a mesma versão do meu sistema em produção estão ok.
  6. Só para constar, acabei de utilizar em um cliente que também estava desde quinta-feira passada sem emitir NF-e, já havia testado todas as outras possibilidades, e esta do registro foi a que resolveu. Obrigado Felipe.
  7. Souza, isto vem dando certo? Pergunto porque na maioria dos clientes com Windows 10 está tudo ok, mas alguns não. Desde já agradeço Abraço!
  8. Bom dia! Você conseguiu resolver este problema? Estou passando pela mesma situação hoje, e apenas em alguns clientes. Desde já agradeço. Att, Emerson Crema.
  9. Tive o mesmo problema hoje, do nada, também atualizei e resolveu 100%! Obrigado também.
  10. Eu concordo com tudo o que vc diz, seria o perfeito e lógico, porém isto está sendo feito baseado em uma situação que um cliente tem de nota de importação, ele passou exatamente desta forma, e como sempre, não abre mão de que seja de outra forma. O chato é que sempre há a alegação que não consegue retirar a mercadoria do porto se não for exatamente da forma que é informado. Veja o original do XML que o cliente forneceu: Sim, se deixar a base de cálculo zerada é validado, veja:
  11. O rejeitado foi incorreto, é este outro. NFE_rejeitado.xml
  12. Bom dia! Sim, claro, sem problemas. Seguem os anexos. No arquivo NFE_rejeitado.xml, o retorno é o seguinte: Nota(s) não confirmadas: 61946->Rejeição: Valor do ICMS da Operação no CST=51 difere do produto BC e Alíquota. Mais uma vez, obrigado. Abraço! NFE_aprovado.xml NFE_rejeitado.xml
  13. Será possível esta alteração? Pois não vejo outra forma, se não tem como validar a NFe sem isto.
  14. Sim, eu até sei que é opcional, ao menos na teoria, mas na prática não é o que acontece. Ao meu ver também "NÃO" é muito lógico ter que enviar um valor zerado ou vazio. O erro é o seguinte: Rejeição: Valor do ICMS da Operação no CST=51 difere do produto BC e Alíquota E não tem jeito, se eu informar as tags com zero, blz, é validado, se suprimir as tags acontece esta rejeição.
  15. Bom dia a todos! Passei uma situação semana passada com relação ao CST 51 (diferimento), onde precisava colocar a tag <pICSMS> com zero, além de outras tags como <vICMSOp>, <vICMSDif>, etc. Porem neste caso, a rotina do contida em pcnNFeW.pas suprime estas tags no XML, quer dizer, elas não são geradas caso tenham o valor zero. Mas isto gera rejeição, ao menos no ambiente 4.0 de webservices. Mas notei que é utilizada a procedure wCampo(), e existe o parâmetro "ocorrencias", que hoje é setado com 0 (zero), mas setando para 1 (um), a tag é gerada mesmo com o conteúdo zero. Gostaria de saber se é possível fazer a alteração disto para o cst 51, pois como eu mencionei, não há condições de validar a NFe sem esta alteração. Segue a imagem do ponto onde encontra-se a programação a ser alterada: Minha sugestão, já alterando os campo necessário (parâmetro "ocorrencias" com o valor 1 (um): Gerador.wCampo(tcStr , 'N13' , 'modBC' , 01, 01 , 1, modBCToStr(nfe.Det[i].Imposto.ICMS.modBC), DSC_MODBC); Gerador.wCampo(IIf(Usar_tcDe4,tcDe4,tcDe2), 'N14' , 'pRedBC' , 01, IIf(Usar_tcDe4,07,05), 1, nfe.Det[i].Imposto.ICMS.pRedBC , DSC_PREDBC); Gerador.wCampo(tcDe2 , 'N15' , 'vBC' , 01, 15 , 1, nfe.Det[i].Imposto.ICMS.vBC , DSC_VBC); Gerador.wCampo(IIf(Usar_tcDe4,tcDe4,tcDe2), 'N16' , 'pICMS' , 01, IIf(Usar_tcDe4,07,05), 1, nfe.Det[i].Imposto.ICMS.pICMS , DSC_PICMS); Gerador.wCampo(tcDe2 , 'N16a', 'vICMSOp' , 01, 15 , 1, nfe.Det[i].Imposto.ICMS.vICMSOp , DSC_VICMS); Gerador.wCampo(IIf(Usar_tcDe4,tcDe4,tcDe2), 'N16b', 'pDif' , 01, IIf(Usar_tcDe4,07,05), 1, nfe.Det[i].Imposto.ICMS.pDif , DSC_PICMS); Gerador.wCampo(tcDe2 , 'N16c', 'vICMSDif' , 01, 15 , 1, nfe.Det[i].Imposto.ICMS.vICMSDif , DSC_VICMS); Gerador.wCampo(tcDe2 , 'N17' , 'vICMS' , 01, 15 , 1, nfe.Det[i].Imposto.ICMS.vICMS , DSC_VICMS); Espero mais uma vez estar contribuindo positivamente. Um ótima semana a todos. Grande abraço! Emerson Crema Max Scalla Informática Ltda.
×
×
  • Create New...