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: 1. When delivering spare parts that are parts of a standard machine that cannot be grouped with a unique material number. 2. When returning parts for repair or erroneous delivery, false picking etc. 3. When providing samples to a client or for an exhibition. 4. When receiving payment in advance before executing the order that is based on the invoice. 5. When declaring customs values across borders that diverge from invoiced value (discounts, offsetting, settlement, barter trades) 6. When splitting orders in different parts due to lead times, different locations, cross-trades, transporting both air and sea. 7. When obtaining regulatory aprovals from national or international authorities in advance of a specific date. 8. When assuring and clarifying final payment terms and conditions for a final clearance from client to avoid conflicts. 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. This being said, I would like to welcome everybody to add further information and comment on the reasons why the pro forma invoice is important to Tryton and the business models associated with it. After having hopefully reached a consensus on this, I would like to outline a possible workflow. 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 would like to attempt to keep both essential parts in a form and style that most of us are able to understand it and follow it. This is something that I have noticed that cannot always be ensured by the procedure so far. 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 I am no friend of big bureaucracy, but in our case, I find it quite helpful to enable people to participate and integrate available knowhow and knowledge from all sides. Cheers, Denis
