-------- Message transféré --------
Sujet : [Pro20550] Processus commande totalement refusée
Date : Sat, 7 Jan 2023 14:46:45 +0100
De : Florian Motteau <florian.motteau(a)nereide.fr>
Organisation : Néréide
Pour : Ludovic Peugnet <ludovic.peugnet(a)refectory.fr>, Pierre Gaudin
<pierre.gaudin(a)nereide.fr>, Laurent CRESSON
<laurent.cresson(a)refectory.fr>, antoine.maachi(a)refectory.fr,
pro20550(a)listes.nereide.fr <pro20550(a)listes.nereide.fr>
Bonjour messieurs,
Vendredi dernier Laurent nous a rapporté le cas un peu particulier en BU
d'une commande fournisseur totalement refusée à la livraison.
Actuellement côté ERP il n'y a pas de processus bien défini pour ce cas
: doit on faire une réception, en refusant la totalité ? Côté finance,
doit on émettre une demande d'avoir ou pas ?
Après discussion, il semble nécessaire de prévoir un point avec Ops et
Finance pour définir ce qui doit se passer pour ce cas précis. Ludovic
aurais tu un moment cette semaine (plutôt l'après midi étant données les
contraintes de Laurent) pour discuter de ce point ?
Merci à bientôt
--
Florian Motteau
Co-entrepreneur Néréide
information(a)nereide.fr
8 rue des Déportés 37000 TOURS
Std: 02 47 50 30 54 - mob: 07 49 02 90 43
www.nereide.fr
Réseau Libre-Entreprise
_______________________________________________
Pro20550 mailing list --pro20550(a)listes.nereide.fr
To unsubscribe send an email topro20550-leave(a)listes.nereide.fr
Bonjour Mathieu, bonjour Fred,
On s'apprête à implémenter ce dont on a parlé dernièrement, concernant
les commandes partiellement reçues avec reliquat replanifié. On voulait
vous soumettre un exemple concret avant de se lancer.
Voilà donc ce que ça donnerait :
Commande (rien à signaler)
|{ "adjustments": [ { "businessUnitIdErp": "01FR01RET01",
"receivedQuantityAdjustment": 0, "productIdErp": "10110",
"incomingQuantityAdjustment": 120, "salesDate": [ { "from":
"2022-11-30", "to": "2022-12-20" } ], "sellbyDate": "2022-12-20",
"stockLineErpId": "15781", "receivedDate": "2022-11-29" } ] } |
Réception partielle de 96, 24 replanifiés, quadruple trame :
* on annule 96 planifié sur l'id initial de la commande (15781)
* on reçoit 96 sur un nouvel id (15782)
* on annule 24 planifié sur l'id initial de la commande (15781)
* on planifie ces 24 à une nouvelle date, sur un nouvel id (15783)
|{ "adjustments": [ { "businessUnitIdErp": "01FR01RET01",
"receivedQuantityAdjustment": 0, "productIdErp": "10110",
"incomingQuantityAdjustment": -96, "salesDate": [ { "from":
"2022-11-30", "to": "2022-12-20" } ], "sellbyDate": "2022-12-20",
"stockLineErpId": "15781", "receivedDate": "2022-11-29" }, {
"businessUnitIdErp": "01FR01RET01", "receivedQuantityAdjustment": 96,
"productIdErp": "10110", "incomingQuantityAdjustment": 0, "salesDate": [
{ "from": "2022-11-30", "to": "2022-12-20" } ], "sellbyDate":
"2022-12-20", "stockLineErpId": "15782", "receivedDate": "2022-11-29" },
{ "businessUnitIdErp": "01FR01RET01", "receivedQuantityAdjustment": 0,
"productIdErp": "10110", "incomingQuantityAdjustment": -24, "salesDate":
[ { "from": "2022-11-30", "to": "2022-12-20" } ], "sellbyDate":
"2022-12-20", "stockLineErpId": "15781", "receivedDate": "2022-11-29" },
{ "businessUnitIdErp": "01FR01RET01", "receivedQuantityAdjustment": 0,
"productIdErp": "10110", "incomingQuantityAdjustment": 24, "salesDate":
[ { "from": "2022-12-01", "to": "2022-12-21" } ], "sellbyDate":
"2022-12-21", "stockLineErpId": "15783", "receivedDate": "2022-11-29" }, ] }|
On a donc 2 trames pour annuler le planifié sur 15781, on pourrait
fusionner ces trames idéalement. De votre côté je suppose que ça
simplifie le travail, on va voir si de notre côté c'est possible sans
complexifier les choses.
Est ce que c'est OK pour vous ?
||
--
Florian Motteau
Co-entrepreneur Néréide
information(a)nereide.fr
8 rue des Déportés 37000 TOURS
Std: 02 47 50 30 54 - mob: 07 49 02 90 43
www.nereide.fr
Réseau Libre-Entreprise
Bonjour Lisa, bonjour Lætitia,
Pembe nous a remonté un souci concernant le produit 11115 (jus d'orange
Innocent) sur la BU de Nantes. Une commande a été passée le 01/12, puis
annulée le 15/12, mais le BO (Chinchilla) n'a pas eu toutes les
informations nécessaires : l'annulation n'a pas été reçue pour ce
produit (pas de souci pour les autres produits de la commandes)
En investiguant, nous avons constaté que ce produit n'est pas dans une
catégorie principale, alors qu'a priori il devrait être dans la
catégorie BOISSON. Les produits qui ne sont pas dans une catégorie
principale (celles qui ont "BO" à la fin) ne sont pas synchronisés avec
le BO. Comme le BO a bien eu les infos lors de la validation de la
commande pour ce produit, mais pas lors de l'annulation, on suppose
qu'entre le 01/12 et le 15/12 quelqu'un a retiré ce produit de la
catégorie BOISSON (ou toute autre catégorie principale).
Il se pourrait aussi que ce produit ne soit légitimement pas exporté
vers le BO, et que la BU se soit trompée de produit.
Qu'en pensez vous ?
Bonne journée
--
Florian Motteau
Co-entrepreneur Néréide
information(a)nereide.fr
8 rue des Déportés 37000 TOURS
Std: 02 47 50 30 54 - mob: 07 49 02 90 43
www.nereide.fr
Réseau Libre-Entreprise
Bonjour,
Je vous remonte une chose sur les BCA. Nous ne savons pas si c'est normal
qu'on ait pu ajouter 2x le même BCA sur la même facture.
Merci à vous,
<https://www.youtube.com/watch?v=IHkr2a7zhys>
Maureen Oddono
Comptable Générale
DEJBOX DEVIENT REFECTORY <https://www.youtube.com/watch?v=IHkr2a7zhys>
<https://www.instagram.com/dejbox_/>
<https://www.facebook.com/refectory_club>
<https://twitter.com/Refectoryclub>
<https://www.linkedin.com/company/10271427>
---------- Forwarded message ---------
De : Merryna Burcea <merryna.burcea(a)dejbox.fr>
Date: mar. 20 déc. 2022 à 15:15
Subject: BCA (:
To: Maureen ODDONO <maureen.oddono(a)dejbox.fr>
Salut,
Je t'ai fait une capture d'écran de l'ERP car en insérant les BCA par
erreur j'ai mis deux fois le même (BCA). Et en regardant de plus près, je
me suis aperçue que le BCA avait été accepté 2 fois.
Ce qui n'est normalement pas faisable. C'est comme si le BCA s'est scindé
en deux tout seul. Alors que habituellement si on rentre 2 fois le même BCA
il est refusé car BCA unique.
Bonne journée à toi !
Bonjour,
Comme prévu je viens de livrer 3 tickets en production :
* https://dejbox.atlassian.net/browse/OF-910 (support des réceptions
effectuées avec l'ancienne version)
* https://dejbox.atlassian.net/browse/OF-896 (fix erreur au chargement
de la page de consultation des mvt de stock)
* https://dejbox.atlassian.net/browse/OF-907 (contrôle supplémentaire
sur replanification de commande pour éviter de vider cette date)
Bonne journée
--
Florian Motteau
Co-entrepreneur Néréide
information(a)nereide.fr
8 rue des Déportés 37000 TOURS
Std: 02 47 50 30 54 - mob: 07 49 02 90 43
www.nereide.fr
Réseau Libre-Entreprise
Salut Mathieu,
Si tu es toujours dispo, on peut refaire un tour des scenarios en échec
à 11h aujourd'hui.
à bientôt
--
Florian Motteau
Co-entrepreneur Néréide
information(a)nereide.fr
8 rue des Déportés 37000 TOURS
Std: 02 47 50 30 54 - mob: 07 49 02 90 43
www.nereide.fr
Réseau Libre-Entreprise
Bonjour Mathieu,
Suite à mes tests d'hier pour les différents scenarios de réception, on
pense qu'on pourrait attaquer une phase de recette de bout en bout pour
la communication entre l'ERP et Chinchilla. On se dit qu'on pourrait
déployer nos modifications sur la plate-forme de recette de l'ERP
(https://ofbiz-test.dejbox.io). D'après Pierre cet environnement pousse
déjà ses trames sur une queue RabbitMQ, il suffirait - en théorie :) -
qu'une instance Chinchilla les ingère pour qu'on puisse commencer à
valider nos devs respectifs. On pourrait jouer nos scenarios sur l'ERP,
et contrôler ce que vous recevez et le bon traitement.
Est ce que ça semble jouable de lancer ça à court terme de votre côté ?
Bonne journée
--
Florian Motteau
Co-entrepreneur Néréide
information(a)nereide.fr
8 rue des Déportés 37000 TOURS
Std: 02 47 50 30 54 - mob: 07 49 02 90 43
www.nereide.fr
Réseau Libre-Entreprise
