Questions about deleteing SO information after invoice posted

ae1351

New Member
Hi,
I know that SO information (so_mstr, sod_det and so on) will be deleted
when it is shipped and the invoice is posted provided that all the ordered
quantities of the SO detail lines have been shipped.
My questions are:
1. why that information has to be deleted?
2. How about if some of them are not shipped?
3. If I want to keep the "original SO", what can I do?
4. Suppose that I had the source code and modify the program to keep
the so_mstr and sod_det records, what's the side effect to other modules
(e.g. MRP)?
Thanks in advance
 
1. why that information has to be deleted?
Well it might have done to keep the lesser load on Db , as you can get all the information OF a SO in ih_hist (idh_hist) records. All the so fields have equivalent fields in ih_hist . It also help in reduction of locking in SO maintenence as we only have open order in so_mstr and history is in ih_hist.
2. If some of the lines are not shipped then the whole SO doesn'tt get deleted (during invoice posting). Only the lines which are shipped completely and invoiced are deleted.
I am not sure why you want the original SO , as you can get everything of an SO from ih_hist and if you want to know any modifications done on any SO , then transaction history is best way(depends on control setting).
 

ae1351

New Member
1. why that information has to be deleted?
Well it might have done to keep the lesser load on Db , as you can get all the information OF a SO in ih_hist (idh_hist) records. All the so fields have equivalent fields in ih_hist . It also help in reduction of locking in SO maintenence as we only have open order in so_mstr and history is in ih_hist.
2. If some of the lines are not shipped then the whole SO doesn'tt get deleted (during invoice posting). Only the lines which are shipped completely and invoiced are deleted.
I am not sure why you want the original SO , as you can get everything of an SO from ih_hist and if you want to know any modifications done on any SO , then transaction history is best way(depends on control setting).

Anand, thanks for your information.
Just don't understand why SO information is deleted but not PO or other type of orders.
One of the reason I want to keep the SO records is our users have to print the whole SO when
some of the lines have been shipped (and invoiced) and the information (e.g. price) of the rest
lines is changed. If shipped lines are deleted than they cannot print the whole revised SO. So I'm
trying to keep the shipped lines or even shipped SO in the original status so that users can print
the whole SO when they need (sometimes they ask to print the SO even the whole order has been
shipped and invoiced).

Therefore, I want to know if the shipped and invoiced SO records (e.g. so_mstr and sod_det) are
kept in the system, is there any influence to other modules especially MRP? Is there anyone had
tackle this kind of problems?

thanks
 
Keeping the SO record in so_mstr after the invoice posting might be a big customization..MRP will not be affected as far as demand is concerned as the open quantity will be zero.

As per your requirment, i think you can modify Sales order print program. You can modify it where it can get data from the ih_hist record for the deleted lines and from so_mstr for the remaining lines.
 

ae1351

New Member
Keeping the SO record in so_mstr after the invoice posting might be a big customization..MRP will not be affected as far as demand is concerned as the open quantity will be zero.

As per your requirment, i think you can modify Sales order print program. You can modify it where it can get data from the ih_hist record for the deleted lines and from so_mstr for the remaining lines.

Thanks again Anand.
Your information is really helpful.
Thank you.
 

rongavarra

New Member
Hi,

This might help if you want to keep your so_mstr and sod_det records without modifiying QAD source codes.

1. You may create a customized table with the same structure as so_mstr and sod_det records or you may only create those fields you will be needed in future (to limit disk space consumption).
2. Modify create trigger for so_mstr and sod_det tables to populate the so_mstr and so_det or create a background process that populate the newly created tables for so_mstr and sod_det.

Hope this will help.

Regards,
Ron
 
Top