Tuesday, October 17, 2006

More TP/VS hacking

There is an icon column in the orders list in TPVS, it is used to exclude some orders from the optimizer. If you have used VS01 this screen is familiar for sure.



Users love to have some visual tips for some special cases they need to take extra attention. And with this icon it's so easy to give then what they love. To put a flag on the icon for some small orders we just need this on exit EXIT_/SAPAPO/SAPLVS_VSGUI_005.


LOOP AT ct_funit.
IF ct_funit-rcap_cap1 < lc_low_limit.
CT_FUNIT-ICON = '@F1@'.
ENDIF.
ENDLOOP.


The result is something like this:



This is good for display, but one may want to use this field to exclude some orders from processing. A quick description of the scenario is to have some coded rules that, based on some configuration, puts alert icons in some orders and excludes them from the optimizer. The planners need to review manually those orders with alerts.

It would be good to be able to just lock the order in the EXIT_/SAPAPO/SAPLVS_VSGUI_005 exit, but the lock field is not available at that stage. There is one workaround I use that is good enough for the job. With exit EXIT_/SAPAPO/SAPLVS_VSGUI_005 I put some rules that set some icons for those special cases. By default any order that has an icon will be excluded from the optimizer run. That is made by having some coding to delete items in BADI /SAPAPO/VS_OPT_PREP (after starting optimization in VS01 but before sending the data to the optimizer). Something like this:


DATA: ls_orders_free TYPE /sapapo/vsr_g_funit,
ls_order TYPE /sapapo/vsr_o_i_order,
ls_ord_servicetime TYPE /sapapo/vsr_o_i_order_s_time,
ls_ord_quan TYPE /sapapo/vsr_o_i_order_quantity,
l_tabix LIKE sy-tabix.

LOOP AT it_orders_free INTO ls_orders_free.
IF NOT ls_orders_free-icon IS INITIAL.
READ TABLE ct_order INTO ls_order
WITH KEY guid = ls_orders_free-orderid.
l_tabix = sy-tabix.
IF sy-subrc = 0.
DELETE ct_order INDEX l_tabix.
ENDIF.
LOOP AT ct_ord_servicetime INTO ls_ord_servicetime
WHERE order_id = ls_order-opt_id.
l_tabix = sy-tabix.
DELETE ct_ord_servicetime INDEX l_tabix.
ENDLOOP.
LOOP AT ct_ord_quan INTO ls_ord_quan
WHERE order_id = ls_order-opt_id.
l_tabix = sy-tabix.
DELETE ct_ord_quan INDEX l_tabix.
ENDLOOP.
ENDIF.
ENDLOOP.


With this logic, if the user sees some order with an alert (with an icon) he may want to remove the icon to include the order in the optimizer run. To do that he can choose the order, then choose the "lock from the optimizer" option, and then remove the "lock from the optimizer" by clicking the button again. This has the side effect of removing the icon.

It's not 100% clean, but overall I find this a simple solution to a much demanded request. If it can be made simpler, I would be very interested in knowing :-).

PS. There are probably better ways to see the ID codes of the icons, one way is to use transaction ICON that shows all the icons and then look in debug the EXTRACT[]-ID value for the icon.

Labels: ,

5 Comments:

Blogger Ankur Gupta said...

Good work Pedro, its really amazing how you keep coming up with these small but useful things.

I was wondering if you could use this icon to may be control various other small features like "TSP not assigned" or "Resource under utilized" or may be "Flagged for change later" etc...

What do you think?

Cheers,
Ankur

6:22 AM  
Blogger pvl said...

Hello Ankur,

It always feels good to hear nice words from our peers!

I think you are right, with this trick some other interesting features can be controlled. For sure we can show icons to highlight some facts that users want to see better (and we all love a lot of color and icons :-). But with some other user-exit, like in the optimizer example, we may be able to use the user input to change the action. At least in the TSP allocation I can imagine some scenarios that could use this trick.

Bye,
Pedro

1:27 PM  
Anonymous Anonymous said...

Hi, Pedro !

On my current TP/VS project (which also happens to be the first implementation in my country ;) we were doing a modification of the shipment view in vs01 and your tip came in handy for marking a certain type of shipments. It's quite nice and visible ;)

I was wondering if you could explain a bit about MAD and material availability time for freight units, since the documentation on this topic is quite scarce.

As far as I understand this are the results of an availability check in R/3 and what I'm currently getting is that

- for STO's the material availability time is set one hour before RDT
- for SO's the MAT is exactly the same time as RDT

Obviously, this is not something we want, because you have to start loading and transporting in advance to meet RDD and RDT.

We're using the conditioning technique for scheduling and maintaining scheduling steps LOAD and UNLD

How can one approach this problem ? Reconfigure the availability check in R/3 somehow (I'm not very familiar with that, unfortunately =( or maintain some kind of parameters in APO ? Please, help, I hope this is a simple question and what take long for you to answer while this could save lot's of my time.

-- Best regards, Sam

5:48 PM  
Blogger pvl said...

Hello Sam,

From your description it seems that you are having problems in making the same ATP scheduling in STOs and sales orders. Transaction //SCHED_TEST is useful to debug those kind of problems (you probably know it already). Maybe it's the TRAN time that is different (are you using conditions or transportation lanes for the transport time?). Have you checked the APO docs on ATP scheduling?

Feel free to drop me a mail on pvl (the symbol you know) por.to. I am always interested in knowing about new TPVS projects.

Regards,
Pedro

11:22 AM  
Anonymous Anonymous said...

Thanks, I guess I'll put this aside for the moment. I'll drop you a line a bit later, when we're near the end of the project =)

12:31 PM  

Post a Comment

<< Home