SAP

When dealing with service contracts, the header of the contract for a quantity and for maintenance can be identical.  In fact, for service I recommend it.  That means you just need both sets item categories.  Today I want to talk about setting up the quantity contract line.  For the quantity lines, there are two main pieces.  The contract line is the first piece, but the call off line is just as important.

The contract line:

The important field is the completion rule.  I recommend C for quantity lines.

Now, in order to consume the quantity items, you need a sales order that will be created with reference to the contract.  (if you use a notification, we will talk about that in a later post).  For this, I recommend a change to the order header of the order type you will use as a call-off.

The important field is the Outline agrmnt mess.  I recommend ‘F’, this will pull up a popup at the item level automatically.  This will give you the opportunity to select a contract to link the line item to.  Please note, this will only work if you create the order in dialog.  In any other situation, the link to the contract will not be created.  In a future post I’ll talk about ways to get past this.  In the meantime, this should give you what need to get started on quantity contracts.

Thanks for reading,

 

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,

I was recently helping out in the configuration for DP80, and came to realize some limitation within the quoting mechanism.  First, let me give you the basic scenario.  I was creating a notification, then generating a service order.  The service order is then planned, and DP80 is run to create the quote.  Here are the limitation I found

1. If you need to make adjustments to the quote, you cannot just run DP80 again and get the “delta”.  The only way to requote is to either manually update the quote in VA22 or delete the existing quote, then run DP80 again (and you must manually refresh the data).  This means that capturing the original quote is impossible.
2. Upon creating the quote, it must be approved within the service order.  This isn’t a huge issue, however, if your service technicians aren’t dealing directly with the customer, it adds another layer of communication in order to get the quote approved and the allow the service order to be processed.
3. Upon accepting the quote, a debit memo is automatically created.  If you model is fixed bid, this is generally fine, but in the event that the quote changes upon further inspection, there is no way to re-quote, so it will require manual work to send a new quote to the customer for any changes.  At this point, it means that the debit memo request must be manually updated to match the manual changes in the quote (did you notice a not of manual in that???)
4. If you want to use DP80 & DP90 for the same order, be aware that you will get 2 separate debit memo requests.  DP90 cannot update the existing debit memo request generated from accepting the quote.  DP90 doesn’t recognize that document, so it generates a new DMR.  This means that you either have to manually delete/reject all line items from the existing DMR generated from the quote, or you will have a duplicate documents, one that will never be processed.  To me this is likely to become confusing if not handled properly every time.

These items are not show stoppers, but they leave room for improvement in my opinion.  Enhancements for Renovation???  Perhaps 🙂

Thanks for reading,