Community mailing list archives

Re: Sale and purchase workflow

gunnar wagner
- 09/18/2015 04:11:39
On 9/18/2015 4:04 PM, Ana Juaristi wrote:

>> So I started to try to collaborate on this cleaning... opening my first 9.0 bug on github about invoicing from pickings.

so you have hope that an issue on github will be addressed? There is a long thread about the "issue mountain on github" (8.0) which in the end proved that issues are not looked at by anyone (expect the frustrated reporter maybe)
maybe some have hope that this only effects ancient versions like 8.0 and the all new, brilliant 9.0 will be reviewed and fixed and just be splendid (at least until focus switches to 10.0)

<blockquote cite="" type="cite">
Hi Fabien:

I agree with everybody that main sale/purchase workflow should be intensively tested and bugs cleaned before the release. As non technical developer but functional consultant, my big concern is not about workflows has been erased or they are still there. Meantime I can configure the business processes to my customers is right for me.

Thank you very much:


2015-09-18 9:04 GMT+02:00 Fabien Pinckaers <>:
Hi Graeme,

Thanks for the feedback. Don't hesitate to send more.

For example in the order lines are iterated over 4 times.  This seems pointless and could just be once.

We will improve the code. But it should not change anything in the performance since it's just Python code, no SQL.
In it is a bit difficult to understand what is going on.  In general there are no docstrings or help throughout making community adjustment that much more difficult.

Yes, we will add a docstring and parenthesis. here it seems a design decision has been made that invoices out count towards quantity but refunds are not to decrement it.  I'd like to understand that.  A common action is/was refund and modify, to me that would double count.

That's actually a bug. Thanks for reporting, we will fix it. The normal behaviour:

- Refund generated from SO should be taken into account (usually because of a too large deposit or decrease of sold quantities)
- Refund generated from Accounting should not be taken into account, even if it's a refund of an invoice generated from a SO (exceptions should always be handled manually, there are too much possibilities to automate one behaviour)
This will be fixed today. here one of the most frustrating inconsistencies has been retained.  Sale Orders get their tax from the product, invoices fallback to the account.  Pretty please change this.  In multicompany environments this is so frustrating.  Only a user with access to all companies can create a product if it needs taxes.  If another user does, then another company uses it, no tax gets charged.

It's the normal behaviour and was already like that in v8. It's normal that a multi-company product should define his taxes for every company. Note that there is a default tax on the company. So, newly created product should be defined using this default tax. (so you only have to change i you want another tax than the default one).

Of course a roadmap would be nice, especially since only a few days ago a code freeze was announced.  Seems every release a massive surprise hits just before launch. 6.0 - not 5.x, new web client, 6.1 - Hmm no surprises I remember

Yes, 6.1 was the biggest flamewar actually: drop of GTK client to focus on web client.


Post to:

CEO Avanzosc, S.L : Office phone / Tfono oficina: (+34) 943 02 69 02
Ana Juaristi Olalde : Personal phone: 677 93 42 59. User/usuario skype: Avanzosc

El contenido de esta comunicación y de toda su documentación anexa es confidencial y se dirige exclusivamente a su destinatario. El uso no autorizado de esta información está prohibido por la legislación vigente. Si usted no es el destinatario le rogamos nos lo indique, no comunique su contenido a terceros y proceda a su destrucción. Disculpe las molestias que le haya ocasionado la recepción indebida de este e-mail. Sus datos figuran en un fichero cuyo titular es Avanzosc, S.L., a quien usted puede dirigirse para ejercer sus derechos de acceso, rectificación, cancelación y oposición en Klara Donea 13, 20720, Azkoitia (Gipuzkoa), Tef. 943 02 69 02 -

Komunikazio honen edukia eta dokumentazio erantsia konfidentziala da eta hartzaileak bakarrik jaso beharko luke. Indarrean dagoen legeriak debekatu egiten du bertan eskainitako informazioa baimenik gabe erabiltzea. Komunikazioa zuri iritsi bazaizu, baina zu ez bazara hartzailea, mesedez, guri jakinarazi, eta jasotako informazioa ez inori jakinarazi eta suntsitu. Barkatu okerreko email hau jasotzeak eragindako eragozpenak. Zure datuak Avanzosc, S.L. enpresaren fitxategietan sartuta daude. Zure datuak atzitzea eska dezakezu, bai eta, datuak zuzentzea, ezereztea eta tratamenduari aurka egitea ere. Horretarako, enpresara jo dezakezu, helbide honetan: Klara Donea 13 20720, Azkoitia (Gipuzkoa), telefonoa: 943 02 69 02 -
This message and all documents attached to it are confidential and intended only for the person or entity to which it is addressed. Any use of this information by unauthorised persons is prohibited under current legislation. If you received this message by error, please advise us, destroy it and refrain from communicating its contents to third parties. We apologise for any inconvenience receiving this email improperly may cause to you. Your personal data are included in a file owned by Avanzosc, S.L. If you want to exercise your rights of access, correction, erasure and objection you can contact the Controller at Klara Donea 13 20720, Azkoitia (Gipuzkoa), T: 943 02 69 02 –

Post to:

Gunnar Wagner | Iris Germanica Co., Ltd. | Jin Qian Gong Lu 385, 8-201, Feng Xian District, 201404 Shanghai, P.R. CHINA
+86.159.0094.1702 | skype: professorgunrad | wechat: 15900941702