Blog

I recently had an interest in adding custom fields to a notification.  It’s been a while, so I check with my old friend google, and found a great blog on this already.  I figured I’d share that.

https://blogs.sap.com/2014/04/22/user-fields-in-pmcsqm-notifications-screen-exit-qqma0001/

I’ll be experimenting with this soon.

Thanks for reading,

I recently came across an interest challenge in SAP.  A company has both serialized products and batch managed products.  The catch is that a service contract can cover batch managed products as well as serialized products.  This is something I have never tried before, but upon inspection, standard SAP does not appear to this account.  So, from my perspective, I see 2 clear paths to handle this.

1. Add a bunch of custom code and fields to the following objects
   1. Service Contracts
   2. Service Notifications
   3. Batch records (for enhanced warranty as well)
   4. Service Orders
   5. Repair Sales orders
2. Create an equipment record for each batch

Both of these have pro’s and con’s.

Option 1 involves a lot of development work, as well as some creativity to try to leverage the service contract/warranty functionality in the SD and SM transactional data.

Option 2 doubles the amount of master data, but allows you to leverage all the standard functionality in the service realm for batches.

Is there a better way that I’m missing?  has anyone else encountered this requirement?  I would love to hear your take.

Thanks for reading,

Since I’ve recently been doing some work around maintenance plans, I thought this could be a good topic for a few blog post.

First you must setup the category for the maintenance plan.  I recommend creating a new category and then following the remainder of this section to complete all the needed configuration.

IMG->Plant Maintenance and Customer Service-> Maintenance Plans, Work Centers, Task Lists and PRTs -> Maintenance Plans -> Set Maintenance Plan Categories

Click on new entries to create your own version.

Maint. Plan cat. : This is the 2 digit category for your maintenance plan type.  It is recommended to create a different category for each major category.

Name : This is just the description of the category.

Call object : This is the type of document that will be generated by the plan.  Keep in mind, depending on your process, you may select a “softer” document like the notification to put a reminder out to the call center to contact a customer to setup an appointment.  Or you may need a “harder” document that say on Nov 15^th, a technician must be on-site to perform yearly maintenance.  This will often depend on your agreement with the customer.

Service Entry Sheet

Notification

Inspection Lot

Maintenance or Service Order

In service, the most common selections will be Notification or Service Order.

Change Documents: Do you want to collect change documents for any changes that you  make to the plan.  I’m a big fan of history, so I always encourage this to be checked.  You never know when you might need it.

Completion Data: You can use this indicator to influence the maintenance processing process. For example, you can prevent that every employee who can complete orders and notifications can also influence the scheduling of maintenance plans through the data.

With this indicator you can:

Activate a separate completion for the maintenance plan for the completion of call object notification and order.

Activate a dialog for the completion of notifications and orders using list processing.

Activate additional functionality for completing the call objects notification and order using a BAdI.

If you select the indicator completion date, you can enter a reference time that only applies to the maintenance plan, when you are completing a call object (notification or order) generated from a maintenance plan. To do this, you can also use the maintenance-plan-based fields completion date and completion time when you are completing an order or a notification.

These fields are pre-filled with the original plan date and the current time. If the current system date is displayed, then the original plan date is in the future and is replaced by the system date.

This is functionality I have not used in the past.

Outline Agreement:  Should this be created with reference to an outline agreement.  If you want to create a plan with reference to a service contract, this must be checked.

Ref Obj: This defines the type of object that the plan will “work” on.

O100   Functional location+equipment+assembly

O110   Equipment + assembly

O120   Functional location(30)+equipment+assbly

O130   Serial number+material number+device ID

O140   Without reference object

O150   Equipment only

O160   Functional location only

O170   Equipment + Serial No. + Material No.

O180   Functional loc. 1:1 + equip. + assembly

O190   Physical sample

You might recognize this list from the notification defaults.  I tend to always select O170.

Something interesting to take note of.  In my ECC 6.0 EHP4 system, in transaction IP50, the last category with the Outline agreement checked does NOT show up.  In my EHP7 system, this doesn’t happen.  I could not find anything in OSS that directly corrects this.  A workaround would be to create an addition plan 00 or ZZ or something with the description of do not use.  Then the previously created plan should show up just fine.

Thanks for reading,

Well, after I did the initial implementation, I found there were a few things missing.  So I wanted to document those right now, to make it clear what needs to happen.

First, in order to make the entry screen function properly, you need to update the transactions allowed with the equipment record.  You can do that by going to transaction: VFBS

Enter in program: SAPMIEQ0

Select Function codes.

Find the entry for ENT1 and copy it.  Change ENT1 to 19 and Save.

Within the same transaction, go to T185 (the second radial button) for the same program.

Find the entry for ENT1 again and copy it.  Change ENT1 to 19 in the first FCode column.  Leave everything else the same.

This will get rid of the error that the function doesn’t exist.

This got me to a working screen, but when I saved it, it never wrote the entries back to BGMKOBJ.  So I did some more digging.

In CMOD for the user exit, you need to change the code to be:

e_subscreen_number = ‘1000’.
CALL FUNCTION ‘WTY20_OBJNR_SET’
EXPORTING
IV_OBJNR         = i_data_equi–objnr.

 

Next, in the Badi:  change the code to be:

field-symbols:<bgmkobj_new> TYPE wty_bgmkobj_tab,
<bgmkobj_old> TYPE table.
ASSIGN (‘(SAPLWTY20)gt_bgmkobj_new’) TO <bgmkobj_new>.
check sy–subrc = 0.
ASSIGN (‘(SAPLWTY20)gt_bgmkobj_old2’) TO <bgmkobj_old>.
check sy–subrc = 0.
CALL FUNCTION ‘WTY20_DB_UPDATE_BGMKOBJ2’
EXPORTING
i_data_equi    = i_data_equi
it_bgmkobj_new = <bgmkobj_new>
it_bgmkobj_old = <bgmkobj_old>.
unassign:<bgmkobj_new>, <bgmkobj_old>.

Once you make these updates, you will have multiple master warranties for a singe equipment record.  Pretty slick.  Now my next mission is to figure out how to make use of these entries within the service notification.  More to come soon.

Thanks for reading,

Well, a new friend of mine recently told me about some functionality I had never heard of.  He explained that you could assign multiple master warranties to a single equipment record.  Initially, I wondered why you would ever want to do this.  Well, it turns out that if you do it correctly, it can be a pretty slick method to allow different warranties to apply to a single piece of equipment.  For example, you could have standard warranty, an extended warranty, a warranty that allows diagnostic visits, and they can all have their own start and end dates.

Needless to say, I had to see this for myself.  So, I found a really good post that walked me through, step by step how to implement it.

Check it out here.

Couple things I’ll add to that post.  First, if you need to create a BADI implementation, use transaction SE19.

Second, there is a little gotcha that isn’t mentioned.  You can only assign a warranty type once to a piece of equipment.  So, in the standard system, you have customer and vendor.  But if you need multiple different customer master warranties, the way the backend tables are structured you must define different warranty types in order to assign multiple.  So you might have A = initial warranty period, B = extended warranty, C = Diagnostic, D = replacement, E = On-site visits, etc…

I’m still playing with this, and need to see how the standard warranty check handles this.  Obviously, I’m curious if this might be another place to enhance the JaveLLin products 🙂

Thanks for reading,