AlexSilva
-
Total de ítens
66 -
Registro em
-
Última visita
Tipo de Conteúdo
Blocks
Notes ACBrLibNFe
Fóruns
Downloads
Calendário
Posts postados por AlexSilva
-
-
Caros,
Baixamos a última versao do MonitorPlus: ACBrMonitorPLUS-1.3.0.129-x64-Instalador.
Ao fazer alguns testes antes de atualizar em nossos clientes, pegamos um problema ao encerrar uma MDFe, onde simplesmente volta uma message box 'Access Violation' sem oferecer nenhum detalhe a mais.
Tentamos passar o comando tanto com argumentos opcionais, como sem e em ambos o erro persiste.
MDFE.EncerrarMDFe("31191004002794000183580010000004301846836564", 11/10/2019, "3201209")
ERRO: Access violationou
MDFE.EncerrarMDFe("31191004002794000183580010000004301846836564", 11/10/2019, "3201209", "", "")
ERRO: Access violationAgradeço de antemão pela ajuda!
Alex
-
Realmente Ítalo, foi na mosca!
Muito agradecido pela ajuda!
Alex
- 2
-
Boa tarde Colegas,
feito como instruído pelo José Junior... praticamente copiei e colei os comandos do manual, e apliquei e ainda assim persiste o mesmo erro.
Segue log para avaliação:
[Status]
CStat=107
CUF=31
DhRecbto=29/07/2019 14:18:11
DhRetorno=30/12/1899
Msg=Servico em Operacao
TMed=1
TpAmb=2
VerAplic=RS20190308130819
Versao=3.00
XMotivo=Servico em Operacao
XObs=29/07/2019 14:18:16 - MDFE.CriarMDFe("
[ide]
cUF = 31
mod = 58
serie = 001
procEmi = 0
dhEmi = 26/07/2019 13:54:09
tpEmis = 1
tpEmit = 2
modal = 1
ufini = MG
uffim = MG
cMDF = 84473200
nMDF = 000000138
tpTransp = 2[CARR001]
cMunCarrega = 3115300
xMunCarrega = Cataguases
dhIniViagem = 29/07/2019
indCanalVerde = 0
indCarregaPosterior = 0[Emit]
CNPJ = 04002794000183
IE = 1530937930030
xNome = RECICLEBEM LTDA
xFant = RECICLEBEM
Fone = 3234223681
CEP = 36771000
xLgr = AVE MANOEL INACIO PEIXOTO
nro = 1285
xCpl =
xBairro = INDUSTRIAL
xMun = Cataguases
cMun = 3115300
UF = MG
cUF = 31[Rodo]
RNTRC = 00000000[infANTT]
RNTRC = 00000000[veicTracao]
placa = QOQ6524
capKG = 0
capM3 = 0
tara = 1815
tpRod = 02
tpCar = 01
UF = MG
xnome = 0
tpProp = 0
ie = 0
RENAVAM = 1158060448[MOTO001]
xNome = HUDSON TEIXEIRA GOMES
CPF = 01203375689[DESC001]
cMunDescarga = 3115300
xMunDescarga = Cataguases[infNFe001001]
chNFe = 31190704002794000183550010000090751722528623[tot]
vCarga = 10.00
cUnid = 01
qCarga = 100
qNFe = 1
qCTe = 0
[infAdic]
infAdFisco = teste
infCpl = teste")
29/07/2019 14:18:16 - OK: C:\Arquivos de programas\VSEmissFiscal_Sys\VSNFe\entr_sai\31190704002794000183580010000001381844732006-mdfe.xml
29/07/2019 14:18:20 - MDFE.ImprimirDAMDFE( "C:\Arquivos de programas\VSEmissFiscal_Sys\VSNFe\entr_sai\NFe\31190704002794000183580010000001381844732006-mdfe.xml" , , , ,1)
29/07/2019 14:18:20 - OK: DAMDFe Impresso com sucesso
29/07/2019 14:18:51 - MDFE.EnviarMDFE( "C:\Arquivos de programas\VSEmissFiscal_Sys\VSNFe\entr_sai\MDFe\31190704002794000183580010000001381844732006-mdfe.xml",138, 1 )
29/07/2019 14:18:51 - ERRO: Falha na validação dos dados do Manifesto: 1381871 - Element '{http://www.portalfiscal.inf.br/mdfe}indCarregaPosterior': This element is not expected.
No aguardo de alguma ajuda no uso desses campos novos.
Alex
-
Boa tarde José!
Obrigado, vou proceder como instruído e qualquer dúvida posterior eu volto a fazer contato.
Gostaria de sugerir apenas uma correção pro post do Italo de quarta feira, visto que ele diz que esses campos podem ficar ausentes ou com 0.
Como isso tem sido basicamente norma no MonitorPlus, deixei os campos ausentes.Grato pela atenção!
-
Boa tarde!
Tivemos uma reclamação de um cliente que não estava conseguindo enviar um MDFe.
Ao analizar a situação percebemos que parece que o monitor está gerando a tag do evento de inclusão de DFe mesmo sem a presença do comando indCarregaPosterior.
Segue o log de uma simulação de envio e o erro gerado:26/07/2019 13:56:43 - MDFE.CriarMDFe("
[ide]
cUF = 31
mod = 58
serie = 001
procEmi = 0
dhEmi = 26/07/2019 13:54:09
tpEmis = 1
tpEmit = 2
modal = 1
ufini = MG
uffim = MG
cMDF = 66662342
nMDF = 000000138
tpTransp = 2[CARR001]
cMunCarrega = 3115300
xMunCarrega = Cataguases[Emit]
CNPJ = 04002794000183
IE = 1530937930030
xNome = RECICLEBEM LTDA
xFant = RECICLEBEM
Fone = 3234223681
CEP = 36771000
xLgr = AVE MANOEL INACIO PEIXOTO
nro = 1285
xCpl =
xBairro = INDUSTRIAL
xMun = Cataguases
cMun = 3115300
UF = MG
cUF = 31[Rodo]
RNTRC = 00000000[infANTT]
RNTRC = 00000000[veicTracao]
placa = QOQ6524
capKG = 0
capM3 = 0
tara = 1815
tpRod = 02
tpCar = 01
UF = MG
xnome = 0
tpProp = 0
ie = 0
RENAVAM = 1158060448[MOTO001]
xNome = HUDSON TEIXEIRA GOMES
CPF = 01203375689[DESC001]
cMunDescarga = 3115300
xMunDescarga = Cataguases[infNFe001001]
chNFe = 31190704002794000183550010000090751722528623[tot]
vCarga = 10.00
cUnid = 01
qCarga = 100
qNFe = 1
qCTe = 0
[infAdic]
infAdFisco = teste
infCpl = teste")
26/07/2019 13:56:43 - OK: C:\Arquivos de programas\VSEmissFiscal_Sys\VSNFe\entr_sai\31190704002794000183580010000001381666623427-mdfe.xml
26/07/2019 13:57:17 - MDFE.EnviarMDFE( "C:\Arquivos de programas\VSEmissFiscal_Sys\VSNFe\entr_sai\MDFe\31190704002794000183580010000001381666623427-mdfe.xml",138, 1 )
26/07/2019 13:57:17 - ERRO: Falha na validação dos dados do Manifesto: 1381871 - Element '{http://www.portalfiscal.inf.br/mdfe}indCarregaPosterior': This element is not expected.
Fico no aguardo de alguma ajuda.
Grato.Obs: usando a versao .67 do MonitorPlus
Alex
-
Bom dia !
Ok!
Obrigado.
- 1
-
Boa tarde!
Após atualizado para a versão 1.2.0.65 - passou a gerar o xml com a tag <indAlteraToma>1</indAlteraToma>
Foi feito o Envio mas voltou rejeição: 259->739-Rejeicao: O CT-e substituido deve possuir evento de Prestacao do Servico em Desacordo para alteracao de tomador
- Acreditamos que ficou faltando o Evento de Prestacao do Servico em Desacordo - ja orientamos o cliente para solicitar o evento.Depois de atualizado, passamos a ter problemas agora com geração do xml da NFE:
- Na geração volta msg: 17/06/2019 17:02:01 - ERRO: Código Numérico inválido, Chave não GeradaSegue em anexo o log com todo o conteúdo.
No aguardo.
-
Caro Ítalo, só para esclarecer, a outra postagem eu tinha feito anteriormente...
Acontece que eu estava com o SAC expirado e me confundi.
Então renovei e esqueci de fechar o outro post.
Peço desculpas por qualquer inconveniente, mas as vezes a correria nos deixa meio 'aluados'.Grato novamente
Alex
- 1
-
Muito obrigado Ítalo!
Ficarei no aguardo.
Alex
- 1
-
Caro Ítalo!
teria como você me informar que dia sai a atualização semanal para que eu possa dar uma previsão para nosso cliente?
Pelo que ele disse, que a contabilidade orientou, ele tinha um prazo final ainda essa semana...
Assim ao menos poderei informá-lo sobre um prazo concreto.Grato
Alex
-
Bom dia Ítalo!
desculpe-me a demora para responder, mas estávamos aguardando nosso cliente.
Você acertou na mosca em relação ao problema da geração. Porém ao usar:[infCteSub]
chCte= 31190604002794000183570010000002591000005218
refNFe= 17190525086034000171550020000175491184232405
indAlteraToma = 1
notamos que a tag indAlteraToma não foi gerada.Ao tentar o envio para a SEFAZ recebemos a seguinte rejeição:
XMotivo=Rejeicao: O CNPJ do tomador do CT-e substituto deve ser igual ao informado no CT-esubstituido
Como devemos proceder?
Grato,
Alex
-
Caros
tenho um cliente de MG, que gerou um Cte com tomador errado.
Este ao perceber o erro, gerou uma NFe anulando o serviço e orientou ao meu cliente para gerar um CTe substituto.
Como o manual do AcbrMonitor parece estar com os exemplos desatualizados ou com omissão de algumas tags/valores, pesquisei bastante aquí no forum a forma correta de fazer isso, mas apenas achei tópicos referentes ao controle AcbrCte.
Na maioria das vezes os nomes dos comandos são consistentes, e assim tentei arriscar usando os mesmos comandos usados no controle, mas seja por divergência na palavra-chave ou erro da minha parte o xml gerado não gera refNFe; ele aplica refCTe em branco no lugar, o que gera o erro de validação: erro: 1824 - Element '{http://www.portalfiscal.inf.br/cte}refCte': '' is not a valid value of the atomic type '{http://www.portalfiscal.inf.br/cte}TChNFe'.a parte do txt referente à substituição eu estou fazendo da seguinte forma:
[infCteSub]
chCte= 31190604002794000183570010000002591000005218
[tomaICMS]
refNFe= 17190525086034000171550020000175491184232405
indAlteraToma= 1O xml gerado segue em anexo.
Aguardo ajuda pois meu cliente tem urgência.
Agradeço desde já a boa vontade e atenção!
Alex
-
Caros colegas,
tenho um cliente de MG, que gerou um Cte com tomador errado.
Este ao perceber o erro, gerou uma NFe anulando o serviço e orientou ao meu cliente para gerar um CTe substituto.
Como o manual do AcbrMonitor parece estar com os exemplos desatualizados e com omissão dos possiveis comandos para esse caso, pesquisamos bastante aquí no forum a forma correta de fazer isso, mas apenas achei tópicos referentes ao controle AcbrCte.
Na maioria das vezes os nomes dos comandos são consistentes, e assim tentei arriscar usando os mesmos comandos usados no controle, mas seja por divergência na palavra-chave ou erro da minha parte o xml gerado não apresenta as tags de sustituição e, provavelmente por esse motivo, retorna o erro: 1824 - Element '{http://www.portalfiscal.inf.br/cte}refCte': '' is not a valid value of the atomic type '{http://www.portalfiscal.inf.br/cte}TChNFe'.a parte do txt referente à substituição eu estou fazendo da seguinte forma:
[infCteSub]
chCte= 31190604002794000183570010000002591000005218
[tomaICMS]
refNFe= 17190525086034000171550020000175491184232405
indAlteraToma= 1e o xml resultante está em anexo.
Agradeço qualquer ajuda desde já.
Alex
-
Boa tarde José Junior!
Procedemos como você nos indicou e a situação do MDFe foi resolvida.
Usando a mesma comparação que você fez, encontramos uma pequena divergencia na geração do NFe. Estamos realizando testes finais mas parece que foi resolvido também.Agradecemos muito sua assistência e paciência conosco.
Apenas por curiosidade, nos enganou bastante o tipo de mensagem de erro devido ao problema no campo RNTRC (Rejeição assinatura difere do calculado). E ainda pior que, em algumas circunstâncias era aprovado (CriarEnviar - mesmo sem ter corrigido o campo é aprovado) e versões anteriores.
Ficaremos mais atentos na busca de problemas no futuro.Muito obrigado!!
- 3
-
Feita a correcao do campo indicado, e novo teste.
Segue a mesma rejeicao - log anexado abaixo
-
Prezado José Junior, vou fazer como indicado. Irei realizar a correção deste campo e procederei com os testes.
Todavia gostaria de apontar que estamos testando com o MDFe para simplificar, porém a mesma rejeição acontece com a NFe. Imagino que uma vez descoberto o problema o que passou a gerar rejeição no MDFe, a correção será similar para NFe.Lembrando:
com NFe:
Se rodo nosso sistema com o monitor versão 1.1.0.55 - aprova
Se rodo nosso sistema com o monitor versão 1.2.0.11 - aprova
Se rodo nosso sistema com o monitor versão 1.2.0.16 - não aprovaGrato mais uma vez.
-
Em complemento ao post anterior, gostaria de apontar o seguinte:
a) Como aprova com versões anteriores, certamente teve aguma alteracao no monitor
b) como você mesmo comprovou, não existe manipulação do arquivo da nossa parte (eles são identicos)
c) Embora o método 'CriarEnviar' tenha funcionado e pode ser usado, nunca antes usamos o metodo MDFe.CriarEnviarMDFe (mesma coisa com NFe) pois os clientes mostraram preferir mais controle nos estágios.
Portanto gostaríamos de resolver o problema usando os métodos separados para evitar impacto na forma como os clientes interagem com nosso sistema, até porque muitas funcionalidades ficariam perdidas caso fossemos obrigados a abandonar esses métodos.
d) Agradecemos sua indicação referente ao campo RNTRC , e vamos acertar de acordo, mas certamente não é isso que está implicando problema, visto que aprova tanto na versão anterior, quanto usando o 'CriarEnviar'.Agradecemos e contamos com sua ajuda para resolver esse problema.
-
Boa tarde José Junior!
Segue os arquivos solicitados:
1 - LOG-Aprovado.TXT - com o método = MDFe.CriarEnviarMDFe(.ini) - Com este método foi Aprovado.
2 - LOG-Não_Aprovado.TXT - Feito como sempre foi feito pelo nosso sistema. Usando separadamente: Gerar, validar e Assinar e depois Enviar.
10/09/2018 12:34:33 - OK: C:\Program Files\VSEmissFiscal_Sys\vsnfe\entr_sai\31180965235434000116580010000000801000000805-mdfe.xml
10/09/2018 12:34:40 - MDFE.ImprimirDAMDFE( "C:\Program Files\VSEmissFiscal_Sys\vsnfe\entr_sai\NFe\31180965235434000116580010000000801000000805-mdfe.xml" , , , ,1)
10/09/2018 12:34:43 - OK: DAMDFe Impresso com sucesso
10/09/2018 12:34:49 - MDFE.EnviarMDFE( "C:\Program Files\VSEmissFiscal_Sys\vsnfe\entr_sai\MDFe\31180965235434000116580010000000801000000805-mdfe.xml",80, 1 ) -
adendo ao post anterior:
só por via das dúvidas acabei de testar sem passar argumento nenhum de assinatura, e não alterou nada. Persiste a mesma rejeicao.
Segue o log em anexo.
-
Boa noite José Junior!
Acabei de fazer o teste forçando 0 no argumento da assinatura. Nada feito: continua o mesmo erro.
Acabei não testando omitir o argumento, mas pela lógica (e pelas instrucoes dos Helps) passar 0 ali no argumento seria ate mais indicado.De qualquer forma, ainda testarei por via das dúvidas.
Segue anexo o log completo.
Muito obrigado pela atenção e paciência. Contamos com sua ajuda porque a semana toda dando erro, estamos apertados com os clientes no nosso pé (e com razão).
Bom feriado e fim de semana!
-
-
Bom dia José Junior!
Segue os arquivos solicitados:
Versão usada 1.2.0.16
1 - LOG.TXT
2 - 31180965235434000116580010000000791000000790-mdfe(Pasta_log).xml
Apenas para maiores esclarecimentos:
- Quando dizemos enviar pelo sistema - MDFE.ENVIARMDFE("caminho_do_xml",1) estamos querendo dizer que usamos o sistema pra mandar o comando pro monitor- NÃO APROVA.- E quando dizemos enviar direto pelo monitor, é usando o monitor em testes (enviar XML MDFe) e apontando o arquivo xml - APROVA.
- Como dito em posts anteriores: com a versão 1.1.0.55 foi aprovado fazendo o envio pelo nosso sistema - SEM PROBLEMAS
31180965235434000116580010000000791000000790-mdfe(Pasta_log).xml
-
Bom dia José Junior!
Fizemos muitos testes aqui, segundo sua instrução.
Os arquivos da pasta LOG e da MDFe (copia) validam sem nenhum problema.Quando enviamos e acontece a rejeição, não retorna nenhum arquivo que podemos usar para validar.
Conferi o codigo novamente, e não existe nenhuma manipulação, apenas é enviado o comando: MDFE.ENVIARMDFE("caminho_do_xml",1)
Ou seja, deixamos por conta do AcbrMonitor.
Com o mesmo exato codigo, se rodar fazendo par com a versã0 1.1.0.55 do monitor, aprova sem problemas.
Já se rodar com o monitor versão 1.2.0.11 pra frente, da problema.Outro exemplo, agora com NFe:
Se rodo nosso sistema com o monitor versão 1.1.0.55 - aprova
Se rodo nosso sistema com o monitor versão 1.2.0.11 - aprova
Se rodo nosso sistema com o monitor versão 1.2.0.16 - não aprovano citado acima é sempre o mesmo exe do nosso aplicativo, a unica variável é o monitor. Ou seja, tudo leva a crer que alguma alteração do monitor está resultando na 'incompatibilidade'.
Apenas preciso saber qual foi essa alteração para poder adequar nosso sistema de acordo.Presumo que até a versao 1.2.0.11, tinha sido feito o refactoring da MDFe mas não da NFe.
Na ultima versão, já foram feitos para ambos, e ambos geram problema para aprovar nossos envios.Agradeço qualquer ajuda possivel sua ou de outros colegas do forum.
Muito obrigado!
-
Boa tarde José M. S. Junior !
Afim de fornecer mais informações para um comparativo entre as versoes. Segue os exemplos de XML gerados com a versão 1.1.0.55
1 - 31180965235434000116580010000000771000000770-mdfe(gerado_pasta_Log).xml
2 - 31180965235434000116580010000000771000000770-mdfe(copiado_pasta_Log_para_pasta_MDFe).xml
- com esta versão 1.1.0.55 foi aprovado fazendo o envio pelo nosso sistema.3 - 31180965235434000116580010000000771000000770-mdfe(Aprovado_Enviado_pelo_Sistema).xml
Att,
31180965235434000116580010000000771000000770-mdfe(gerado_pasta_Log).xml
31180965235434000116580010000000771000000770-mdfe(copiado_pasta_Log_para_pasta_MDFe).xml
31180965235434000116580010000000771000000770-mdfe(Aprovado_Enviado_pelo_Sistema).xml
MDFE.EncerrarMDFe retorna ERRO: Access violation
em ACBrMonitorPLUS
Postado
Certinho Daniel!
testamos aqui e tudo 100% com a versão 32.
Ao ver a versão 64 disponível nos downloads achamos que já estava ok para uso em produção.
Muito grato pela ajuda!
Alex