ThiagoDornelas
-
Total de ítens
177 -
Registro em
-
Última visita
Tipo de Conteúdo
Blocks
Notes ACBrLibNFe
Fóruns
Downloads
Calendário
Posts postados por ThiagoDornelas
-
-
3 horas atrás, Italo Giurizzato Junior disse:
Bom dia @ThiagoDornelas,
Já inclui na minha lista de tarefas para analise desse caso juntamente com a equipe ACBr. TK-5736
boa tarde @Italo Giurizzato Junior
agradeço imensamente sua atenção.
só para deixar vc por dentro da situação.
voltei o arquivo para ACBrCTeWebServices.pas q eu tinha alterado e tambem o ACBrCTeServicos.ini para a versão antiga e fiz o teste novamente e deu certo.
como te falei, eu estou achando que agora MG autoriza EPEC.
se for do seu interesse esta é a chave do cte: 31240744547281000172570010000000554000000288
-
16 horas atrás, Italo Giurizzato Junior disse:
Boa tarde @ThiagoDornelas,
Isso é estranho pois vai contra a regra de validação que colei mais acima que diz que o evento EPEC não pode ser enviado para o ambiente normal de autorização.
bom dia @Italo Giurizzato Junior, blz?
cara, deu 24hs do envio do EPEC e continua ocorrendo a mesma rejeição.quando eu consulto a chave no ambiente nacional, aparece o evento (isso foi imediato) mas quando consulto na sefaz MG, nao consta nada. continua dando rejeição 641.
estou achando que para MG, o webservice para EPEC é o que constava no arquivo INI antigo.
-
3 horas atrás, Italo Giurizzato Junior disse:
Bom dia @ThiagoDornelas,
Como é São Paulo que esta recepcionando o evento, favor colocar cOrgao = 35.
bom dia @Italo Giurizzato Junior, tudo bem?
alterando para "35" o evento foi aceito, porem ao enviar em modo normal, esta ocorrendo a rejeição "Rejeição 641: O evento prévio deste CT-e não foi autorizado na SVC ou ainda não foi sincronizado."
pelo que pesquisei (e tb pela própria rejeição), pode ser um delay na sincronização entre os ambientes. vou aguardar ate hj a tarde pra ver ser autoriza.
so para deixar registrado, quando eu consegui autorizar o EPEC com as alterações que eu tinha feito, eu conseguia transmitir em modo normal logo depois do EPEC.
a nota ja aparecia no ambiente nacional e na sefaz mg com a autorização e o evento EPEC.
retorno pra vc mais tarde.
obrigado
-
1 hora atrás, Italo Giurizzato Junior disse:
Informe 91 para cOrgao.
mesmo erro.
o xml gerado esta com cOrgao 91 mas o que retorno com a rejeição esta como 31.
tem algum outro local onde devo passar o cOrgao91?23-eve.xml23-ped-eve.xml
-
fiz um teste agora com os fontes atualizados e ocorreu este erro.
estou passando o codigo 31 para infEvento.cOrgao
agora esta pegando o endereço que está na chave que vc adicionou nesta atualização (RecepcaoEventoAN_4.00=https://homologacao.nfe.fazenda.sp.gov.br/CTeWS/WS/CTeRecepcaoEventoV4.asmx)
obrigado
-
13 minutos atrás, Italo Giurizzato Junior disse:
Boa tarde @ThiagoDornelas,
Eu acredito que a sua alteração não esta 100%, digo isso pela regra abaixo referente ao envio do evento EPEC.
A regra O02 verifica se o ambiente que esta recepcionando o evento EPEC é o ambiente autorizador normal, caso afirmativo o evento vai ser rejeitado, pois esse tipo de evento só pode ser enviado para o ambiente autorizador SVC.
A sua alteração estaria enviado o evento para o ambiente de autorização normal.
Fiz uma revisão completa no arquivo ACBrCTeServicos.ini e enviei para o SVN.
Favor fazer uma cópia da sua alteração, atualizar todos os fontes de todas as pastas, reinstale o ACBr e faça novos testes.
boa tarde @Italo Giurizzato Junior,
inicialmente, eu estava tentando enviar o EPEC para o SVC. tentei destas 3 formas e nas 3 tive os mesmos erros.
ACBrCTe1.Configuracoes.Geral.FormaEmissao := teSVCAN ou teSVCSP ou teSVCRS
só consegui a autorização quando passei a usar "ACBrCTe1.Configuracoes.Geral.FormaEmissao := teDPEC" e fazendo a alteração que mencionei anteriormente.
antes desta alteração que fiz, o componente sempre "montava" estava chave "RecepcaoEventoAN_4.00" para localizar no arquivo .ini .
como nao achava esta chave, ele procurava por esta chave "RecepcaoEventoAN_3.00" fazendo com que pegasse o endereço errado.
existe um teste no componente que se nao encontrar a chave referente a versão atual(4.0) ele pega da versão anterior. por isso alterava de RecepcaoEventoAN_4.00 para RecepcaoEventoAN_3.00.
vou fazer uma copia dos meus fontes e atualizarei com as suas alterações para ver se vai funcionar.
obrigado pelo retorno.
-
boa tarde, eu cheguei a ver isso no manual mas nao tinha entendido essa questão do "impressão em papel comum". rs
mas consegui resolver.
é so imprimir o DACTE passando o protocolo do evento EPEC.
obrigado pela atenção.
-
36 minutos atrás, Juliomar Marchetti disse:
sugestões anexa a unit alterada para isso
segue a unit com a alteração.
obrigadoACBrCTeWebServices.pas
-
1
-
-
17 horas atrás, elainemeurer disse:
Boa tarde,
Tiveram algum retorno da sefaz ou ajuste que funcionou?
Estou com mesmo problema.bom dia,
acabei de postar isso. no meu caso, resolveu o problema.
-
bom dia pessoal,
semana passada, postei no tópico abaixo, um problema que eu estava tendo e que outra pessoa tb teve o mesmo problema.
debugando os fontes, identifiquei onde poderia estar o problema e fiz uma alteração que resolveu meu problema.
gostaria de compartilhar para que analisem e vejam se poderiam alterar no código oficial.
na unit ACBrCTeWebServices.pas na procedure TCTeEnvEvento.DefinirURL tem o seguinte teste:
if ((FEvento.Evento.Items[0].InfEvento.tpEvento in [teCCe, teCancelamento,
teMultiModal, tePrestDesacordo, teGTV, teComprEntrega, teCancComprEntrega,
teCancPrestDesacordo, teInsucessoEntregaCTe, teCancInsucessoEntregaCTe]))
FPLayout := LayCTeEvento
else
FPLayout := LayCTeEventoAN;como o evento é o "teEPEC", estava caindo na linha "FPLayout := LayCTeEventoAN"
em um determinado ponto do fonte, o componente vai buscar o endereço de webservice no arquivo "ACBrCTeServicos.ini" e para Minas Gerais, estava pegando o endereço errado.
estava pegando um endereço de ambiente nacional (LayCTeEventoAN) para versão 3.0. Ele procurava no arquivo pela chave "RecepcaoEventoAN_4.00" e como nao encontrava, pegava a chave "RecepcaoEventoAN_3.00" (esta chave consta o endereço errado).
entao, fiz a seguinte alteração na unit ACBrCTeWebServices.pas, e o problema foi resolvido.
if ((FEvento.Evento.Items[0].InfEvento.tpEvento in [teCCe, teCancelamento,
teMultiModal, tePrestDesacordo, teGTV, teComprEntrega, teCancComprEntrega,
teCancPrestDesacordo, teInsucessoEntregaCTe, teCancInsucessoEntregaCTe])) or
((UF = 'MG') and (FEvento.Evento.Items[0].InfEvento.tpEvento = teEPEC)) then
FPLayout := LayCTeEvento
else
FPLayout := LayCTeEventoAN;eu poderia apenas acrescentar o "teEPEC" no teste do "if" que resolveria o meu problema mas como nao sei se isso ocorre nos outros estados, achei melhor fazer desta forma.
não sei se esta é a melhor solução mas no meu caso foi resolvido. analisem e vejam se vale a pena alterar nos fontes;
obrigado.
-
bom dia pessoal,
gostaria de saber se existe a impressão da contingência EPEC.
estou fazendo uns teste aqui e tanto no meu sistema quanto no programa exemplo, a impressão do EPEC esta saindo em branco (conforme imagem).
estou testando em homologação, ja que nao tenho XML em produção em EPEC.
estou usando os seguintes comandos (para o evento CCe está funcionado corretamente).
ACBrCTe1.Conhecimentos.Clear;
ACBrCTe1.EventoCTe.Evento.Clear;ACBrCTe1.Conhecimentos.LoadFromFile(qryCTePendente.FieldByName('des_pathxml').AsString)
ACBrCTe1.EventoCTe.LerXML(qryCteEvento.FieldByName('des_pathxml').AsString);
ACBrCTe1.ImprimirEvento;
-
Em 01/04/2024 at 19:35, Paulinho disse:
Ola Diego, tudo bom, deu certo? Pois acredito estar com o mesmo problema
boa tarde, tudo bem?
comecei a implementar hj o EPEC do CTe mas ao enviar, esta ocorrendo este mesmo erro. Estou testando na homologação de MG.- atualizei os fontes hj;
- reinstalei tudo (com a opção de apagar arquivos antigos marcada)
- verifiquei se o arquivo ACBrCTeServicos.ini estava na pasta do meu executável
mesmo assim continuo tendo este problema. alguem poderia me ajudar com isso?
-
boa tarde Pessoal,
apareceu um caso aqui de um cliente onde foi solicitado a possibilidade de envio da NFe por email com cópia oculta.
Hoje, para envio das notas, usamos o seguinte comando: TACBrNFe1.NotasFiscais.Items[0].EnviarEmail(...).
Fuçando no fontes, vi que ja foi implementado a opção de envio BCC mas no procedimento EnviarEmail, não possui esta opção como parâmetro.
Alterei meu fonte incluindo um novo parâmetro e nos meus testes, funcionou redondo.
Estou anexando o arquivo alterado para que avaliem a possibilidade de subir esta alteração, se assim, acharem necessário.
A única alteração que fiz foi esta (em negrito), o resto já estava pronto:
procedure EnviarEmail(const sPara, sAssunto: String; sMensagem: TStrings = nil;
EnviaPDF: Boolean = True; sCC: TStrings = nil; Anexos: TStrings = nil;
sReplyTo: TStrings = nil; sBcc: TStrings = nil); -
Em 13/05/2024 at 15:48, Juliomar Marchetti disse:
Acho que tu vai ter que alterar o componente
e dai vai passar a perder as atualizações do ACBr mas tu pode
foi o que pensamos em fazer.
o responsável por esta solicitação no meu cliente adoeceu e por isso pediram um tempo para verificar se realmente não tem o DV no nossonumero.
então isto está parado aqui na empresa.
de qualquer forma, agradeço pelo retorno.
o post pode ser fechado.
-
bom dia,
Gostaria de saber se existe alguma forma de gerar o boleto sem que o AcbrBoleto calcule o DV do nossonumero?
a situação é a seguinte.
Tenho um cliente que trabalha com varios bancos. as vezes eles fazem o "desconto" dessas cobranças com o banco pagando uma taxa por isso.
Agora estao fazendo isso com uma Factoring (melhor taxa). Essa empresa usa o mesmo layout do Bradesco com algumas diferenças. Uma delas é no nossonumero. no caso deles nao existe o DV. o nosso numero deve seguir um sequencial definido por eles, sendo o primeiro dígito igual a 5.
então por exemplo. Definiram que o sequencial inicial do meu cliente será 15000. então o nosso numero será 500000015000.
os próximos seguem a sequencia: 500000015001, 500000015002, 500000015003 ....
entao quando mando gerar o boleto, o componente esta calculando o DV mesmo eu informado no campo "Banco.TamanhoMaximoNossoNum" o tamanho 12, fazendo com que o nossonumero fique com 13 digitos e diferente do que foi gerado pelo sistema e diferente tb do que foi enviado no arquivo de remessa.
por isso, gostaria de saber se tem como fazer com q o DV nao seja gerado pelo componente.
obrigado
-
17 horas atrás, Juliomar Marchetti disse:
só alterou esses dados no novo manual?
está no svn mas creio que não seja só isso de mudança no ECF
bom dia,
ajustei so isso inicialmente já que o arquivo nao estava sendo importado.
provavelmente terá outros ajustes.
-
bom dia,
precisei ajustar os fontes abaixo para o novo layout. Além do novo código de layout, foi necessário criar um novo campo para o registro "0020".
segue abaixo as alterações feitas:
- unit ACBrECFBlocos: acrescentei o novo codigo "0010"
- unit ACBrECFBloco_0: criei um novo campo (IND_PR_TRANSF) para o registro 0020.
- unit ACBrECFBloco_0_Class: ajuste na procedure de escrita do registro 0020.
-
Em 08/09/2023 at 19:30, Renato Rubinho disse:
Boa noite,
Em primeiro lugar a forma de como e o que preencher sempre deve ser verificada com seu contabilista ou do cliente, pois eventualmente uma sugestão incorreta pode te induzir ao erro na geração.
Se o manual não instruir a agrupar é muito provável que não deva ser agrupado e, cada nota, deva ser preenchida individualmente.
ja descobri o problema.
os dados de fato nao devem ser agrupados.
eu estava montando o registro informando a tag "natRend" para cada nota e na verdade ela deve ser informado apenas 1 vez, e "dentro" dela, todas as suas respectivas notas.
obrigado @Renato Rubinho pela atenção.
-
2
-
-
Em 08/09/2023 at 19:30, Renato Rubinho disse:
Boa noite,
Em primeiro lugar a forma de como e o que preencher sempre deve ser verificada com seu contabilista ou do cliente, pois eventualmente uma sugestão incorreta pode te induzir ao erro na geração.
Se o manual não instruir a agrupar é muito provável que não deva ser agrupado e, cada nota, deva ser preenchida individualmente.
bom dia,
entendi. vou dar uma olhada. perguntei isso pq nos testes iniciais geramos sem agrupar e deu este erro:
"Já existe outra tag 'idePgto: natRend' com mesma chave no evento. Não pode ser informada mais de uma tag com a mesma chave."
Por isso imaginei que pudesse ser por ter enviado mais de uma nota do fornecedor.
-
1
-
-
boa tarde,
Estou validando o evento R4020 e surgiu uma situação que nao sei qual o procedimento correto.
Tenho um beneficiário que possui várias notas no mesmo período. Todas as notas possuem as mesmas deduções (PCC e IR)
ao montar o registro, devo agrupar as mesmas deduções e enviar o total de cada uma delas ou devo mandar separado? se for pra mandar agrupado, qual deve ser a data do fato gerador (tag dtFG) se as notas são em datas diferentes?
exemplo:NOTA A: vlr. Total $100,00 - PCC $12,00 - IR $5,00
NOTA B: vlr. Total $200,00 - PCC $24,00 - IR $10,00
Neste caso deveria mandar pro evento PCC 36,00 e IR 15,00 ou deveria ser separado?
obrigado
-
Em 09/05/2019 at 16:37, Daniel Caus disse:
Boa tarde!
Pelo portal e-CAC é possível verificar os dados.
Obrigado Daniel.
apenas e-CAC acho q pode ser complicado. Acho difícil algum cliente passar os dados de acesso do portal.
-
boa tarde,
por acaso a Receita disponibilizou algum site para que possamos verificas os dados enviados?
existe alguma forma de consultar o que já foi enviado?
obrigado
Thiago Dornelas
-
boa tarde,
siga os procedimentos do link abaixo e seus problemas serão resolvidos. fiz isso com todos os meus clientes e tive 100% dos problemas resolvidos.
funciona em todas as versões do windows (7, 8 e 10) e para certificados A1 e A3.
-
2
-
1
-
-
bom dia,
acabei de atualizar os fontes q comecei a ter este erro ao compilar meu sistema. " ...pnfsEnvLoteRpsResposta.pas(1113) Error: Undeclared identifier: 'ReplaceStr'"
ja desinstalei os fontes e o mesmo erro acontece ao usar o ACBrInstall.
obrigado.
-
1
-
Erro ao enviar EPEC para MG - possível solução
em ACBrCTe
Postado
boa tarde @Italo Giurizzato Junior, blz?
desculpe pela demora em retornar.
agora funcionou 100%.
obrigado pela ajuda.