-
Total de ítens
325 -
Registro em
-
Última visita
-
Days Won
1
Tipo de Conteúdo
Blocks
Notes ACBrLibNFe
Fóruns
Downloads
Calendário
Posts postados por WINDEL
-
-
Boa tarde, na pasta Report dos exemplos do ACBR, existia um fr3 do modelo danfe do NFC-e A4, mas identifiquei um problema nele, não estava mostrando as OBS, mesmo estando dentro do XML, então fui atualizar o componente, para ver se vinha um modelo novo, e o tortoise acabou excluindo ele, alguém sabe alguma coisa sobre este modelo A4?
Se o acbr parou de dar suporte?
-
Olá BigWings, obrigado pelo seu retorno!
Vou tentar usar isso para convencer o Sefaz que há esse furo no layout deles e ver como proceder nessa situação.
Assim que eu tiver outro retorno deles vou postar o desfecho da situação aqui.
Muito obrigado pela ajuda de todos vocês.
- 2
-
Boa tarde pessoal! Obrigado pelo retorno!
Respondendo ao BigWings:
Sim nesse caso o tomador do serviço é um não contribuinte, trata-se da Secretaria de Educação do Rio Grande do Sul (CNPJ 92941681000100). Essa secretaria tem várias inscrições estaduais, porem nenhuma para a cidade de Porto Alegre. Fiz a consulta pelo próprio site do Sefaz RS.
Respondendo ao Amarildo:
Segue anexo o xml original gerado com o grupo "toma" e sem a tag de IE, já que o tomador está definido como não contribuinte.
OBS: se enviar para o portal esse xml ocorre a rejeição 719 - " IE do Tomador não informada"
-
Verifiquei o emissor gratuito de conhecimentos de carga disponibilizado pelo Sebrae, porem aquele não emite CTe-OS, somente conhecimentos modelo 57.
Portanto, se alguém tiver passado por isso ou por alguma situação similar, estou aberto a sugestões.
Muito obrigado!
- 1
-
Mais uma vez agradeço seu retorno Ítalo.
Estive em contato com eles mais uma vez, segue a resposta confirmando o uso do grupo "toma4" no CTe-OS. Pelo o que dizem, seria nesse caso onde o tomador é não contribuinte.
Isso tudo não está fazendo sentido, por isso vamos verificar qual o comportamento do emissor gratuito para um CTe-OS nessa mesma situação.
- 1
-
Primeiramente, muito obrigado pelo retorno Ítalo!
Pois é, eu tambem tinha esse entendimento que você comentou acima, inclusive a um bom tempo emitimos o CTe OS pelo componente dessa forma e nunca houve problema.
Porem enviando desse jeito, o xml não aprovou mostrando a rejeição 719 "IE do Tomador não informada" e o retorno que obtive do Sefaz RS, me diz o seguinte (vou colar a imagem do email aqui, mas se necessário posso lhe encaminhar o email tambem):
OBS: retornei esse email para eles pedindo um exemplo de como ficaria então esse xml, pois creio que seja um equívoco da parte deles.
-
Boa tarde!
Queria ver se podem me ajudar ou sugerir alguma possível solução para o meu caso.
Estou tendo problemas com o preenchimento dessas tags do grupo "toma", que foram indicadas acima.
Tive que enviar um CTe OS onde o tomador do serviço é não contribuinte (no caso indIEToma = 9 ), porem o meu xml não aprova, dizendo que a IE do tomador é inválida. Entrei em contato com o Sefaz-RS e eles me esclareceram que eu deveria estar enviando o grupo "toma4" e que esse outro grupo "toma" sugerido acima é na verdade Opcional para excesso de bagagem.
Verificando o manual, realmente encontrei o que eles estavam falando, conforme segue:
Com base nisso, fiz algumas alterações no meu fonte e passei a alimentar os campos do grupo "toma4" ao invés do mencionado anteriormente, porem o componente parece ignorar o preenchimento deles e nesse caso não preenche tomador nenhum no xml gerado, ficando conforme o xml anexo.
OBS: pelo o que verifiquei a impressão do CTe OS tambem estaria comprometida uma vez que busca informações do grupo "toma" ao invés do "toma4".
-
Obrigada por seus retornos. Entrarei em contato com o cliente.
- 1
-
Boa tarde, estamos com problema em alguns clientes que estão perdendo o certificado das NFe por causa do ACBR.
Recebemos a seguinte observação:
"Foi constatado que existe na programação dos emissores a maioria deles com base no emissor (ACBR) um comando que separado de sua função correta realiza a exclusão/exportação do certificado de dentro da mídia, isso acontece devido a uma falha de comunicação com a mídia onde está armazenado o certificado, durante o processo esta falha de comunicação no caso o comando indicado fica em CACHE e ao retomar o processo e inserir a senha o usuário autoriza este comando, que por estar separado de sua função acaba por remover/exportar o certificado de sua mídia."
Alguém já teve este mesmo problema? Ou sabe de algum motivo que levaria o ACBR causar a exclusão do certificado?
-
Boa tarde Italo,
Conseguimos resolver as inconsistências.
Agradeço muito o contato !!!
- 1
-
Em 29/05/2018 at 08:47, Italo Jurisato Junior disse:
Bom dia Windel,
Você esta tentando envia a nota para qual cidade?
Pelotas.
-
Boa tarde Italo,
Atualizamos os fontes novamente, e dessa vez funcionou \0/.
Porem ao tentar enviar uma nota em homologação, ocorreu o seguinte: "Erro não previsto pelo sistema(EIntfCastError - Nao foi possível executar o método ProcessaRequestNfse. Caso a mensagem persista, entre em contato com o administrador do seu sistema.). Entre em contato com a prefeitura para maiores esclarecimentos.". E gostaríamos de saber se já passaram por este erro.
De qualquer forma, muito obrigado! -
Boa tarde Italo,
Fiz a atualização do ACBR, porem ao tentar enviar uma nota, está ocorrendo um erro de código do município não encontrado.
Depurando o código, cheguei na unit: Fontes\ACBrDFe\ACBrNFSe\PCNNFSe\pnfsConversao.pas(Onde consta o nome dos provedores, e ali não encontrei o provedor Asten).
Você pode me confirmar, que foi enviado para o trunk2 essa atualização? Por que já atualizei duas vezes e não veio.
-
1 hora atrás, Italo Jurisato Junior disse:
Boa tarde Windel,
O arquivo de consulta gerado pelo componente como estão essas datas, elas são iguais?
Os nomes das tags referente as datas estão corretas?
Se a resposta for sim para as duas perguntas acima, então o problema é no provedor.
Então é com o provedor mesmo, obrigada!
-
Para nota de serviço para São Vicente do Sul (4319802) estamos tendo problema no envio da nota fiscal e constatamos o seguinte:
Ao utilizar a function ACBrNFSe.ConsultarNFSe, passando para os parâmetros de data inicial e data final a mesma data (datas iguais, 04/04/2018, por exemplo), retorna a seguinte mensagem:
"Data final anterior a data inicial. Informe uma data final igual ou superior a data inicial da pesquisa."
Mesmo que a mensagem diga que a data pode ser igual, mesmo informando a data igual, o erro persiste.
Isso pode ser algum problema dentro do ACBr? Ou é um problema do web service de São Vicente do Sul?
Desde já agradeço!
-
15 horas atrás, luisclaudio_jr disse:
Veja se vc ativou a 3.0 para a carta de correção também, esse erro estava dando aqui pra mim quando a carta estava na 2.0
Sim, faltou setar a versão na Carta de Correção. Grato!!
15 horas atrás, wagner_fix disse:@WINDEL boa tarde...
Não esqueça de setar o seu componente para a versão 3.0
ACBrCTe1.Configuracoes.Geral.VersaoDF := ve300;
ACBrCTe1.EventoCTe.VersaoDF := ve300;
ACBrCTe1.EventoCTe.Versao := '3.00';
Abraço,
Wagner
Obrigado, coloquei esses comandos na Carta de Correção e funcionou.
Grato à atenção de todos
-
Senhores,
Estou com o erro ao enviar uma carta de correção de um CTe aprovado.
CitarRejeição: Cabeçalho - Versão do arquivo XML não suportada (imagem anexo)
Verifiquei que a CTe está na versão "3.00". Estou anexando o XML, ele foi feito em ambiente de homologação.
-
1 hora atrás, WINDEL disse:
Rotina: GetPathPDF
Regra: removido a validação que fazia com que o caminho do PDF não atualizasse.
// if EstaVazio(Result) then // Se não informou o Diretório para o PDF // begin
CORREÇÃO: Essa Unit nossa estava desatualizada, pelo que verifiquei está correto no Fonte ACBr atualizado. A segunda parte tivemos que manter nosso ajuste após pegar o fonte mais atualizado
-
Olá senhores,
Gostaria de relatar uma situação que identificamos ser um "erro" no ACBr e se assim for constatado vou colocar a solução abaixo para ajuste.
Quando o usuário entra em uma CTe (visualização) e usa a opção Exportar para PDF, o sistema traz o nome do PDF conforme o nome do xml. OK
Ao visualizar outro CTe e exportar para PDF, o sistema trouxe o nome do XML do CTe anterior, ou seja, o último nome utilizado.
Fizemos alterações no ACBr e agora está trazendo o nome do CTe correto.
Unit: FontesACBR\Fontes\ACBrDFe\ACBrCTe\DACTE\ACBrCTeDACTEClass.pas
Rotina: GetPathPDF
Regra: removido a validação que fazia com que o caminho do PDF não atualizasse.
// if EstaVazio(Result) then // Se não informou o Diretório para o PDF // begin
Unit: FontesACBR\Fontes\ACBrDFe\ACBrCTe\DACTE\Fast\ACBrCTeDACTEFR.pas
Rotina: ImprimirDACTE
Regra: Foi setado a propriedade frxPDFExport.FileName logo abaixo de frxReport.PreviewOptions.AllowEdit := False:
frxPDFExport.FileName := IncludeTrailingPathDelimiter(PathPDF) + OnlyNumber(CTE.infCTe.Id) + '-cte.pdf';
Se alguém passou por essa situação e puder compartilhar se achou uma solução diferente. Caso seja realmente um problema, para nós seria ótimo se fosse ajustado no ACBr pois quando atualizarmos os fontes, as alterações que fizermos serão perdidas.
Apensa destaco que sou novato na utilização do ACBr e caso eu tenha postado no local errado ou da forma errada, antecipo minhas desculpas.
-
Bom dia,
estamos tendo um problema com a impressora Multifuncional Samsung ProXpress SL-M4070FR Laser.
A mesma possui duas bandejas na qual o cliente usa a de cima com folha serrilhada para impressão de NFe e a debaixo com folha normal.
Nas impressoras disponíveis aparecem as duas (Samsung Notas e 1 Bandeja Normal "Imagem 2"), porém na hora da impressão com o fortes report mesmo escolhendo a opção(Samsung Notas) a impressão sai na bandeja 1(que é a debaixo).
Feito teste imprimindo um PDF pelo Windows e está ok.Alguém poderia auxiliar?
-
2 horas atrás, Daniel Simoes disse:
Com a ajuda do @BigWings, hoje cedo enviamos algumas modificações para o SVN, que devem resolver o problema...
1 hora atrás, BigWings disse:Essa é a mensagem com o protocolo. Se você tiver marcado a opção "Visualizar mensagem" na guia WebService deve ter mostrado antes uma mensagem mais detalhada.
Em outras palavras: parece correto.
Testei novamente e está funcionando! Muito obrigada @BigWings e @Daniel Simoes !
-
41 minutos atrás, BigWings disse:
Foi aplicada uma correção no repositório.
Atualize os fontes e teste novamente.
Segue print do novo teste:
-
19 horas atrás, Daniel Simoes disse:
Por favor forneça um passo a passo completo, de como reproduzir o problema no Demo do ACBr
Utilizando a demo, opção: Consultar carregando XML
-
30 minutos atrás, Daniel Simoes disse:1 hora atrás, BigWings disse:
Fazendo mais testes, consegui simular o erro.
Se configurar o componente para a versão 4.00, e fazer a consulta de uma NFe da versão 3.10 carregando o XML vai ocorrer o problema.
Se configurar o componente para a versão 3.10 o problema não ocorre, pode confirmar?
Substituindo o arquivo, o erro mudou:
Mas pelo que entendi era isso mesmo que o BigWings citou, certo? Dai o que você fez foi um ajuste? Serão necessários mais ajustes para ficar 100%?
Codigo de HASH no QR-Code difere do calculado
em ACBrMonitor PLUS
Postado
Boa tarde, estou tentando gerar uma NFC-e para o estado do PR e está gerando o seguinte erro:
Li no fórum que já houveram outras pessoas com o mesmo problema em 2015, tentei aplicar as soluções que estavam lá, mas sem sucesso.
Em anexo mando o xml que estou gerando.
Alguém tem alguma ideia do que pode estar gerando?
41190602779363000100651020000135121948914682-nfce.xml