Sale [history] improvements needed

[risto3]

In order to better automate all the ‘pieces parts’ from customer quotations up to final invoicing, I’d like to outline some initial aspects deemed to be necessary to satisfy reliable company audit trail processes but aren’t provided by the base Tryton platform.

The goal is to quickly establish a blueprint.

First, to set the scope, this post primarily concerns databases having the sale_history module activated, where quotations are versioned, that is object to discussion/negotiation with the customer.

Indirectly concerned is with the sale_amendment module activated, mostly because of the simple fact that it uses versioning for amendments of confirmed orders.

The initial needs statement:

1. Each revision of a quotation needs to have a quotation_date that is persistent and chronological,
2. For each revision of a quotation it should be possible to recuperate the [cached] report,
3. If a customer signs a previous revision of a quotation, or refers to one in their order form, it should be possible to revert back to that revision in order to confirm, without creating a new revision.

Why these needs?

As indicated, in a reliable audit trail for customer quotation to invoicing, the document management system of Tryton should be able to reproduce with fidelity the quotation initially issued and communicated to the customer… much like it does with invoices using the invoice cache.

This is because the quotation is a legal document issued by the company to initiate the contract process with the customer.

If the customer signs an issued quotation, or issues his own order form referencing the quotation number and date with reference to the quoted products and/or services with prices or the total amount, and does so prior to the validity expiration date of the quotation, then the sale contract has been made.

The quotation_date permits not only to print the quotation report, but also permits accessing a date that is not overwritten with the closing sale date which, naturally, is not the same as the quotation_date though currently it is thus used while in the ‘quotation’ state.

The tuple which uniquely identifies a quotation is the quotation number and date.
If there has been any revisions, the revision becomes part of the quotation number with a new quotation date, which naturally must not be prior to a previous revisions’ quotation_date.

Though I mention only sales here, it seems logical that the same needs apply to purchases, with possibly the exception of caching the quotation report…

For the company’s role as customer, it is probably the confirmed order that should be focused upon as opposed to the suppliers quotation, which is probably manually cached as file attachment(s).

[pokoli (Sergi Almacellas Abellana)]

@risto3

Each revision of a quotation needs to have a quotation_date that is persistent and chronological,

Isn’t that the write that of the revision?

@risto3

For each revision of a quotation it should be possible to recuperate the [cached] report,

You should be able to open the historized record and print the report from there. It will print the values of the historized record.

@risto3

If a customer signs a previous revision of a quotation, or refers to one in their order form, it should be possible to revert back to that revision in order to confirm, without creating a new revision.

Maybe this can be solved by just a wizard which picks the revision number, restores the values from the history record and then stores the final number as version.

But note that this will cause duplicated verion number when amending to the confirmed sale.
SO probably the best is just to create a new number with the right data.

[risto3]

Well, taking these in order

1. it appears that ‘show revisions’ is actually show history ‘dates’ but without any indication of ‘what’ happened… also ‘show journal’ seems clearer, at least the event and transition is indicated. But it seems to be missing a number of the history activity… notably the initial quotation prior to be revised for the first time.
   Perhaps I’m old school, but it has always been considered poor practice to use metadata (ie write_date) for something that belongs in the user data model. They are distinct domains.
   An example is reconciliation_date, which is the oldest patch I’ve on tryton since migrating from openerp because tryton maps reconciliation_date onto the reconciliation create_date, which just doesn’t jive when creating and importing existing data.

2. Thanks for this hint, so I chose the date and moved up or down based upon the state of the record displayed… finally I tried to print the report… when the reported printed with today’s date, I remembered that the report uses ‘Date: <format_date(sale.sale_date or today, sale.party.lang)>’

3. Not sure I follow here. The proposed restoration is only prior to confirmation, so I believe restoration back to a prior quotation revision is unhindered.
   Though it should be checked if amendments only ‘increment’ the current revision, or operates like a sequence and picks the next revision available. If the latter, which I hope is the case, there shouldn’t be any problem.

[risto3]

@pokoli

…
But note that this will cause duplicated verion number when amending to the confirmed sale.
SO probably the best is just to create a new number with the right data.

I slept on this and it makes me quite a bit uneasy.

Firstly, in a negotiation, it is normal to revise quotations until the parties agree on not only the object of the quotation but the price. This is the confirmation of the sale (or purchase, if that is the case).

If there are any amendments, it can only be upon the confirmed sale. So I’m wondering if it’s not the real problem, munging amendments with revisions, as they are not exactly the same thing.

Furthermore, during invoicing (which may be multiple), the amendments are frequently expected to be appended, in order, at the end… as they entail primarily modifications (additions and/or reductions) to the confirmed sale.

To give an example, imagine a sale done on revision 3 of a quotation pertaining to furnishing and installing a few multi split air conditioner systems of a particular size.

In our numbering system, this is displayed as ‘D23-123C’ where ‘C’ is the ASME Y14.35 encoding for the third document revision or /3 (BTW we have a sale_history_letters module to implement that logic).

This number should never change, once confirmed, even with amendments, as the sales reference, in absence of customer order form&number, is the physically or electronically returned signed&dated quotation. In presence of such customer order form&number, the quotation date and number is indubitably referenced.

The amendments should simply be sequentially numbered from 1 which, IMHO, implies somewhat that the revision be stored [for amendments] in the Amendment class.

But, differing from revisions which replace the previous quotation, amendments are applied to the version confirmed, in order of occurrence, much like correction invoices work, where the resulting lines would be appended, amendment by amendment.

In this way, nasty confusion is avoided between revisions and amendments (and rejects from customer accounting departments, particularly public institutions).

Unfortunately it appears that amendments point to their amended sales, instead of the sale being amended - making it rather difficult to unravel what happened.
Also, perhaps instead of going back to ‘draft’, there could be an ‘amending’ state used (probably something needed to replace the ‘valid’ state as well during the amendment process).

An very simple example amendment would be to increase the size of one of the air conditioners adding an additional internal unit.
Another might be to replace a cassette interior unit by a ducted one.
Naturally, we frequently have much more complicated ones.

I guess there is a possible alternative where the sale_amendment module could be disabled, and a related sale could be made for the amendment.
Then at least the resulting amendment invoice(s) could then be appended, but that seems to be an awful lot of manual work to deal with all the missing relationships between the original sale and its forged amendments… Tryton is about normally about automation not complication.

Unfortunately, at the moment we frequently need to resort to ‘manual’ invoicing to get over these difficulties.

In short, perhaps this indicates that a fork of this topic is needed to dwell upon the amendment process mechanics.

[pokoli (Sergi Almacellas Abellana)]

@risto3

If there are any amendments, it can only be upon the confirmed sale. So I’m wondering if it’s not the real problem, munging amendments with revisions, as they are not exactly the same thing.

This is not how tryton is designed. Amendments are used to update the sale after it is confirmed.
If you do not want such behaviour your should not activate the sale_amendment module.

@risto3

Furthermore, during invoicing (which may be multiple), the amendments are frequently expected to be appended, in order, at the end… as they entail primarily modifications (additions and/or reductions) to the confirmed sale.

This contradicts your past sentence. Are amendments used or not?

@risto3

This number should never change, once confirmed, even with amendments, as the sales reference, in absence of customer order form&number, is the physically or electronically returned signed&dated quotation. In presence of such customer order form&number, the quotation date and number is indubitably referenced.

Then just store the right number once the sale is confirmed and override the full_number property to return it if its already stored.

Just to clarify: I think what you need are some customizations that extend current features to implement your specific use case.

[risto3]

@pokoli

@risto3

If there are any amendments, it can only be upon the confirmed sale. So I’m wondering if it’s not the real problem, munging amendments with revisions, as they are not exactly the same thing.

This is not how tryton is designed. Amendments are used to update the sale after it is confirmed.
If you do not want such behaviour your should not activate the sale_amendment module.

?? I believe we are in violent agreement here

@pokoli

@risto3

Furthermore, during invoicing (which may be multiple), the amendments are frequently expected to be appended, in order, at the end… as they entail primarily modifications (additions and/or reductions) to the confirmed sale.

This contradicts your past sentence. Are amendments used or not?

Currently the use is extremely limited, some of the reasons already mentioned supra…

@pokoli

@risto3

This number should never change, once confirmed, even with amendments, as the sales reference, in absence of customer order form&number, is the physically or electronically returned signed&dated quotation. In presence of such customer order form&number, the quotation date and number is indubitably referenced.

Then just store the right number once the sale is confirmed and override the full_number property to return it if its already stored.

Just to clarify: I think what you need are some customizations that extend current features to implement your specific use case.

Perhaps there’s some extensions needed to permit more robust change orders managed in a reasonable, auditable manner from initial sale (or purchase) to final invoice.