A must have for TP/VS

The new note 961601, although being a customer modification, is in my opinion a must have for TP/VS implementations.

Making links to OSS notes

I added a functionality to hotoss to solve something that should be easy out-of-the-box: to make a link to the OSS note page. For example, for note 961601, if one writes http://hotoss.uatki.com/961601, clicking the link will redirect to the OSS note page (of course a OSS login will be necessary).

Music playing: Legendary Tiger Man

Announcement (although a timid one)

I have been working on making a web service for saving and organizing links to OSS notes.

Why such a service? I don't know if it is just me, but I always find the need to have fast access to some important OSS notes. Mostly those FAQ or consulting OSS notes that explain those difficult aspects of the system.

I know that I can save bookmarks in the OSS service. But I use OSS accounts related to the projects, and those change, so it is not that useful. I need something more personal.

I already tried saving the notes as text in my computer disk. This works, but it needs some effort in order to maintain things organized. Also, in order to have an overview of the information I had to write some index files. And I sometimes need to access the information from different computers (I could have a CD with the data, but then I would have to be a lot more organized than I am).

I also tried saving the note numbers in a private web page with some comments. It also works, but it needs some effort to maintain organization.

So that is why I started this HotOSS webservice. It's a lot like the social bookmarking concept of del.icio.us. Being in a OSS note page I can save OSS bookmarks with just a button click. And I can keep the bookmark with some tags and comments for later search.

And also related to social bookmarking, this service could have some community benefits. One could find interesting notes by looking at other person list of bookmarks.

Well, that's the announcement. I don't want to shout it to the world because I'm still testing and doing quality checks on the code (also open-source). But for you three readers of this blog ;-), I would really like if you could give a try to the service.

New blog posts on APO

This one on TPVS. Also on demand planning and new features of SCM 5.

It's time to put SDN again in my radar.

"Algorithm" for requirement type/check instruction determination

material Master -> MRP type
sales order -> item category
OVZI: item category, MRP type -> search strategy

if search strategy is 0 or not defined:

  material master -> material type 

  MRP group:
     1) material master -> MRP group
     2) SPRO for MRP groups: material type -> MRP group
  
  strategy group from:
     1) the material master -> strategy group
     2) OPPU: MRP group -> strategy group
 
  OPPS: strategy group -> requirement type

else if Search strategy is 1 or 2:

  OVZI: item category, MRP type -> requirement type

endif  

OVZH: requirement type -> requirement class

OVZI, OVZH, etc are transaction names.

What is the difference between strategy 1 and 2 in OVZI? If one uses strategy 2 a check is made that the requirement type is in the list of allowed req. types. That list is built with all the values of requirement types set in the planning strategies included in the planning strategy group (as from the algorithm, the planning strategy group can be defined in the material master or in the MRP group).

One other thing is tricky. Although the item category/MRP type configuration for the requirement type is done in SPRO section:

• Sales and Dist. > Basic Functions > Availability check
  

there is the need to assign the item category/MRP type to schedule line categories in section:

• Sales and Dist. > Sales > Sales Documents > Schedule lines
  

This is core SD configuration. But it's also the basic for modeling the GATP in APO.

Also check OSS 547277 point 7.

External storage location in APO

Consider this generic scenario:

A plant has an external warehouse. The products are planned and produced in the plant and after are transported to the external warehouse. Later they will be transported to the final customer (customer picks the goods or there is another transport).

For example, a specific scenario:
The plant has a warehouse in the harbor for storing materials to be included in a ship transport.

The most obvious way to model this external warehouse in APO is as a location. But then, having a location for each external warehouse has many disadvantages:

- a lot of master data must be created and maintained (if there are 10 plants, each having 10000 materials, and 10 external locations, there will be one million more location-materials in APO).

- demands would have to be created for the external warehouse, and the decision on which warehouse to use may not be available at that time.

Another way (that I'm not sure if it is a supported scenario, but seems to work well) is to model the external warehouse as a storage location of the plant. To transfer goods one has to create STOs having the same supplying and receiving plant (with the storage location address being the base for the address in the delivery). There are some gotchas with this approach:

- the address for TP/VS transport planning is not relevant, so some hacking it's needed to change the destination location for planning the transports

- if using make to stock production, something must be done to avoid the material in the external location being used for other orders

This last approach is bit hackish, but other than that it works and makes the model simpler and more flexible. In my opinion, the overhead for using a location in APO is too large and that reduces it's practical application scope.