January 2014 - Page 2 of 2 - Paper Street Enterprises

Learning to Document

14JanJune 27, 2016

You know, for as long as I’ve been consulting, you’d think that documentation would be an easy task, but for me, it’s always come painfully. This is mostly likely due to the fact that I hate documenting things. Well I’m learning that often the things that are least interesting to do, are the most important. Documentation is one of those things (damn! :> ).

Well, that brings me to some of the things that I’ve learned that can really help your documentation. I thought I’d share some of things today.

1. Use a lot of screenshots. It sounds pretty obvious, but pictures really are a worth a 1000 words. So get yourself a good screen capture program. I personally use SnagIt, but anything that takes a screenshot, and allows you to add some arrows, text boxes etc will do the trick.

2. Take things step by step. If you really want to make sure someone knows how to do something, start at the beginning, and walk them through each little piece. As soon as skip steps, you can lose your audience, and then your documentation isn’t worth anything.

3. Use a real example. Whenever possible, use something in the system that someone can look at. For example, if it has to do with data, try to use something that is in the system that someone could look at again. Often, allowing someone to be able to look at the data on their own terms can help solidify the information. If you can’t, make sure you show your user how to look up your own data.

4. Set the stage early on. Start your documentation with a good overview. Keep in mind that someone could be reading this document (hopefully) 3, 6 or 12 months down the road. If you don’t explain what you’re doing well enough… the documentation can quickly get “foggy”, even to you if you don’t do the steps often enough.

5. A good title. This little piece of advice might actually get this read. It doesn’t matter how good the guts of your document are, if you don’t label it appropriately, no one will ever find it. This includes being able to find it in a file system, like sharepoint, put it in a location that fits, use good directory names, etc.

Those are a couple tidbits that I’ve picked up that are helping my documentation get better. Don’t get me wrong, I’m far from an expert, but I have been finding that my stuff is making more sense to me lately, so that’s a good start. ha ha

Thanks for reading,

ABAP – Changing a Namespace

13JanJune 27, 2016

Well, once you finally get to the phase of creating a namespace and making yourself a program, inevitably, things change. In my case, I joined forces with a partner, created a new company and started moving forward. So, in order to keep things keep everything consistent, I had to generate some new namespaces. The problem is that you can’t simply rename things for a new namespace, you have to copy each component to the new namespace, then delete the existing stuff. Of course, the fun comes in the sequencing.

In order to start everything, I recommend using transaction SE80. Since a namespace is generally associated with a package, the easiest way to pull everything for a particular package. This will give you everything associated with the namespace. Initially, you I suggest just copying everything. For this piece, it doesn’t matter the sequence.

Once everything is copied, now is where the fun part begins. Go back to the original namespace pull up all of the objects. Typically I go through and start with the highest level objects. This will include any programs, web dynpro objects or BSP objects. For each object, do a where used to make sure it isn’t included anything else, if the where used list is empty, then I’ll delete the item. Next I move to functions and function group. Then I’ll move onto the data dictionary objects. Starting again with the highest level tables and table types. Then move down the chain to structures and finally data types.

It’s not a simple task, and can be rather tedious… but at the end of the day, you can move from one namespace to another with very little risk, and just a little bit of time.

Thanks for reading,

Warranty Claims – Partner Setup

09JanJune 27, 2016

Well, when you start playing with warranty claims, you quickly find that it is very particular when it comes to partner setup. Your customer and vendor both need to be have some particular settings in place in order for the partner to even be used in the warranty claim. So I’m going to show you what you need to have in place.

First, let’s begin with the customer master. For any customer that you want to be a claimant, you must assign the appropriate partner type. By default, it’s AS, but like most things in SAP, you can set it to what you want.

Next up, the Reimbursing Vendor:

You need a customer (with at least Company code Data maintained) for each vendor that will be used for warranty claims processing.

Enter the corresponding customer here. the customer must be a sold-to party:

Be sure that the vendor partner is set up for the vendor master in the appropriate org.

Vendor Customer:

Be sure that Tax jurisdiction is blank if the vendor will be used across multiple company codes.
Be sure the VN partner is attached to the customer.

If you follow these simple rules, you’ll be in good shape, and will be able to attach your customer/vendor to the warranty claim. If not, expect some issues when you attempt to do your first claim.

Thanks for reading,

Warranty Claims – Configuration – Define Warranty Claim Types

08JanJune 27, 2016

This step in warranty claims it the first real piece of the puzzle when it comes to defining the different warranty claim scenarios. I will always encourage you to come to the define warranty claim types screen and create a custom claim type, and copy from the closest standard claim type. SAP does a great job of providing multiple base claim types that will likely be close to your final needs. For this coming example, I’m going to follow the postcrediting warranty claim types, and create a custom version. If you aren’t sure which option to choose, check out my post on the basics of warrany claims to gain some insight.

Now, we start at the OWTY transaction to see all the configuration pieces. We select Define Warranty Claim Types.

By default, SAP provides multiple options to start with. In fact, you might be able to use the out of the box options, but being the SAP purest, I always encourage you to create a ZXXX claim type.

So, highlight the option you want to copy, and press copy. This will bring you to the Define Warranty Claim Types detail screen.

Again, this is a busy screen. there are a lot of fields, and most of them are vital to the workings of the claim.

Start with renaming the warranty Claim type, I selected Z005 for this example, and changed the description. At this point, you can save and come back to these settings later, or update everything at once. Now, onto everything else.

Recall Claim: This sets this claim type as a recall. A recall is a special subset for warranty claims. In general, you can think of this as a defect in a product, and you want to create a bunch of claims all related to the same thing. This is a recall.
Authorization: Allows you to set this as applicable to authorization, WTYAUT transaction. In future posts, I’ll talk about the actual execution of the claim and go into transactions like these.
Partner Det.Prc: this like so many documents, allows you to set your own partner determination procedures. This is very handy to determine what partners can and should be related. Certain partners will be required no matter what, but we’ll get to those shortly.

Pricing
Pricing Schema: serves to determine specific prices for each warranty claim item and each warranty claim version and then to to post them to FI. In short, this is your pricing procedure.
Message Schema: this is your output determination procedure. Especially useful, since it’s likely you will have special documents, either printed or IDOC relevant to warranty claims.

Default Values
Reimburser Partner Role: This is a very important piece to notice here. I’ll do a post soon that talks about this more detail, but you need a specific partner type for your reimburser, and it must have some additional settings within it to allow it to be part of a warranty claim.
Partner Reimburs.: this allows you to set a default vendor or reimburser for the claim type. This is valuable if you always know who will be doing the work.
Claimant Partner Role: exactly like the Reimburser Partner Role. This is typically a customer, but this must be a specific partner type that gets assigned to the customer. I’ll go into this in a future post as well.
Sales Organization/Distribution Channel/Division/Purch organization/Plant: These are all defaults. So if your claim will only be used in a specific area, be sure to set it here. You will get the option to enter this information within each claim if you need.
Version Currency: self explanatory

Layout
The layout section is likely to be revamped as you better understand the flow of the warranty claim. You have complete control of how the screen is laid out, and you can do it with or without a navigation tree. We will discuss the Layout section in the future.
Layout of Claim w/o Nav. Tree:
Layout of Claim with Nav. Tree:
Number Header Screen Customer: When using customer exit WTY00001, a customer-specific screen area is activated in the bottom of the header data area in the warranty claim by using this screen number. The customer-specific screen area can have a maximum of two lines without a frame or one line with a frame.

Control
This section, like layout, is something you should configure your own values for. The control of the warranty claim is truly where the power resides in this technology. We’ll discuss the control section of configuration in future posts.
Action Control: set the action control profile
Start Process. Status: Based on your action control profile, you can define what status a claim should start at.
Process.Status v.fr Reimburser: Based on your action control profile, you can define what status a claim should start at.
Start Category: should the claim start with IC, OC, IV or OV
Field Name Split Criterion: If the claim can split, what field will determine how to split it.
Item Type Group: assigned to the warranty claim using the claim type. This means that only specific item types are allowed in a claim type and/or specific item types are excluded from a claim type.
Change Documents: this field I’m always a huge advocate of. In all instances, I encourage this field checked. Unless you’re really concerned with a change table, it can only benefit you to be able to see exactly how and when each change occurred.

Accounting
Document Type Customer Posting: The document type that you enter here is the document type for the warranty credit memo that is sent to the claimant. The claimant is the debtor in warranty processing. You define document types in Customizing for Warranty Processing under Accounting –> Define Document Types .
Document Type Vendor Posting: The documet type that you enter here is the document type for the warranty debit memo that is sent to the reimburser. The reimburser is the creditor in warranty processing.
Result Schema: This is for PA transfer. This is outside of my expertise, so always, talk to your FICO expert when filling in this field.
AcctDetProced: this is your account determination procedure. If you’re not sure, talk to your SD/FICO expert for guidance.

Now, that’s the define warranty claim types step in configuration. You will likely revisit this step in configuration if you following the configuration order listed in OWTY. I’ll talk about what you should configure first in the future.

Thanks fore reading 🙂

Warranty Claims – Configuration – Define Number Ranges

07JanJune 27, 2016

Now, I have to confess, doing the define number ranges step the first time was a huge pain. The way the screens are setup don’t follow the standard convention of a number range screen. For example, Change Status, or Change interval have no buttons. But I’ll show you how to navigate through this… Again, if you missed yesterday’s post, this the second step in configuring your warrant claim, at least it’s the second menu item listed. Use transaction OWTY to get to this screen.

So, when you first arrive at the screen, it looks like any other number range. The biggest difference is that there is no predefined number range interval. So before you can do anything you need to create the first number range. Here’s how you do it.

You can either press the change groups button, or use the menu Group–>Maintain.

Once you arrive at this screen, you need to use the menu Group–>Insert

On this screen, give a text/description, the to and from interval, and then press insert.

Now, you can finally do the standard task of assigning your claim type to the number range. Keep in mind, you will have to revisit this step if you create a new claim type (which I will recommend in a future post 🙂 ). So, first check the box next your number range (mine is My WC Number range). Then place you cursor on the range you wish to assign. I chose 0005 for this example, press the select button, then press the Element/Group button. If you did it correctly, you should see this:

So, that’s the trick to getting your number ranges rolling for warranty claims.

Thanks for reading,

Warranty Claims – Configuration – General Settings

06JanJune 27, 2016

I recently had a request to start talking more about warranty claims. I did a post a while back that talked that the theory behind warranty claims and what you need to consider in order to implement it. If you haven’t seen it, I encourage you to check out that post. Now assuming that you know you want to implement warranty claims, let’s get started with step 1. The general settings.

First, if you’re not familiar, the transaction OWTY is the place to go for all your warranty claims configuration needs.

So, I like to start at the beginning, so select General Settings.

Now, you’ll notice that there are a lot of fields here. So, let me begin by saying, many of these may not be needed, depending on the scenario you need to implement. The first thing to recognize is the abbreviations used within warranty claims:

IC: Inbound Claimant – this is the information coming in from the customer or whomever is requesting reimbursement or a replacement.
OV: Outbound Vendor – this is the information to send to the vendor that will do the work.
IV: Inbound Vendor – this is the information sent back to you from the vendor.
OC: Outbound Claimant – this is the information you send back to the claimaint/customer.

Ref Equipment – this can be used as the reference piece of equipment to copy from. Personally, this isn’t a feature that was useful in my projects due to the fact that the equipment records were always in existence before the claims occurred.

Calender: This is the factory calender to use when calculating deadlines.
Deadline Parts to be Returned: This is the number (in days) for the claimant to return the equipment to the vendor (or you) before the claim is no longer valid.Answer Period Reimb. Version: this only applies to a claim split. This is functionality have not used in my previous projects.

For each of the following areas you can define a different condition for each of the IC, OV, IV, OC steps.
Condition Type Part Amount – this is the pricing condition for a parts/materials amounts.
Cond. type Amnt LbrValue – this the pricing condition for the labor amounts.
Condition Type Amount – this the pricing condition for the overall amount.
Cond Type Percent Part – this is the pricing condition for parts/materials as a percentage.
Cond Type % Labor Value – this is the pricing conditon for labor as a percentage.
Condition Type Percent External – this is the pricing condition for external as a percentage.

Claim Grouping Field – this field allows you to select the way claims are grouped within the warranty tree. PARNR would be a common way to group things by customer.

So, that’s the first step in configuration. While much of this screen is extraneous for any one particular claim type, you may have multiple claim types, each for a slightly different scenario. Some dealing in percentages, some straight amounts, etc… It is recommended to set a pricing condition for each of the fields. Often times, you’ll want to make a custom ZXXX condition, to assure it goes to the appropriate account determination.

That’s our first step in Warranty Claims. I’ll be doing more posts over the coming weeks. Thanks for reading,

Web Dynpro – Editable ALV Table

02JanJune 27, 2016

Well, I’m still learning things about the Web Dynpro version of the ALV Table. In this post, I’m going to about how to make an editable ALV Table within ABAP Web Dynpro. So far, I’ve talked about how to make the table, and now it’s time for a little more advanced stuff.

Here’s some simple code to handle this aspect:

  data: l_ref_cmp_usage type ref to if_wd_component_usage.

" Instantiate the ALV usage
  l_ref_cmp_usage =   wd_This->wd_CpUse_My_Alv( ).

  if l_ref_cmp_usage->has_active_component( ) is initial.
    l_ref_cmp_usage->create_component( ).
  endif.

" Get reference to the model
  DATA: l_ref_INTERFACECONTROLLER TYPE REF TO IWCI_SALV_WD_TABLE .
  l_ref_INTERFACECONTROLLER =   wd_This->wd_CpIfc_My_Alv( ).

  data: lr_config type ref to Cl_Salv_Wd_Config_Table.

  lr_config = l_ref_INTERFACECONTROLLER->Get_Model( ).

|" Set read only mode to false (and display edit toolbar)
  lr_config->if_salv_wd_table_settings~set_read_only( abap_false ).

  data: lr_table_settings type ref to if_salv_wd_table_settings.
  lr_table_settings ?= lr_config.
  lr_table_settings->set_read_only( abap_false ).

Now, this is only the first half of the equation.  By default, every column is a text view within the table.  In order to have anything to edit, you'll need to change certain columns to be a different editor.  If you want to set something to say a checkbox, this is how you'd go about doing it.

  data: lr_column_settings TYPE REF TO if_salv_wd_column_settings,
        lt_columns         TYPE        salv_wd_t_column_ref,
        ls_columns         TYPE        salv_wd_s_column_ref,
        lr_checkbox        TYPE REF TO cl_salv_wd_uie_checkbox.

"  Embed the UI elements within the ALV
  lr_column_settings ?= lr_config.
  lt_columns = lr_column_settings->get_columns( ).
" Embed a checkbox within the column APPROVE
  LOOP AT lt_columns into ls_columns.
    CASE ls_columns-id.
      WHEN 'APPROVE'.
        CREATE OBJECT lr_checkbox1
          EXPORTING
            checked_fieldname = ls_columns-id.
        ls_columns-r_column->set_cell_editor( lr_checkbox ).
        FREE lr_checkbox.
    ENDCASE.
  ENDLOOP.

While there are a lot of ways to handle this, this is the most straightforward.  
As always, thanks for reading,