> > > I think you posting describes it already pretty good. why don't you just > add it to the Wiki? > > I would like to wait for some replies and comments before writing things down, in order to ensure that we have a consensus on this.
> 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. > > Correct. Every pro forma also must have a unique number in order to be recognized by the fiscal authorities. > > 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? > > I see requirements as the description of the final functionality/technical implementation and the objectives as the reachable/doable steps that we may commit on doing next. There may be a huge gap between what we need (commercially) and what we can realize (technically). Still we may be able to implement next steps technically as other may be dependent on other pre-conditions in the architecture, always keeping the overall final design in mind.
