Jump to content

logo_acbr_paygo.png

Chegou o TEF ACBr PayGo
Seja um revendedor e ofereça uma solução completa para seu cliente.


botao_saibamais.png

beneficios.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

Sulsoftware

Membros
  • Content Count

    45
  • Joined

  • Last visited

Community Reputation

4 Neutral

About Sulsoftware

  • Rank
    Membro
  • Birthday 05/18/1965

Contact Methods

Profile Information

  • Sexo
    Masculino
  • Localização
    Novo Hamburgo

Recent Profile Visitors

998 profile views
  1. Boa tarde Ítalo, como está ?? Grato pelo retorno. Sim, percebi da modificação desde a minha última atualização e também havia deduzido sobre a coincidência de numeração das NFSe. A questão é que "o cliente" (e o nosso sistema) já estava acostumado a localizar a nota pelo numero específico e nos avisaram da modificação da numeração + serie. Imaginei que talvez tivesse alguma configuração ou modificação no fonte que poderia fazer para "não" gravar a numeração+serie na nomenclatura dos arquivos XML e PDF. Mas, caso não tenha, tudo bem, o cliente que se acostume. Abraço e grato pelo retorno,
  2. Bom dia pessoal, Utilizo o ACBRNFSe para emissão das notas de serviço com o provedor ISSNET. Verifiquei que os arquivos XMLs e PDFs estão sendo gravados com o número da Serie após o numero da NFSe (ex: 35793-nfse.xml), o último digito (3) é a série do documento, o número da NFSe é 3579). Minha dúvida é se existe alguma configuração no componente para que NÃO grave o numero da serie logo após o numero da NFSe ? Anteriormente a minha última atualização não gravava esta informação no nome do arquivo, apenas o numero da NFSe. Desde já, grato pelo retorno, Abraço a todos, Denis Monteiro
  3. Bom dia pessoal, Alguma novidade quanto ao erro do tópico ? Aqui em Novo Hamburgo RS está ocorrendo o mesmo erro. Abraço a todos!!
  4. Sim, deduzi isso, mas, será corrigido isso nos fontes ? pois o vDesc normalmente não possui valor e atualmente está ocorrendo o erro tanto na homologação como na produção, com a versão 4.0. Na versão 3.10 passa normalmente. Abraço,
  5. Boa tarde pessoal.. mesmo atualizando os Schemas, o XML não gera o vDesc se não informado o desconto. Alguma outra atualização ? Abraço,
  6. boa tarde, grato pelo retorno. Sim, foi o teste que fiz, adicionei o valor do vDesc ao VOrig e passou. Mas, aguardemos pela atualização da SEFAZ. Abraço
  7. Bom dia pessoal... Aqui no RS, em Homologação, tbm ocorre o erro citado no tópico. Fiz um teste informando o vDesc e, desta forma, ele grava a tag vdesc no XML e passa. Alguém sabe se precisa atualizar os fontes ou os Schemas para resolver esse erro ? Abraço todos e um ótimo jogo..
  8. olá José, bom dia... Na verdade em qualquer operação com a NFe, apresenta a mensagem de erro em questão ( Erro Interno: 0 Erro HTTP: 500, Inativo e Inoperante). Tanto impressão, reimpressão, consulta de Status, etc. Abç,
  9. RS não está funcionando... e a principio a disponibilidade está OK.
  10. boa tarde pessoal, Em nossa aplicação estamos enviando os seguintes comandos, no caso da ve400: ACBrNFe.Configuracoes.Geral.SSLLib := libWinCrypt; ACBrNFe.SSL.SSLType := LT_all; ACBrNFe.Configuracoes.Geral.SSLCryptLib := cryWinCrypt; ACBrNFe.Configuracoes.Geral.SSLHttpLib := httpWinHttp; ACBrNFe.Configuracoes.Geral.SSLXmlSignLib := xsMsXml; e as configurações no IE estão cfe. imagem. já trocamos para LT_TLSv1_2 e ocorre o mesmo erro. Na ve310 está funcionando normalmente. Se alguém tiver alguma luz, agradeço. Abraço a todos,
  11. Bom dia Italo, como está ? Estou atualmente com a mesma situação citada neste tópico. Terminamos o desenvolvimento da aplicação mas não temos como testar sem certificado próprio com autorização para emissão do CT-e. Você poderia passar este certificado disponibilizado pelo SEFAZ-RS para que possamos efetuar os testes gerais na aplicação ? Ou se já existe algo mais apropriado atualmente ? Abraço e bons negócios,
  12. Boa tarde Daniel, Valeu, grato pelo esclarecimento. Estava usando a instrução errada então. Abraço e bons negócios,
  13. Bom dia Daniel, grato pelo retorno. Aí que está. Não dá mensagem de erro, apenas não envia o e-mail para o endereço informado em ACBRMail1.AddReplyTo := [email protected] Antes da atualização, enviava o e-mail para: ACBRMail1.AddAdress ACBRMail1.AddCC ACBRMail1.AddReplyTo Agora só está enviando o e-mail para o AddAdress e o AddCC, parou de enviar para o AddReplyTo Abraço,
  14. Bom dia a todos, Ontem efetuei a atualização de todo o ACBR e após esta atualização o componente ACBRMail na função AddReplyTo não está funcionando. Possuo esta função em dezenas de processos no sistema e o email enviado estava sendo copiado para o destinatário em AddReplyTo, porém após a atualização não está mais enviando. Alguém poderia dar uma dica aonde olhar o problema ? Abraço a todos,
  15. Bom dia Daniel e demais, Grato pelo retorno, mas, atualizei o Fortes e instalei novamente e o erro persiste com os campos truncados. Resolvi apenas colocando os campos truncados como AutoSize=true no formulario. Abraço a todos,
×
×
  • Create New...