[Serie da NFSe no nome dos Arquivos]

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

[Data Emissão Fora Da Vigência]

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!!

[905 - Rejeicao: Campos do grupo Fatura nao informados]

24 minutos atrás, BigWings disse:

Atualizar os schemas não vai fazer com que a tag seja gerada no XML.

Para as tags vOrig, vDesc, vLiq serem geradas é preciso que seja informado um valor maior que zero.

Lembrando que essa rejeição deve acontecer apenas em homologação, em produção a previsão para ativação da regra de validação é 03/09/2018.

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,

[905 - Rejeicao: Campos do grupo Fatura nao informados]

4 horas atrás, BigWings disse:

Foi liberado hoje pacote de atualização de Schemas que permite a geração das tags vOrig, vDesc e vLiq do grupo fat com valor zero.

Os novo schemas já se encontram atualizados no repositório.

Entretanto, é preciso que as SEFAZ também atualizem, senão pode haver rejeição por falha de schema.

Fazendo a validação do XML na SEFAZ-RS, com um XML com a tag vDesc = 0,00 acusa erro, pois ainda não atualizaram os schemas:

A sugestão é incluir um valor qualquer no vDesc, somando também ao vOrig.

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,

[905 - Rejeicao: Campos do grupo Fatura nao informados]

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

 

[905 - Rejeicao: Campos do grupo Fatura nao informados]

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

 

[Consulta Cadastro]

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ç,

 

[Consulta Cadastro]

RS não está funcionando...

e a principio a disponibilidade está OK.

[Consulta Cadastro]

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,

 

[Rejeição: Emissor não habilitado para emissão do CT-e]

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,

 

[ACBRMail com erro no AddReplyTo]

Boa tarde Daniel,

Valeu, grato pelo esclarecimento.

Estava usando a instrução errada então.

Abraço e bons negócios,

 

[ACBRMail com erro no AddReplyTo]

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,

 

[ACBRMail com erro no AddReplyTo]

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,

 

[Impressão PDF erros nos valores dos itens]

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,

 

[Impressão PDF erros nos valores dos itens]

Boa tarde Juliomar,

Está acontecendo em todos os clientes que usam a aplicação, inclusive aqui na empresa, quando efetuamos os testes.

Muito estranho.

Grato pelo retorno,

segue um PDF, se ajuda a detectar o erro.

 

43170613539571000140550010000062331767732818-nfe.pdf

[Impressão PDF erros nos valores dos itens]

Bom dia pessoal...

Desculpem estar colocando este erro como resposta mas não encontrei nenhum tópico sobre o assunto, e este tópico se relaciona com o erro que vem ocorrendo.

Ocorre que, somente na geração do PDF automático pelo Fortes Report, Está ocorrendo uma gravação errada do PDF, truncando alguns número na Danfe, conforme imagem em anexo.

Já tentei de tudo e não consegui uma solução.

Alguém teria alguma dica sobre este erro ? Acontece somente na geração do PDF pelo ACBR. Se mando imprimir em PDF, a gravação do PDF fica normal.

Grato a todos,

Abraço,

[Provedor Tecnos]

olá Italo, 

Grato pela ajuda...

Vou tentar gerar as NFSe mas agora parece que não está aceitando nenhum numero de lote, como se não estivesse recebendo a numeração da RPS disponivel, tanto na homologação como na produção.

Abraço,

 

[Provedor Tecnos]

sim Italo, são esses Schemas...

Ajustei agora a tag Validar=0 abaixo... e passou o erro do campo.. passou para outro erro, mas creio que agora é questão de configuração..

Isso ??

 

[Provedor Tecnos]

Boa tarde Italo,

Alterei agora para 2.00 e voltou o erro inicial..

Os fontes havíamos atualizado pela manha...

Abraço,

[Provedor Tecnos]

olá Italo, boa tarde,

a versão está como 2.01

abraço

[Provedor Tecnos]

16 horas atrás, Rodrigo Crovador disse:

Boa tarde a todos. Faz algum tempo que não passo por aqui 

 

Bom, vamos lá. Não migrei ainda para o trunk2 pois são muitos clientes a atualizar, mas farei o possível para ajudar. O atributo ID da tecnos é realmente grande, conforme citado no manual da Tecnos (http://help.nfse-tecnos.com.br/main_ws/contribuinte/notaeletronica.aspx). A formatação é a seguinte:

 

<LoteRps Id="12013915933760001020000000000000001" versao="20.01">

       <!--identificador do Lote de Rps, por padrão é esperado a composição-->

       <!--1                              - identificação de envio de lote sincrono-->

       <!--0000                         - ano do lote enviado no formato AAAA-->

       <!--00000000000009       - numero do CPF/CNPJ do contribuinte formatado com 14 posições-->

       <!--0000000000000009   - número sequencial do lote formatado com 16 posições-->

 

 

    <InfDeclaracaoPrestacaoServicoId="1915933760001020000000000000007">

       <!--identificador do Lote de Rps, por padrão é esperado a composição-->

       <!--1                             - Tipo de operação, no caso envio-->

       <!--91593376000102      - Documento do prestador formatado com 14 posições-->

       <!--0000000000000007   - Número do RPS formatado com 16 posições-->

 

Verifiquem no XML de vocês se está tudo certo com os ID's e consultem também o layout no link acima. Caso esteja, recomendo procurar o suporte da tecnos por email. Demoram um pouco mas respondem e são prestativos. 

 

olá Rodrigo, bom dia,

Já revisamos a formatação do ID e aparentemente está conforme a segunda opção que vc colocou acima (literal1 + CNPJ14 + Lote16).

O erro somente ocorre com a nova versão trunk2, com o executável da versão trunk1 funciona normalmente.

Mesmo diminuindo o Lote de 16 posições para 5 posições passa a ter outro erro de não conseguir gerar o XML.

Grato pelo retorno,

Abraço,

 

 

 

[Provedor Tecnos]

olá Italo e Diego,

Já atualizamos os Schemas do site da Technos e nada feito, continua com o mesmo erro, alguma luz ???

Abraço a todos,

 

[Nota eletronica em PDF]

bom dia pessoal!!
Estamos com o mesmo problema...
A questão é que são em vários clientes que ocorre o problema e, no preview do Fortes ele aparece normalmente a Danfe, somente quando salva em PDF.

Inclusive se voce salva no PDFCReator por exemplo, ele salva perfeitamente.

É somente na função do SalvaPDF do Fortes Report.

Alguma luz ?

Abraço a todos,

 

[XML da NFSe gerado pelo Trunk2]

bom dia pessoal...

Estamos com o mesmo problema e, pelo visto, o componente busca os dados da prefeitura para gerar o XML e imprimir a NFS-e.

E na prefeitura o endereço e bairro estão com os caracteres especiais.

Alguma dica de como retirar os caracteres especiais e o <b> de outrasinformacoes ?

Abraço

 

[Erro ao ajustar INTERNET_OPTION_CLIENT_CERT_CONTEXT: 12046]

olá Leandro,

Fizemos de acordo com sua orientação e funcionou !!!!

Valeu a força e o empenho!!

Abraço a todos.