How do you manage several PMP per warehouse ?
when you are encoding a customer order and when you have to choose (buy price)
between pfp (product fournisseur priceS)
or PMP (Prix Moyen Pondérés) you have to choose between all the PMPs of all your warehouses (so sometimes different PMPs of the same product in a different warehouse...) ?
or do you have a GLOBAL PMP at the product level, making an average of all your PMPs ?
The GREAT new feature, is that it is finally clearly explained, no ?
Eldy :
"PMP has a clear definition: qty in stock * PMP is a value of your stock. A value of PMP changes only when a product enter into a stock.
It is one of a valuation of a stock (others are "standard", "fifo" and "lifo"). No need to make difference between warehouse.
If 100 products P enters in stock A with price 1X and
100 in stock B with price 2X,
PMP for stock A is X
and for stock B is 2*X.
Why not (even if such notion is not used in industry, we can imagine). Now you move 40 products from stock A to stock B, what is PMP for stock B ?
According to definition of PMP it should be 100 * 2X + 40 * 1X / (100 + 40) = 1,714285714 * X
So you have :
Product P, PMP = 1.5 * X
60 in A at PMP X
140 in B at PMP 1,714285714 * X
Then you sell 100 from warehouse B
So you have :
60 in A at PMP X
40 in B at PMP 1,714285714 * X
So if you take value of stock from warehouse, you get 60_X + 40_1,714285714_X = 128.57_X
But if you take value of stock from product, you get 60 + 40 * 1.5*X = Value 150 * X
As you see 128.57 * X is just a rubish value. And if you imaging when moving into A to B does not change PMP of stock at all, you will also get a wrong result)? The meaning of PMP at stock level just become wronger and wronger when doing internal stock move. In fact "PMP at stock level" was just an invention of Dolibarr."
Please write something against this if it is not coherent for you...
Hubert ANDRIOLO
Gérant F.M. MEDICAL et NORD HYGIENE
Mobile: +33 (0) 6 23 10 17 31
Fax: +33 (0) 9 56 51 95 71
Site: www.fournisseur-medical.com
![]()
Gérant F.M. MEDICAL et NORD HYGIENE
Mobile: +33 (0) 6 23 10 17 31
Fax: +33 (0) 9 56 51 95 71
Site: www.fournisseur-medical.com
2 RUE DE LA JUSTICE
62410 BENIFONTAINE
2016-11-03 10:07 GMT+01:00 <address@hidden>:
Send Dolibarr-dev mailing list submissions to
address@hidden
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.nongnu.org/mailman/listinfo/dolibarr-dev
or, via email, send a message with subject or body 'help' to
address@hiddenorg
You can reach the person managing the list at
address@hidden
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Dolibarr-dev digest..."
Today's Topics:
1. Re: [Dolibarr-association] Dolibarr 4.0.1 (Maxime Kohlhaas)
------------------------------------------------------------ ----------
Message: 1
Date: Thu, 3 Nov 2016 10:07:22 +0100
From: Maxime Kohlhaas <address@hidden>
To: "Posts about Dolibarr ERP & CRM development and coding"
<address@hidden>
Subject: Re: [Dolibarr-dev] [Dolibarr-association] Dolibarr 4.0.1
Message-ID:
<CAMn8xZdieHL-eBsG=OZHd7-_5zoETYJjkFQH_RofeWYh5qWcCg@ >mail.gmail.com
Content-Type: text/plain; charset="utf-8"
Hi Christophe,
Expecting an answer between 18:30 yesterday and 9:00 this morning is a bit
exaggerated...
As for the pmp by warehouse, it has been discussed and explained here
<https://github.com/Dolibarr/dolibarr/commit/ >7b16482cee32b7c9cb8b2f0702bbad 34d18db86b
.
I'm sure you can open a discussion about datatable plugin also... On the
opposite, we use several different modules that includes Google librairies,
and we didn't ask for it to be integrated to avoid multi-sources.
Regarding the roadmap, I agree we can define developments we want in
priority, and the Feature Request on github are for me the roadmap. But
don't forget this is a community development, so developments are made
whenever someone feels like doing something...
At last, it seems to me that after running out of arguments about release
frequency, you "attack" on the release content. Do you hold a grudge or
something ?
Regards,
--
*Maxime Kohlhaas* | Consultant associ?
------------------------------------------------------------ ------------------------
T?l : 06 33 42 92 43
2016-11-03 9:13 GMT+01:00 Christophe Battarel <
address@hiddenfr >:
> Hello Again,
>
> Of course we have no answer as usual.
>
> Another "great" new feature is that until version 4, pmp was stored by
> warehouse, and not anymore since 4.0... why ? who decides ? after
> consulting who ?
>
> Regards
>
> Le 02/11/2016 ? 17:36, Charles Benke a ?crit :
>
> Hello Again
>
> Dolibarr 4.0.2 just delivered that we speak about freeze (one more time
> the 5.0 ?)
>
> So keep calm and just count
>
> 2 month for beta version (November, December) 2 other for the release
> candidate (Janurary, feburary) and we finaly delivery a 5.0 in march ? WE
> don?t respect the roadmap
>
> SO what will be in this new version ?
>
> - The suppression of jquery datatables plugin, used by myList
> and some other additional modules?, just because they made some problems
> with dolidroid ?
>
>
>
> It's fine to have a roadmap in planning terms (which are not required
> since the schedule speaks of January and July so it was March and September)
>
> But it would be more important to have a schedule on functionality is
> added or is removed ...
>
>
>
>
>
>
>
> Bien cordialement,
>
> Charlie Benke
>
>
>
> *De :* Dolibarr-dev [mailto:dolibarr-dev-bounces+
> charles.fr=address@hidden
> <dolibarr-dev-bounces+charles.fr =address@hidden>] *De la part de*
> Olivier Geffroy
> *Envoy? :* jeudi 20 octobre 2016 11:08
> *? :* Posts about Dolibarr ERP & CRM development and coding
> <address@hidden> <address@hidden>
> *Objet :* Re: [Dolibarr-dev] [Dolibarr-association] Dolibarr 4.0.1
>
>
>
> It's depends of the final user
>
>
>
> let's says for a company (who use dolibarr) and make less than 100K per
> month and don't have a lot of externals modules, 2 update per year is easy
>
>
>
> for a big company 1 update per year is enough and with dolibarr isn't a
> problem to stay in 3.8 and to migrate in 4.0 and squeeze the 3.9 (for
> example)
>
>
>
> my 2 cents
>
>
>
> 2016-10-20 10:58 GMT+02:00 Laurent Destailleur (aka Eldy) <
> address@hidden>:
>
> I don't understand. You say "If the major release issued every 6 months
> was free of bug, stable and did not require another install/update after
> barely one month to correct the most glaring bugs that will not be dramatic"
>
>
>
> Every experimented developper know that this argument is the best argument
> to ask to have more release than 2 per year. And you ask less. So why using
> an argue to ask more release: The more is the delay between 2 versions, the
> more is the bug rate on production (that's why more and more project are
> increasing the release frequency) and difficulty to have a stable version
> is an exponential of the number of feature added or modified. So your argue
> is just incomprehensible.
>
>
>
> I used on production each version, as soon as it is release and announced
> and I have no problem. Also the stability of a version depends on bugs
> fixes during the beta period and number of unit tests added when added new
> future. Developers must work on this direction instead of an "against
> productive" idea.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> 2016-10-19 21:34 GMT+02:00 Charles Benke <address@hidden>:
>
> OK
>
>
>
> If I follow your argumentation ? I will deliver a brand new version of all
> my modules each week, because I have decide to planned like this
>
> Even if the version is not enough tested, even the previous release have
> some know bug, even if the document are not upgraded ?
>
> And I will explain to my disgruntled customers that this is a good method
> to make a better quality and simplify their upgrade ...
>
>
>
> Release a version every 6 months because FOR YOU is more simple is not
> acceptable. I do not develop modules dolibarr because it is easy but
> because it allows users to better manage their company, create growth, the
> emploies ...
>
>
>
> If the major release issued every 6 months was free of bug, stable and did
> not require another install/update after barely one month to correct the
> most glaring bugs that will not be dramatic
>
>
>
> The minimum straightforwardness that we can have with users downloading a
> new major release is to explain that this version DO NOT BE USED IN
> PRODUCTION.
>
>
>
>
>
> Bien cordialement,
>
> Charlie Benke
>
>
>
> *De :* Dolibarr-dev [mailto:dolibarr-dev-bounces+charles.fr =
> address@hidden] *De la part de* Laurent Destailleur (aka Eldy)
> *Envoy? :* mercredi 19 octobre 2016 17:34
> *? :* Posts about Dolibarr ERP & CRM development and coding <
> address@hidden>
>
> *Objet :* Re: [Dolibarr-dev] [Dolibarr-association] Dolibarr 4.0.1
>
>
>
> Your argue is not coherent.
>
> You say you want less version so you have to test your module less often.
> It also meas your customer upgrade version less often.
>
>
>
> So why just don't you make your tests every 2 versions. Result will be
> same. You will work only every 1 year instead of every 6 month, and your
> customer would be able to upgrade only every 1 year (once your module is
> validated for the version) instead of every 6 month.
>
>
>
> It's just your choice and the choice of your customer.
>
>
>
> Having a release every 1 year, means nor integrator, nor users have
> choice. Also it means a lower quality and exponentiel work to make upgrade.
>
> But if you prefer to upgrade your module once per year, just do it. You
> can, it's just a choice you must do. It is not because there is a new
> version, that you must upgrade your module. If you prefer to follow a 1
> year release, just follow this rythm and ask you customer to follow also
> this rythm. The only difference is that the ryhtm is defined by you instead
> of being imposed be a dolibarr low release rythm.
>
> And i think it is better to let integrator to decide their release/upgrade
> frequency then having this decied/forced by Dolibarr.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> 2016-10-19 16:49 GMT+02:00 Charles Benke <address@hidden>:
>
> Actually I maintain 22 modules, some are simple, some are complex. To test
> all of them correctly (use all feature, modify doc, ?) each time a new
> major version of Dolibarr is release is more than 2 full weeks long for
> Romain an me...
>
> During the month a new version comes out, sales of modules on dolistore
> are halved cut (according to my information it is not related to my modules
> only).
>
>
>
> I could do as some others ? , just change the version number and wait for
> my clients put bugs me but I do not find it honest
>
>
>
> Most integrators with whom I work no longer wish to upgrade versions as
> there are no major advances between two versions either-called major
>
> The final version of each major costs money and energy to NOTHING: just to
> show that development teams are able to release two versions per year, two
> versions full of vacuum .
>
>
>
> We have all been waiting for new accountancy module for 2 years. The time
> spent to release a new version will have better been employed to work on
> this strategic module?
>
>
>
>
>
> Bien cordialement,
>
> Charlie Benke
>
>
>
> *De :* Dolibarr-dev [mailto:dolibarr-dev-bounces+charles.fr =
> address@hidden] *De la part de* Developpement | Open-DSI
> *Envoy? :* mercredi 19 octobre 2016 16:24
> *? :* Posts about Dolibarr ERP & CRM development and coding <
> address@hidden>
> *Cc :* address@hiddenorg
> *Objet :* Re: [Dolibarr-dev] [Dolibarr-association] Dolibarr 4.0.1
>
>
>
> Hi
>
> Thanks to Camille for pointing the main problem : Module and ratio time
> spend / bug / patch
> As integrator of Dolibarr, it's not "sustainable" for me to test every six
> month Dolibarr and the modules I'm commonly using. Today I only install
> 3.9. Maybe next year, I will uprade to 5.0 or not... depending of what
> functions will be added or remaining experimental.
> Modules are too often broken by new version. On the Dolistore you can see
> module labeled 3.x-4.0 who are in fact broken with the last version or
> doesn't exist for the current version of Dolibarr. I think it's not good
> for the reputation of Dolibarr.
> I'll be pleased to discuss about this subject in Valence :-)
>
> Regards
> Philippe Scoffoni - Open-DSI
>
>
>
>
> Le 19/10/2016 ? 15:14, address@hidden a ?crit :
>
> Hi
>
>
>
> Thanks for sharing this.
>
> I agree, Dolibarr migration is pretty nice !
>
>
>
> but only core part, modules looks more problematic to update.
>
>
>
> Regarding communication, this is a work in progress.
>
>
>
> Yes I saw this :) But looks again difficult. But it's better :)
>
>
>
> From now on, we'll have systematic annoucement when a major version is
> released, minor version too, why not. A communication group has been
> started within the fundation with the goal to better communicate with the
> community. We already are present on social medias, but this dev
> mailing-list and the dolistore customers are 2 audiences we poorly
> communicate with (not to say not at all).
>
>
>
> I don't understand logic, dolibarr users/community are on forum,
> mailinglist but piority is social network, strange
>
>
>
> About your concerns around PRs and plugins, I'm sorry you feel that way.
> PRs are usually correctly integrated and not lost.
>
>
>
> Maybe now, I'll try again. But I'm not sure. My fear is to lost again
> energy to nothing.
>
>
>
> Plugins are the responsibility of their developers. Personnaly, our
> plugins are upgraded with the new releases
>
>
>
> I'm not module developper then I don't know if is complicate or not to
> follow release and provide. As user, i prefer to have my own script and
> don't use module. In my use case ratio time spend / bug / patch is too
> heavy.
>
> Thanks a lot
>
>
>
> km
>
>
>
> _______________________________________________
>
> Dolibarr-dev mailing list
>
> address@hidden
>
> https://lists.nongnu.org/mailman/listinfo/dolibarr-dev
>
>
>
>
> _______________________________________________
> Dolibarr-dev mailing list
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/dolibarr-dev
>
>
>
>
>
> --
>
> EMail: address@hidden
>
> Web: http://www.destailleur.fr
>
> ------------------------------------------------------------
> ------------------------
>
> Google+: https://plus.google.com/+LaurentDestailleur-Open- Source-Expert/
> Facebook: https://www.facebook.com/Destailleur.Laurent
>
> Twitter: http://www.twitter.com/eldy10
>
> ------------------------------------------------------------
> ------------------------
>
> * Dolibarr (Project leader): http://www.dolibarr.org (make a donation for
> Dolibarr project via Paypal: address@hidden)
>
> * AWStats (Author) : http://awstats.sourceforge.net (make a donation for
> AWStats project via Paypal: address@hidden)
>
> * AWBot (Author) : http://awbot.sourceforge.net
>
> * CVSChangeLogBuilder (Author) : http://cvschangelogb.sourceforge.net
>
>
>
>
>
>
> _______________________________________________
> Dolibarr-dev mailing list
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/dolibarr-dev
>
>
>
>
>
> --
>
> EMail: address@hidden
>
> Web: http://www.destailleur.fr
>
> ------------------------------------------------------------
> ------------------------
>
> Google+: https://plus.google.com/+LaurentDestailleur-Open- Source-Expert/
> Facebook: https://www.facebook.com/Destailleur.Laurent
>
> Twitter: http://www.twitter.com/eldy10
>
> ------------------------------------------------------------
> ------------------------
>
> * Dolibarr (Project leader): http://www.dolibarr.org (make a donation for
> Dolibarr project via Paypal: address@hidden)
>
> * AWStats (Author) : http://awstats.sourceforge.net (make a donation for
> AWStats project via Paypal: address@hidden)
>
> * AWBot (Author) : http://awbot.sourceforge.net
>
> * CVSChangeLogBuilder (Author) : http://cvschangelogb.sourceforge.net
>
>
>
>
>
>
> _______________________________________________
> Dolibarr-dev mailing list
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/dolibarr-dev
>
>
>
>
>
> --
>
> *Merci d'avance a tous ceux qui vont partager la vid?o dans ma signature
> ^^*
>
> *Olivier Geffroy*
> * Consultant Informatique*
>
> *Le rapprochement bancaire dans Dolibarr <https://youtu.be/nXRdIZltRWw>*
>
>
>
> *-------------------------------------*
>
> *Jeffinfo SARL*
>
> *29 rue de la Gare 59320 Ennetieres en Weppes*
>
>
>
> *address@hidden <address@hidden> Gsm : 0608632740 <0608632740> Skype
> : darkj3ff*
>
>
>
>
> _______________________________________________
> Dolibarr-dev mailing address@hiddenorghttps://lists.nongnu.org/ mailman/listinfo/dolibarr-dev
>
>
> --
> ---------------------------------------
>
> *Christophe Battarel Responsable technique Altairis*
> +33 (0)9 52 71 70 96
> Altairis <http://www.altairis.fr> - Blog <http://www.altairis.fr/blog> - Modules
> Dolibarr <http://www.altairis.fr/modules > - Twitter
> <https://www.twitter.com/altairis_fr >
> Financez vos projets avec Dolipro <http://www.dolipro.org>
>
>
>
>
> _______________________________________________
> Dolibarr-dev mailing list
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/dolibarr-dev
>
>
--
<http://www.atm-consulting.fr>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nongnu.org/archive/html/dolibarr-dev/ >attachments/20161103/64108020/ attachment.html
------------------------------
Subject: Digest Footer
_______________________________________________
Dolibarr-dev mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/dolibarr-dev
------------------------------
End of Dolibarr-dev Digest, Vol 164, Issue 5
********************************************