chore(export-order) : check if has updated by tiny before send

[matheusgnreis]

Today we have a loop problem when status isnt correctly. Some times we receive two status closely

So, we receive webhook status and patch him on tiny. But when we patch, sometimes tiny already has new status, so we change tiny to preparado para envio, when tiny was enviado, so notify us ... and order in tiny goes to wrong side of fulfillment people and then they need to re-work all orders to separe then to shipped again.

[leomp12]

Mas ainda tem um problema aqui, você não sabe aqui se a atualização do pedido é por status de entrega, com essa alteração aqui um pedido estornado por exemplo, que foi salvo como enviado no Tiny, não seria atualizado da plataforma para o Tiny.

[leomp12]

Quer dizer, se o lojista muda o status no Tiny (para NF emitida, enviado ou o que for), depois o pedido é atualizado automaticamente ou manualmente na plataforma para cancelado, o status cancelado não seria enviado pro ERP. Pior seria se o lojista trocar o status do pedido no Tiny antes da aprovação do pagamento, nesse caso o Tiny nunca receberia status de aprovação. Acho que ainda é necessário checar de alguma forma se atualização atual é do status de entrega mesmo, se não for não faz essa checagem aí.

[leomp12]

Não sei se isso vai dar muito certo não, como está o histórico do pedido em questão? Não seria o caso só de editar o parse do status pra pegar o último status do histórico por data em vez do current em https://github.com/ecomplus/app-tiny-erp/blob/master/functions/lib/integration/parsers/order-to-tiny/status.js ? 🤔

[matheusgnreis]

O problema ai é que por exemplo, esse último que postei a foto, por algum motivo, não teve o update do enviado, aparentemente deu timeout. No v2 da google, consigo filtrar pelo trace daquele fluxo específico e o retorno foi timeout do promise all lá

E ai mandar sempre o último, poderia dar erro também, se esse último não for correto.

[leomp12]

Isso do print é importação, não exportação, você tá editando é exportação nessa PR então não mudaria nada nessa execução em específico... Fora isso não entendi o que você falou do timeout com pegar o status pela última entrada no histórico, o que tem a ver?

[matheusgnreis]

O que tem haver é que por conta de uma não atualização do pedido da e-com, o último status no fulfillment iria ser pronto pra envio, o que faria atualizar errado de toda forma no Tiny, por isso a ideia de não atualizar lá, quando a informação já veio de lá

[leomp12]

Eu perguntei o que tem a ver o timeout com o fato de usar o status do histórico em vez do current, tendeu? Isso que eu tinha sugerido e não mudaria nada no timeout aí, não foi a causa, nem vai ser a solução pra esse timeout. Eu sugeri isso pro caso de o status no histórico estar certo por ser atualizado antes, mas o status no current ainda estar o anterior e pelas atualizações simultâneas enviar o current incorreto pro Tiny... Por isso perguntei inclusive se verificou os status e histórico no JSON do pedido em questão.

A sua sugestão eu entendi, problema é que ela vai gerar outros bugs, você percebeu? Por exemplo, se o lojista colocar no Tiny que está preparado para envio antes da aprovação, quando o pedido for aprovado o status não será atualizado no Tiny, acredito que isso seria um problema grave.

Se pedido na plataforma estava incorreto por causa desse timeout na importação, o correto não seria tentar corrigir isso na importação? Se realmente for verificar flag no fulfillment você vai ter que verificar pelo menos a data também, pelo menos intuir de alguma forma que a exportação sendo executada é por atualização de status de entrega, caso contrário a exportação tem que continuar normalmente.

Em qui., 1 de set. de 2022 21:38, Matheus Reis @.***> escreveu:

O que tem haver é que por conta de uma não atualização do pedido da e-com, o último status no fulfillment iria ser pronto pra envio, o que faria atualizar errado de toda forma no Tiny, por isso a ideia de não atualizar lá, quando a informação já veio de lá

— Reply to this email directly, view it on GitHub https://github.com/ecomplus/app-tiny-erp/pull/120#issuecomment-1234943116, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACOZELGIDVB35LIPZE7FEUTV4FEADANCNFSM6AAAAAAQCKNG4I . You are receiving this because you commented.Message ID: @.***>

[matheusgnreis]

A sua sugestão eu entendi, problema é que ela vai gerar outros bugs, você percebeu? Por exemplo, se o lojista colocar no Tiny que está preparado para envio antes da aprovação, quando o pedido for aprovado o status não será atualizado no Tiny, acredito que isso seria um problema grave.

Tiny não tem campo pra dois status, então se o lojista colocou em um status avançado pós aprovado, é um erro dele. Seria o mesmo tipo de erro que colocar o pedido como aprovado e não estando, porque a expedição pega o preparando pra envio e já dá sequencia.

Se realmente for verificar flag no fulfillment você vai ter que verificar pelo menos a data também, pelo menos intuir de alguma forma que a exportação sendo executada é por atualização de status de entrega, caso contrário a exportação tem que continuar normalmente.

Vou colocar por data também, porque ele me mostrou uns pedidos que tem mais de 500 atualizaçoes de status, até que em algum determinado momento deu pau, não atualizou e travou.

![Uploading image.png…]()

Para mim isso entra na mesma situação de loop de estoque, não deveria poder atualizar infinitamente. O problema pra mim é que vai continuar gerando esse loop. Talvez para resolver isso, colocar uma opção a mais na atualização de não enviar status de envio para o tiny. O essencial é o financeiro, pois se cancelar na e-com, precisaria reenviar para o tiny.

[matheusgnreis]

Então, de fato tenho que pegar a hora do payment history e fulfillment para saber qual foi o último alterado, pra saber se foi pagamento ou envio, para poder barrar. No caso, as últimas entradas de cada um

Não sei se isso vai dar muito certo não, como está o histórico do pedido em questão? Não seria o caso só de editar o parse do status pra pegar o último status do histórico por data em vez do current em https://github.com/ecomplus/app-tiny-erp/blob/master/functions/lib/integration/parsers/order-to-tiny/status.js ? 🤔

Até fiz aqui, mas se o pedido for por exemplo pago via fidelidade e ele for o último, em muitos casos será, irá atualizar lá erroneamente. Então filtrar pelo último, só pra saber o último modificado e se for de entrega e já existir flag, não enviar. Ideias, depois voce avalia se dá