Bonjour,

La date demandée référé à la date de pesée sur la SITEBR et non à la ZEBR,

Après Investigation des interfaces reçu pour l’OF 103358 et l’article en consommé entièrement
M199.

La pesée est faite sous deux doses. - Voici l’acheminement des actions effectués.

Date : 05.05.2020

Première pesée

(Pas d’anomalie  : Consommation automatique généré sur EWM – propagé en MM)

 PESEE_IN à 11:26:25

Qte : 4.0011 / HU approché 1000141262 / fin de contenant Non.

 Stocks_out à 11:26:27

article M199 Qte 3.832000 / container status : A / container nmber 2 / HU 1000141262

**************

Deuxième pesée (Cas échéant)

 PESEE_IN à 11:32:25

Article M199 // HU 1000141262 --> bien passée // Qte 3.6411 // Fin de contenant Y
  Stocks_out à 11:42:27

HU 1000200362 , container status // Plant MAPA // Quantity 24.615000 // container statut : A ( Non
consommé)

Système a retourné la quantité actuelle de la HU, sans consommer la partition.

3 pesées SITEBR sont faite sur 2 OFs différents sans un intervalle. Chose qui a perturbé l’intergation
des fichiers vers le S4.

Pour les prochaines pesées de ce mois, et afin de tacler l’anomalie, Il y’a-t-il une possibilité de :

1) Laissez un intervalle de 4 minutes minimum entre chaque pesée.

2) Eviter de faire la pesée pour 2 OFs diffèrent en même temps.(Finir la pesée d’OF 1 -> Passer à
l’OF 2)
j'ai trouvé quelque chose de particulière sur la SITEBR

1) Les stocks out sont toujours générés même aprés un delai

2) les Unités de manutention sont corrompue , le systéme change l'UM a consommer c'est ce qui
généré un probléme à la consommation 

11:42:25 11:42:27 M199 généré pour autre OF