Le 24/08/2011 16:02, Jean Heimburger a écrit :
Je ne suis pas tout à fait d'accord avec toi.
Une commande est souvent la suite logique d'une propale,
souvent n'est pas toujours.
qui elle est signée par le client et a donc valeur contractuelle.
Pas sur le plan de la compta et donc de la remise. Tu peux tres bien
faire signé 3 commande avec 3 remises si tu veux et finallement en
annulé 2.
Donc si le client signe une propale avec une relise de 100 euros,
cette remise doit forcément apparaître sur la facture.
C'est deja le cas. Quand tu fais la facture, il te faut intégrer la
remise et elle apparaitra.
Le système des remises dans Dolibarr devrait être étendu : il faut
pouvoir ajouter une remise sur une commande.
C'est deja le cas. Il suffit de mettre une ligne négative.
cette remise n'est pas positionnée sur le client et utilisable dans
le futur un peu comme on veut, mais est liée à la commande (et donc
au client). C'est pour réaliser ce genre d'actions (un geste
commercial, parce que le client a passé une commande d'un certain
montant par exemple..), ou gèrer des bons de réductions, très
fréquents dans le commerce, que des utilisateurs saisissaient des
lignes de commandes avec des montants négatifs.
Ce que permet Dolibarr
Nous sommes donc bien en phase.
Je comprend que pour la future comptabilité, il faut des montants
positifs. Pourquoi ne pas créer un type de service spécifique pour
les remises qui seront toujours interprétés comme devant être déduit
du total tout en étant >0. Ce type de service aura de toute manière
aussi une comptabilisation spécifique j'imagine ?
On a le même besoin probablement pour ce qui est des frais de port
(compta spécifique ?).
Ca aura aussi l'avantage de pouvoir plus facilement amémiorer les
templates de documents, car intégrer des réductions et des frais de
port au même niveau que des lignes de commande n'est pas terrible.
Qu'en penses-tu ?
On peut en discuter de vive voix, ce serait plus simple.
On est bien en phase. On dit la meme chose et dolibarr fait bien ce
que tu annonces en 3.1
La seule chose qui manque, c'est que la remise sur la facture doit
etre automatiquement insérée en base au moment de la création de la
facture plutot que insérée par un clic "ajouter remise". Ce sera pour
la prochaine version. Quelquechose me dit que tu as trouvé une
occupation pour ce week-end ;-)
PS: Pour les discussion, il vaut toujours mieux utiliser les ML
developpeur. Que tout le monde profite des débats.
@+
Jean
Laurent Destailleur (eldy) a écrit :
Une comande n'est pas un document contractuel.
Si on veut la saisir 10 fois par exemple pour la corriger on doit
pouvoir. Il ne doit donc pas y avoir de limitation sur les remise a
ce niveau.
Seule la facture doit s'assurer qu'une remise accordé n'est consommé
qu'une fois.
Sur la 3.1, une remise décidé sur les commandes n'est pas recopié en
automatique car il faut que l'utilisateur choisisse expressement la
remise à appliquer. Si il y a 2 commandes avec 2 remises a facturer,
a l'utilisateur de saisir 2 remises. Et l'intgrer au moment de la
facture.
Il y avait donc bien un bug en 3.0
En 3.1 la situation est plus claire, puisque la ligne n'est pas
recopié en automatique et l'utilisateur doit choisir la remise a
appliquer laquelle ne sera pas dispo si elle est consommé, ceci
evitant le double remise.
Un warning disant de faire la manipu serait un plus mais ce n'est
pas un bug sur la 3.1 beta, au contraire, c'est un bug qu'on
laissait passer et qui empeche d'evoluer vers la compta double
partie qui a été supprimé.
Le 22/08/2011 21:31, Jean Heimburger a écrit :
Suite au mail que j'ai envoyé cet AM concernatn les remises saisies
comme des montnats négétifs sur une commande et qui deviennent des
ligne facturées sur la facture
Juanjo m'a envoyé ce post sur le forum international.
http://www.dolibarr.org/forum/12-howto--help/17770-negative-prices-not-working#18561
Puisque la saisie de remise en négatif ne marche pas en 3.0, j'ai
essayé par la méthode indiquée et je vois que c'est toute la
gestion des remises qui est KO puisque si on créé une remise sur le
client, elle devient une ligne de facture sur la facture.
Je comprends le changement, mais là ça provoque une régression qui
n'auraient pas dû être dans une version stable. Ca donne des
utilisateurs mécontants et nuit à la longue au projet.
J'ai essayé sur la version Beta :
On peut affecter une remise absolue à une commande, mais elle n'est
pmas reportée sur la facture qu'on créée.
De plus on peut affecter la remise deux fois (et plus) sur la même
commande.
Pour moi ce sont des bugs à corriger avant de publier la 3.1 comme
stable.
Jean