dolibarr-bugtrack
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Dolibarr-bugtrack] [Bug #1234] Différence "Commandes à traiter" et lis


From: Doliforge
Subject: [Dolibarr-bugtrack] [Bug #1234] Différence "Commandes à traiter" et liste détaillé
Date: Tue, 04 Feb 2014 21:07:59 +0100

Doliforge
Is this email not displaying correctly?
update email preferences.

Différence "Commandes à traiter" et liste détaillé

Latest modifications

2014-02-04 21:07 (Europe/Paris)
Ok, will check in 3.5 (first stable).
It is ok if you fix things in the most recent version only - at least they are fixed ;-).

Answer now

Snapshot

 Details
Submitted by:  Mario DE WEERD (mdeweerd) Submitted on:  2014-02-03 19:42
Last Modified On:  2014-02-04 20:55 
Summary:  Différence "Commandes à traiter" et liste détaillé
Description:  Le nombre de commandes à traiter dans le tableau de bord semble être trouvé à travers une requête SQL

SELECT c.rowid, c.date_creation as datec, c.fk_statut FROM llx_commande as c WHERE c.entity = 1 AND ((c.fk_statut IN (1,2)) OR (c.fk_statut = 3 AND c.facture = 0))

Dans mon cas le nombre de factures visibles dans le détail (après clique sur le nombre affiché) est différent du nombre affiché dans le tableau de bord.

Lorsque je modifie '-3' en '-4' dans l'URL (...dolibarr/commande/liste.php?viewstatut=-3) je vois toutes les commandes à priori et je constate bien autant de commandes en état 'envoi en cours' que le nombre affiché dans le tableau de bord.

Bien souvent je dois clôturer un envoi lié à la commande - étrangement je dois valider bien souvent deux fois l'action "Clôturer" pour l'envoi.
Step to reproduce bug:  A priori, créer une commande, réaliser une facture, régler la facture, réaliser un envoi (valider l'envoi), ne pas clôturer l'envoi.
Vérifier le tableau de bord et le détail.
Detected in version:  3.4.2 Category:  Other
Severity:  5 - Major OS Type/Version:  
PHP version:   Database type and version:  
 Status
Status:  Open Assigned to:  Laurent Destailleur (eldy)
Resolution:  Fixed 

Comments

Mario DE WEERD 2014-02-04 21:07
Ok, will check in 3.5 (first stable).
It is ok if you fix things in the most recent version only - at least they are fixed ;-).
Laurent Destailleur 2014-02-04 20:54
Some changes on this were done into 3.5.
Not sure it fixes your bug, bug it is a too important change to ignore this in 3.4 branch and fix only into 3.5.
So i set report to fixed but if into 3.5 you still get problem, despite changes, please reopened it.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]