Depuis le passage en version 3.8 la clôture d’une proposition commerciale bouton « CLOTURER » ne génère plus la commande en PROV lorsque l’on choisi « Signer (à facturer) ».
La commande passe bien en statut signée à facturer mais la commande n’est pas générée ce qui est gênant.
J’ai tenté la désactivation / réactivation de divers modules (commande, propal, workflow, facture etc… mais rien n’y fait.
Quelqu’un aurait_il rencontré ce problème ?
Il semblerait que le la version 3.8 ne respecte plus la configuration du module WORKFLOW, en 3.7.1 les commandes étaient générées en PROV automatiquement lors de la clôture signée de celle-ci sans que l’on ai a passer par le bouton « Créer commande ».
Le pb n’est pas bloquant puisque l’on peut toujours créer une commande mais cela ajoute puis étapes pour valider une commande.
CLOTURER > CREER COMMANDE > CREER BROUILLON > VALIDER
au lieu
CLOTURER > Commande crée en PROV
C’est à mon sens une régression assez pénalisante.
Bonsoir à tous,
INFOS POUR LES DEVS DE DOLIBARR.
J’ai un peu avancé sur le pb, il s’avère que le $statut de la proposition = 1 au lieu de 2 lors de l’appel de la méthode
commande_class.createFromProposal(), donc en modifiant le test de $statut==1 (au lieu de 2) cela fonctionne.
modifs lignes 1049
$error=0;
// Signed proposal
// if ($object->statut == 2)
if ($object->statut == 1)
{
J’ai remarqué que la gestion des status était passée de « code en dur » à des constantes, peut être que la coquille vient de là ???
autre chose dans le fichier propal.php je pense qu’il y a un copier / coller de code sur la partie // closeProposal qui est codée 2 fois, j’ai donc supprimé le code ci dessous qui correspond au code de la version 3.7.1 pour garder le plus complet.
// Close proposal
else if ($action == ‹ setstatut › && $user->rights->propal->cloturer && ! GETPOST(‹ cancel ›))
{
if (! GETPOST(‹ statut ›)) {
setEventMessage($langs->trans(« ErrorFieldRequired », $langs->transnoentities(« CloseAs »)), ‹ errors ›);
$action = ‹ statut ›;
} else {
// prevent browser refresh from closing proposal several times
if ($object->statut == Propal:
TATUS_VALIDATED) {
$object->cloture($user, GETPOST(‹ statut ›), GETPOST(‹ note ›));
}
}
}
je vais essayer de trouver à quel endroit le $statut est repassé à 1 dans le fichier propal.php.
Merci d’avance de vos retour afin que ce pb ne soit pas redondant dans les versions suivantes.
Cdlt DP
Bonsoir,
en ce qui me concerne, je ne parviens plus à valider une proposition…
Bonjour,
Je n’arrive plus à valider une proposition commerciale depuis le passage en 3.8.0
J’ai mis une impression d’écran en pièce jointe pour que se soit plus clair : ou est passé le bonton de validation ?
idem. Ne peut plus valider de prov. complètement buguée merci de corriger rapidement vers 3.8.1
Bonjour à tous,
Si votre symtome est que vous ,ne voyez pas apparaitre le bouton VALIDER mais seulement les bouton CLONER et SUPPRIMER, alors essayez de désactiver puis réactiver les modules suivants depuis le menu configuration des modules:
- Module propositions commerciales
- Module commande
- Module Facture
- Module Tiers
- Module projets
Cette procédure à fonctionné de mon côté.
Cdly DP
excellent. merci
Bonjour,
Comme je ne suis pas programmeur, le temps que la mise à jour corrige le problème, serait-il possible de me dire quel fichier modifier exactement afin de régler le problème temporairement ? Ce serait grandement apprécié.
Cordialement,
Kevin
Bonsoir, il semblerait qu’il y ait une coquille dans la mise à jour du statut (état) des propal/commandes lors des validation et classement à facturer.
Pour ma part lorsque je passe une propal en « classer à facturer » et que je crée une facture depuis la page de cette propal , elle ne passe pas en « facturéé » (table llx_propal champ fk_statut : la valeur devrait passer à 4 et non resté a 2 … si j’ai bien cherché ) .
Ce sera surement réglé dans les prochaines mise à jour mais je me posait la question suivante : est ce que si je fais une requête sql directement pour changer fk_statut a 4 , cela suffit et ça ne casse pas le « workflow » de dolibarr ?
J’espère que ça fera avancer les choses.
Bonjour à tous !
Pour ceux qui sont bloqués, il y a un moyen facile de règler temporairement le problème en respectant le workflow.
Il suffit d’ajouter la variable suivante WORKFLOW_PROPAL_CAN_CLASSIFIED_BILLED_WITHOUT_INVOICES avec la valeur 1 dans Configurations > Divers.
Cette variable affichera automatiquement l’option « Classer facturée ».
Il semble qu’il y ai un bug au niveau du nombre de factures liées.
$arrayofinvoiceforpropal = $object->getInvoiceArrayList();
if ((is_array($arrayofinvoiceforpropal) && count($arrayofinvoiceforpropal) > 0)
Dites moi si ça résout le problème aussi chez vous.
Bonjour,
Pour ceux qui sont bloqués tout comme moi, il y a une solution temporaire.
Il suffit d’ajouter dans Configuration > Divers, la variable WORKFLOW_PROPAL_CAN_CLASSIFIED_BILLED_WITHOUT_INVOICES avec la valeur 1.
Ceci affichera automatiquement le bouton lorsque la signature est signée.
Il semble qu’il y ai un problème sur le contrôle du nombre de facture :
Dites moi si ma solution fonctionne aussi chez vous !
Gogeta
L’ajout de la variable fonctionne. C’est un peu brutal évidemment puisque le bouton est du coup toujours présent. Mais au moins il est également là lorsqu’on a besoin de lui 
Bonjour et merci pour cette astuce.
Cela fonctionne également sur une installation fraichement mise à jour vers 3.8.1 .
voir sur le github 
mise à jour récente je pense… passez votre sujet à résolu, non ?
https://github.com/Dolibarr/dolibarr/commit/7d382f7997fec9d9fbdb5e199c8e5befb18dfa11
Merci, tout fonction maintenant.
Thanks Very much
