-
Total de ítens
100 -
Registro em
-
Última visita
Tipo de Conteúdo
Blocks
Notes ACBrLibNFe
Fóruns
Downloads
Calendário
Posts postados por Leonardo Quinino
-
-
57 minutos atrás, BigWings disse:
Já está tudo atualizado no SVN.
TpcnFormaPagamento = (fpDinheiro, fpCheque, fpCartaoCredito, fpCartaoDebito, fpCreditoLoja, fpValeAlimentacao, fpValeRefeicao, fpValePresente, fpValeCombustivel, fpDuplicataMercantil, fpBoletoBancario, fpDepositoBancario, fpPagamentoInstantaneo, fpTransfBancario, fpProgramaFidelidade, fpSemPagamento, fpRegimeEspecial, fpOutro);
O 99 foi mantido, afinal ele ainda existe nos schemas, e só passará a ser recusado em produção a partir de 01/09/2021.
Obrigado !
-
Em 25/02/2021 at 10:16, ALA disse:
Vou fazer isso mesmo, ai resolve... No caso do 99 não poder ser enviado mais, qual tipo vcs estão enviando. Tenho uma situação aqui que e a seguinte. Quando realizou uma venda TEF e o cartão não retorna se o mesmo e debito ou credito eu movo 99 para essa tag. No caso de vcs como estão tratando isso...
Estou procurando essa solução, até ontem 14/03, o arquivo do acbr que trata esses tipo enumerados ainda não havia sido alterado, "pcnConversao.pas" Classe TpcnFormaPagamento(), o correto mesmo é NÃO MAIS 99, mas realmente não fica claro, em caso de carteira digital, pix, depósito bancário, se já ponde enviar e se mandar, em produção e homologação, as responstas parecem que serão diferentes.
-
Estou no mesma situação.
-
Estou implementando essa parte no TEF.
Além dessa situação, a questão de vincular o documento porém o mesmo NFC-e apenas é autorizado ao final do processo, resumindo a dúvida que eu entendi deve ser a mesma minha.
Se eu ainda não tenho o documento fiscal autorizado ou gerado efetivamente, qual valor colocar para "vincular" ?
Antes com ECF , quando chega na parte do TEF, o cupom já existe de fato.
-
Boa tarde, após merecidas férias, conseguimos homologar o CREDSIS, conforme sugerido, segue as alterações feitas para apreciação de todos. Foi homologado para o CNAB 240
- 2
-
44 minutos atrás, Juliana Tamizou disse:
Bom dia Leonardo.
Toda sugestão é sempre bem vinda, caso queira também anexar a sugestão de alteração implementada, será muito bom.
Att.
Obrigado pelo feedback, vou trabalhar na melhoria, assim que possível postarei aqui.
- 2
-
18 minutos atrás, Leonardo Quinino disse:
Prezados, percebi alguns detalhes no fonte do ACBrBancoCredisis.pas, que descrevo abaixo:
1-Gostaria além de tudo sugerir uma melhoria, já que o segmento é opcional, seria interessante ter opção para não gerar na remessa, pelo fonte, ele sempre será gerado.
2-Parece que o campo abaixo destacado não está no padrão do banco, no fonte está com opções 2, ou 0 (segue o print)
Pelo Manual do Banco, que está anexo, na posição 66, Página 13 "SEQ: 14.3R"
Segue, anexados o layout que o banco enviou , a remessa que gerei e o pdf de retorno com a rejeição
LAYOUT_CNAB_240_-_REMESSA_RETORNO.pdf 1 MB · 0 downloads 0_01_06_2020_164446.txt 3 kB · 0 downloads 0_01_06_2020_164446.txt-erros.pdf 52 kB · 0 downloads
Esse assunto havia sido tratado no fórum, mas foi encerrado por falta de retorno que quem o abriu.
https://www.projetoacbr.com.br/forum/topic/49584-remessa-banco-097-credisis/?tab=comments#comment-327299 -
Prezados, percebi alguns detalhes no fonte do ACBrBancoCredisis.pas, que descrevo abaixo:
1-Gostaria além de tudo sugerir uma melhoria, já que o segmento é opcional, seria interessante ter opção para não gerar na remessa, pelo fonte, ele sempre será gerado.
2-Parece que o campo abaixo destacado não está no padrão do banco, no fonte está com opções 2, ou 0 (segue o print)
Pelo Manual do Banco, que está anexo, na posição 66, Página 13 "SEQ: 14.3R"
Segue, anexados o layout que o banco enviou , a remessa que gerei e o pdf de retorno com a rejeição
LAYOUT_CNAB_240_-_REMESSA_RETORNO.pdf 0_01_06_2020_164446.txt 0_01_06_2020_164446.txt-erros.pdf
-
Em 07/05/2020 at 17:40, Allan Wolski disse:
Boa tarde, @Juliana Tamizou
Segue arquivos de exemplo após as alterações.
Também estou enviando uma correção no evento de MDF-e.
Obrigado.
Evento CT-e.pdf 26 kB · 16 downloads Evento MDF-e.pdf 25 kB · 11 downloads Evento NF-e.pdf 27 kB · 13 downloads EVENTOS_MDFE.fr3 22 kB · 6 downloads
Ficou bem organizado. Realmente, alguns usuários já haviam me solicitado algo assim para detalhar melhor e destacando campos como foi está nesses modelos.
- 3
-
3 minutos atrás, jaques.rocha disse:
Aqui tenho deixado assim e faz muito tempo que não preciso mexer nessa configuração, a maioria dos meus clientes são de SP, mas tenho em MG, RJ, BA, todos sem precisar alterar.
ACBrNFe1.Configuracoes.Geral.SSLCryptLib := cryWinCrypt;
ACBrNFe1.Configuracoes.Geral.SSLHttpLib := httpWinHttp;
ACBrNFe1.Configuracoes.Geral.SSLLib := libWinCrypt;
ACBrNFe1.Configuracoes.Geral.SSLXmlSignLib := xsLibXml2;
ACBrNFe1.SSL.SSLType := LT_TLSv1_2;Exatamente, não mudo isso , na verdade, parece que voltou ao normal, era o ambiente de homologação que estava com problemas.
Se o ADM quiser fechar o tópico e deixar como caso de uso para caso alguém no futuro tenha o problema.
Por mim dou como solucionado o problema.
-
1 hora atrás, jaques.rocha disse:
Tentou mudar o webservice para outro estado, pra ver se não foi uma coincidência ?
Precisei atualizar o ACBr ontem, fiz envio de algumas notas de teste e esta tudo ok por aqui.Mudei o webservice de ES para SP.. deu certo, porém com um resalva.. que tive que mudar a configuração dos protocolos do certificado, que antes usava padrão wincrypt
SSLIB->libWinCrypt
CRYPTLib -> cryWinCrypt
HTTPLib -> httpWinHttp
XMLSignlib -> xsLibXml2
SSLType -> LT_TLSv1_2 ou LT_Alltive que ajustar (em forma de tentativa e erro) para testar mesmo:
SSLIB->libCapicom
CRYPTLib -> cryCapicom
HTTPLib -> httpWinINet
XMLSignlib -> xsMsXmlCapicom
SSLType -> LT_AllEntão nos webservice testados, 'SP' e 'MG' obteve resultado de status da Sefaz.
Não entendi do porque, se ocorreu alguma mudança para configurar.
Vou continuar testando, se eu obter resultado diferente, reporto aqui, talvez possa ajudar alguém numa situação parecida. -
34 minutos atrás, Leonardo Quinino disse:
Acabei de atualizar os fontes, após remover instalação velha (aquivo de lot do instalador) e instalar novamente.
Começou a aparecer esse erro.
Meu Windows é 10, com Certificado A1
Delphi 10.3
Alguém teve algum relato parecido ?
Deixei anexo o xml que estou tentando enviar.
1-env-lot.xml
32200403248675000142650460000100171000100181-nfe.xml 9 kB · 0 downloads
Testei também com o ACBNFe - Programa Exemplo
Não consigo nem obter o WebServce de Status do Serviço
Veja anexo.
-
Acabei de atualizar os fontes, após remover instalação velha (aquivo de lot do instalador) e instalar novamente.
Começou a aparecer esse erro.
Meu Windows é 10, com Certificado A1
Delphi 10.3
Alguém teve algum relato parecido ?
Deixei anexo o xml que estou tentando enviar.
1-env-lot.xml
-
17 minutos atrás, rogercon disse:
Galera, o que ocorre é o seguinte: o cliente transmite a nota, e como a internet do cliente está beeeeem lenta, a nota chega a ser transmitida, mas o retorno da chave de acesso e protocolo não retornam. Portanto, nesta situação eu recebo o erro(except) e acabo por não receber o xml assinado, como posso fazer para recuperar esse xml ?
obs: se eu tentar transmitir essa mesma nota novamente, eu consigo ver o numero da chave de acesso no retorno.xmotivo, mas ali não consigo fazer nada, apenas vejo a chave.
Alguma dica ?Já me ocorreu isso, com MDF-e, mesmo motivo, "perde" a propriedade... onde recebe o nome do arquivo XML gerado, após a autorização.
Isso me gerou uma dor de cabeça extra, porque o MDF-e no portal, quando baixa, vem sem os dados de autorização....
Mais interessante é que pede o XML , porém os dados de protocolo, e data de protocolo, estão. lá..
Já estou criando um método, como exceção , para quando ocorrer, que quando isso ocorrer , devo consultar a SEFAZ, gerar novamente o XML e salvar no disco.
-
8 minutos atrás, Dennis Carlos disse:
por acaso, alguem tem esses arquivos já atualizados. Estou com medo de atualizar o componente e sobrepor alterações efetuadas
Deu certo, bastou atualizar, e reinstalar os Packs novamente.
Já foi inclusive foi testado em cliente de UF - PA, autorizou corretamente a NF-e.
- 1
-
Em 18/07/2019 at 15:10, BigWings disse:
A libxml2.dll que não entende o regex da forma como vem nos schemas oficiais.
Se você configurar SSLXmlSignLib como xsMsXML, para usar a depreciada msxml5.dll, deve validar com o schema oficial.
Não sei dizer se os schemas oficiais estão fora de algum padrão ou é limitação da libxml2.
Em todo caso estou enviando o Schema alterado para o repositório.
Hoje atualizei o SVN do Acbr, e peguei todos os schemas para MDFe... da pasta dos exemplos, começou a dar essa mensagem, logo após.
Estou avaliando essa situação de configuração do SSLXml...
- 1
-
Agora, Italo Jurisato Junior disse:
Bom dia Leonardo,
Essa propriedade faz com que o XML seja gerado de forma identada que ajuda a sua visualização em um bloco de notas.
A SEFAZ não aceita um XML identado, logo devemos atribuir o valor False.
Show , foi isso mesmo que fiz.
Obrigado pela informação.- 1
-
Em 09/09/2014 at 10:39, Italo Jurisato Junior disse:
Bom dia Adriano,
Neste software você utiliza o componente ACBrMDFe?
Se não utiliza, verifica se na rotina que monta o XML (envelope) não contem os tais caracteres de edição.
Só para acrescentar uma informação.
Fiz um teste aqui, criando um Obj, herdando a classe de TACBrMDFe.
E por descuido deixei a propriedade
MeuObj.Configuracoes.Geral.IdentarXML := True;
Não sei precisar exatamente o que venha a ser, mas sempre faço uma consulta de status, e que essa propriedade está em TRUE, retorna o erro acima citado.
-
1 hora atrás, leotelles disse:
Bom dia. Por hora, estamos usando os fontes disponibilizados pelo @Paulo Henrique de Castro no tópico acima e tem suprido a nossa necessidade.
Já fiz um modelo assim, no estilo boleto de cartão de crédito, porém era usado para convênio médico. fiz alterando os fontes, usando clientdataset, porém depois descobri a regra do ACBr que só pode subir para o projeto se compilar em Lazarus.
-
-
18 horas atrás, percoski disse:
Falta instalar o FastReport para a versão Tokyo.
-
41 minutos atrás, Vicente Carletto Scalfoni disse:
Olá,
Segundo o manual v2.0.22 de 11/12/2017 o campo IND_VEIC é o indicador do tipo de veículo, no componente estava como String e o tipo TACBrTipoVeiculo estava no campo VEIC_ID, que é um campo string.
Segue correção no fonte.
@BigWings Interessante a informação.
-
Sei que o tópico é antigo, porém estou com um problema exatamente igual ,
"falha na validação conhecimento 'KG' is not a valid of the local atomic type"
Entretanto é na NFe4.0 usando protocolo SSL
Pela nota técnica posso mandar KG, UN, etc.
Inclusive quando o produto é de GLP... por exemplo é obrigatório uCom e qTrib KG.... porém dá rejeição.
-
Mudar linguagem Delphi
em Boteco do ACBr
Postado
Tem muita opção e gente sobrando em Delphi, acredite, tem que ofertar home office e salário compátivel.
Se for mudar de linguagem você tem por exemplo c# , que tem compatibilidade com ACBr, então ai você vai subir a régua de salário, pois o dev, c# tem uma expectativa de salário quase uns 40% a mais que o dev Delphi, se for para Node Js por exemplo ai sobe mais ainda a régua.... então acho que a sugestão do colega que postou antes seja muito interessante você observar.