Correção - CT-e OS

[bsoft]

Boa tarde,

Realizamos algumas correções referente ao CT-e OS:

• Tratamento do envio como síncrono;
• Remoção da verificação no status 104 (Lote processado);
• Preenchimento das tags nAver e vCarga do grupo seg somente quando for modelo 57 e versão 2.00;
• Leitura do XML pelo método LoadFromString();
• Ler o subgrupo infQ somente quando houver o grupo infCarga.

Segue em anexo o fonte modificado (arquivos ACBrCTe.pas, ACBrCTeWebServices.pas, pcteCTeW.pas, ACBrCTeConhecimentos.pas e pcteCTeR.pas).

ACBrCTe.pas

ACBrCTeWebServices.pas

pcteCTeW.pas

ACBrCTeConhecimentos.pas

pcteCTeR.pas

[Juliomar Marchetti]

Boa tarde

aguardemos o sr. @Italo Jurisato Junior para analisar o código!

[Italo Giurizzato Junior]

Boa noite a todos,

Já analisei e enviei para o repositório, muito obrigado pela colaboração Bsoft.

[Leonardo Quinino]

15 horas atrás, Italo Jurisato Junior disse:

Boa noite a todos,

Já analisei e enviei para o repositório, muito obrigado pela colaboração Bsoft.

Recebi os ultimos ajustes citados, porém após transmitir, quando modelo CT-e OS  , não devolve o número do recibo, e o arquivo XML que até antes de transmitir, (asisnado e já validado), fica danificado com 1kb.

[bsoft]

Leonardo Quinino, não existe Recibo neste processo porque ele é síncrono, diferente do CT-e normal que é assíncrono, onde primeiro é enviado para a SEFAZ, recebendo o recibo de volta, e depois é consultado o resultado do processamento em cima deste recibo.

Mais detalhes no item 4.2 do manual do CT-e versão 3.0.

[Leonardo Quinino]

53 minutos atrás, bsoft disse:

Leonardo Quinino, não existe Recibo neste processo porque ele é síncrono, diferente do CT-e normal que é assíncrono, onde primeiro é enviado para a SEFAZ, recebendo o recibo de volta, e depois é consultado o resultado do processamento em cima deste recibo.

Mais detalhes no item 4.2 do manual do CT-e versão 3.0.

Obrigado, fiz os tratamento de retorno para quando for 57 ou 67.

Porém o xml quando é gerado por modelo 67, não grava corretamente o XML do CTE-OS.

Debugando o código peguei um tratamento que até então não tinha tido problema, Pois apenas usava o modelo 57

 

usando  a função:

Result := ACBrCTe.WebServices.EnviaOS(NumeroEvento);

pcteProcCTe.pas

Linha 270

    Modelo := StrToIntDef(RetornarModelo(FchCTe), 57);

Essa propriedade está sempre vazia, e retorna 57, mudei o valor para 67 em debuger, e gerou o xml corretamente.

Porém essa validação não deveria ser usado a tag ModeloDF

Modelo = 57   

i f ACBrCTe.Configuracoes.Geral.ModeloDF = moCTeOS

     Modelo=67

?

[Italo Giurizzato Junior]

Boa noite Leonardo,

Favor atualizar os fontes e refaça os testes.

[Leonardo Quinino]

10 horas atrás, Italo Jurisato Junior disse:

Boa noite Leonardo,

Favor atualizar os fontes e refaça os testes.

Show de bola, foi resolvido.

[bsoft]

Boa tarde,

@Italo Jurisato Junior, realizamos a inclusão dos endereços do layout CTeRecepcaoOS_3.00 para os servidores SVC-RS e SVC-SP, tanto homologação quanto produção.

Segue em anexo o fonte modificado (arquivos ACBrCTeServicos.ini)

ACBrCTeServicos.ini

[Italo Giurizzato Junior]

Boa noite,

Muito obrigado pela colaboração, já esta no repositório.

[bsoft]

Boa tarde,

@Italo Jurisato Junior, realizamos uma nova correção na leitura das informações de contingência. Estas informações não estavam sendo lidas devido a inclusão da leitura do grupo "infPercurso" antes delas.

Segue em anexo o fonte modificado (pcteCTeR.pas)

pcteCTeR.pas

[Italo Giurizzato Junior]

Boa noite,

Muito obrigado pela colaboração, ainda hoje estarei enviando para o repositório.

[WINDEL]

Boa tarde,  

 

Este infPercurso ,  tem que ser gerado conforme já é gerado para o MDFe,  ou seja,  informar cada estado no qual ele irá passar para chegar ao destino?

 

Att, 

Diogo

[Italo Giurizzato Junior]

Boa noite Diogo,

Exato, devemos informar a sequencia de UF que o veiculo vai passar a partir da origem até chegar o destino.

Não devemos incluir nessa sequencia as UF de origem e destino.