Am Dienstag, 29. Oktober 2013, 15:06:13 schrieb [email protected]: > With regard to the blueprint of a proforma invoice, I would like to take up > Céd's proposal to draw a workflow for the solution. > > First, I would like to lay out, why the integration of a proforma invoice > is important to Tryton and the business models associated with its > capabilities:
... Thanks, I think this gives a good overview! > The crafting of one or various pro forma invoices in the process of an > order implementation is a crucial and essential step necessary to allow a > convenient work flow of operations. It is also gaining more importance as > companies tend to ensure correct handling and payment in advance to order > processing as a lesson from rising litigation costs during the past years. > The chambers of commerce as well promote the increased usage. ... > As a critical part in this procedure, I would like to propose to first lay > out the commercial side and requirements, and also include them in the > blueprint later, and then add the developing and technical approach to it. I think you posting describes it already pretty good. why don't you just add it to the Wiki? In terms of proces needs that means: Once you have a sales order, you should be able to generate a document (the pro-forma invoice) that looks exactly as your invoice, but does not trigger any material movements or financial postings. Generation of a profroma-invoice should be possible as often as required, basing on the actual status of the sales order. With the last I mean: You should always be able to add items to the sales order (e.g. services like shipping costs or insurance, but additional materials as well). and the ProForma should take this into account. > A. Reasons and rationale > B. Commercial requirements > C. Commercial analysis of implemented status > D. Commercial objective > E. Technical requirements > F. Technical analysis of implemented status > G. Technical objective > H. Caretakers, experts, progress/plan Very sophisticated layout. Where do you draw the line between requirements and objective. Objective should be derived from requirement, or is it just to make it clear? Best/Ax
