Add custom logic to what gets put on shipments and invoices

Support Developer
, ,
1

Hi. I was just thinking of where to best put some extra logic as to what I want on my delivery notes / invoices when they are created from a Sale and it’s SaleLines.

Would it be ok to just write my own _get_shipment_moves ( modules/sale: 5ce863742e26 sale.py ) or would it be better to do this in create_shipment ? (modules/sale: 5ce863742e26 sale.py ) ? Or would this possibly cause complications with anything else?

Basically what I want to do is just filter out some internal use only sale lines that I need, but do not want on the delivery notes and invoices, but do not want to have to remove manually either.

2

I do not think you can ignore to invoice or ship some sale lines. If so the sale will never be completely done.
If those lines must not be shipped or invoiced, I guess they should be comments.

1 Like
3

Thanks for pointing that out I did not think of that at all [and this way it would be like 10 times easier for me anyway].

Ah that is a good point… making them comments sounds good and I will test it. ( I assume that comments would still be listed on the sale report though correct? )

although I think i would have a problme then as I want products assigned to them (to explain why: I am filling in some fields in my own on_product_changed method to make things easier for repeatedly ordered stuff) … maybe I could/should make some sort of “special” type for that … like a comment which can have a product associated too … gotta look into that

4

@ced I just had an idea that would work perfectly for me (I think).

Since all I need is the link to the product and my extra fields … what if I change the visibility of the product field (and some others) for comments to include the data I need for my other reports and/or automatically mark those as type comment before processing is started.

Do you see any issue with that? (Since I did test if I enter a line wihta product,… and save it then change type to comment, save, → confirm and then go back changing it to line it will still have all the data (as I had expected but I wanted to try it)

Alternatively I was considering adding my own type of SaleLine as “comment with product” but that seems to be way more work than just changing the visibility of the fields for comment type.

5

I can not comment on this. I do not understand why you need a sale line with a product that is not a line.
I think there is serious flaw in such design.

6

I only need the product associated wiht a comment line as I want the data on the sale report but not in invoice or delivery. basically think of it as a “comment+”

Really I only wanted to confirm if the visibility of the fields Can have any undesired effect (which I doubt)

7

It is highly risky to use an existing for a different purpose. So add a new field.
But I still do not understand why a comment line should need to have a link to a product. For me there is a design issue.

8

It’s because I have sale lines with data for sub-components that I do not want to be seperately listed on the delivery note/invoices (not all of those will be added as product kits though for maintainability reasons).

risky as in? potentially removal of product-> sale line (type comment) link or something like that? [because at the moment that data is kept in the Sale Line anyway if the type were to be changed after selecting a product).

But that aside … I just am thinking if I make sure I have all the data needed on the report in my extra fields (that are there anyway) then even if the product link was gone i wouldn’t really care. so I could just have the user select the product so that the data gets filled in on on_change_product and then the extra fields for my report are already filled anyway. So unless I am missing any fields there (which I can easily fix) then you are right that I probably wouldn’T need the product → sale line link anymore.

From a quick test I can see that the only fields I would need for me report after on_change_product was called would be uom and amount. the rest is not needed either. if all I need to do is copy that to another field then that is definitely easier

I’m going to check that later and will probably just go with that - then that wouldn’t even require any modifications to the existing code as well so less testing needed.

Thanks for pointing this out . sometimes some brainstorming really helps simplifying stuff and avoiding implementing unneeded stuff

9

Then extend the report instead of changing the data model.

10

Actually… all this back and forth “brainstorming” (at least it was for me) made me realize one thing: I do not really care/mind if tryton processes all the subcomponents as delivered… All I need is to not show it on the delivery note / invoice reports.
So really I do not need to do anything else in sale that I am not already doing but just hide what i don’T need on the reports later … I was thinking in waay too complicated ways here (yet again).
Thanks for that @ced (not sure if by your last reply you meant just that or if you were talking about the SaleReport but it made me realize all I needed to do was customize those 2 reports for the delivery notes and invocies instead)

11

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.