Variant Functions for PP Routings

Hello,
is it possible with the "Variant Functions" to call in a super routing a FM to get some values from a ZTABLE to use this values
in the object dependency syntax to changes values in the routing?
kind regards,
Bernhard

Dear,
In order to grab sales order to the formula for work center selection or value you have to use another characteristic with a reference tables assigned to it. You are correct,  you will need another Characteristic, which is called a reference characteristic with "Not Ready for Input',. Go to the Additional Data Tab for that Characteristic and you can then specify the Table Name as VBAP and then enter in the Proper Field Name for the Quantity from VBAP.
Characteristic Value based upon your Reference Characteristic. Also, the possibility of a Variant Function to set the Value of a Characteristic to sy-unam.
Please try and come back.
Regards,
R.Brahmankar

Similar Messages

  • Variants functionality for a custom made report

    Hello everybody,
    i want to integrate the variant functionality we all know from reports in a custom made report (Dynpro). Is there any kinda generic functionality available you can hook up with? Like FMs or something?
    best regards,
    Markus

    Hello,
    maybe i should start from the very beginning. I am developing an application/report which has besides standard input fields a table (editable Grid Control) as selection fields.
    I started off using the selection-screen functionality and integrated the Grid Control as a subscreen. Working great. But as it come to developing the functionaility "variant saving" i went into a problem. The standard input field were covered by the SAP standard functionalities, but not the table (grid control).
    What i managed to implement using the possibility of custom code at the standard events AT SELECTION-SCREEN and AT SELECTION-SCREEN OUTPUT was when you click on the save button in a report to save my table content in a own database table with the link to the name of the standard variant. (Systemfield VARI hold the data). I even was able to load my saved table data, when loading a variant. This worked only on the first run (event initialization), as clicking on the load variant button in a report does NOT give me any return-code, like pressing the save button. It just raises the event PBO, as does pressing the enter button. So my problem is, i do not have the info at runtime, whether someone has pressed the load variant button and selected a variant or whether someone just pressed the return key, both do invoke PBO and i cant tell the difference.
    So i had the idea of instead of using a report, developing a own dynpro application (Module pool).
    best regards,
    Markus

  • FM call from Variant Function in JAVA SCE

    Hello,
    I have an issue with Variant Configuration in CRM WEB UI / WebShops.
    We have created a variant function in ECC to read/pull a customer master value (KNVV table).  This is working fine in ECC & got the desired result.
    Now we need replicate the same in CRM. For this we need to create KB, Version & write a variant function in Java class in SCE. In that variant function we need to call a function module and get the customer master / Business partner value as similar to ECC process described above.
    But we see that the SAP standard is not supporting FM calls from VF in Java. i.e. we are unable to call the JCO call to a CRM function module from SCE.  The package for User defined classes "com.sap.sce.user" and the method inside it public boolean execute(fn_args args, Object obj) { ..... } has no option to make a FM call.
    Has anyone faced the similar requirement and has any resolution for this? 
    Thanks,
    Surya.

    Hi Eric,
    You sound quite familiar with the variant functions. I am also working on IPC-SCE
    variant functions for few years now.
    We have a situation where I am building some debug logs in one java variant function and want to display it to the web UI at some condition.
    Is there any object(like context etc.) that IPC server-side and Webapps share?
    I can write that log to a text file and read it from web ui ... but I wanna avoid that.
    Is there any other way you know of???
    Regards,
    Ruchika

  • Variant functions in CRM

    hi all,
    i want to know how to implement variant functions for CRM
    please help me
    Thanks and Regards
    shanto aloor

    1.Can we write new functions or we have to modify the existing one?
    You will write the Java functions based on the custom VC functions in the R/3 system. You will closely work with the R/3 Variant Configuration team and get the details of the custom functions that are developed in the design time VC model for supporting their runtime VC. This runtime environment is not available in CRM. Only the design time information is downloaded as knowledgebase.
    Hint:
    SAP provides the Java code for all the standard VC functions in R/3.
    In R/3 see function group CUPR for the standard VC functions)
    In R/3 one uses transactions
    cu65,
    cu66 and
    cu67
    to maintain the interface definition of custom  variant functions. Here they desgin and develop
    FUNCTION - read access to the KB and
    PFUNCTION - read and write access to configuration and more.
    You will actively work with your R/3 VC team to get the full design details of these functions.
    2.how our custome functions are linking to SAP ,means if we create java user exit we will register that by giving full path of the class and finally we use that in pricing procedure or somewhere. Is there any these type of procedures are needed for VC?
    Variant Configuration is the other face of the IPC and should not be confused with any of the pricing features of IPC. The SCE ( configuration engine) deals with the configurable products. The design time confguration of configurable products are downloaded as kowledgebase in R/3.
    Since the design time (KB) is available to IPC, during runtime the reference to pfunctions and functions are known to IPC and IPC by design will look for the instances for the classes for these Variant functions.

  • Java User Exit for Variant Function logic in CRM

    Hello Experts,
    We have implemented Variant configuration in ECC with some variant functions / function modules.  Now we have to implement the corresponding Java class in CRM for the knowledge base & version to work. 
    Can anyone help me out to find the correct userexit where I need to implement this Java class consisting the variant function logic.
    Thank You
    Satish

    I don't have any CRM system at hand, but I'm sure there are some BAdI's for this. Look in SE18 for BP or BUS, and i'm sure  you will find something.
    One suggestion though: Before going for the BadI, try and see if CRM also uses change pointers for sending Idoc's . This case you wont need any user exits / badis, an probably no programming at all.
    Transaction
    BD50: Activate Change Ptrs for Mess. Type
    BD61: Activate Change Pointers - Generally
    and use report RBDMIDOC for triggering IDoc.

  • "transaction variant" functionality in the Web Client

    I'm opening this message for a customer this message is a consulting...
    Thanks in advance,
    Daniel Kaoro Kobashigawa
    In the SAP GUI we have Transactions that use transaction variants. For example we have ZBUP1A that is based upon BUP1. It uses a transaction variant to default certain important fields like "Grouping" "BP Type" etc. so BP are created correctly.
    We are in the process of CRM 2007 upgrade from CRM 5.0 and plan to use CRM WebClient UI for all user transactions.
    1. Can we put to use the same Transaction variants for the CRM WebClient UI without using the Transaction Launcher to call the GUI transactions (as SAP does-not recommend the use of SAP GUI Transactions except for
    administrative related functions)? If so is it just configuration?
    2. If we cannot use the Transaction variants for the CRM WebClient UI, is there a way to pass parameters to the standard transactions by making modifications to the logical links provided in the Navigation Bar? If so, please elaborate.

    Discarded question

  • Functionality for Select and Save layout in a report output

    Hi,
    I had developed a report program containing several fields in the output and requires the Functionality for Select layout and Save layout in a report output.
    Please suggest.
    Thanks,
    Shariq.

    While calling the FM for List Display ( "REUSE_ALV_LIST_DISPLAY" or "REUSE_ALV_GRID_DISPLAY" ) set the Parameter I_SAVE for Setting the Layout and Selecting a different Layouts.
    The possible values for I_SAVE are "A", "U", "X" or others. Depending on the requiement you can set different values for the Parameter I_SAVE.
    ' ' = display variants cannot be saved
    Defined display variants (e.g. delivered display variants) can be selected for presentation independently of this flag.
    Changes can not be saved.
    'X' = standard save
    Display variants can be saved as standard display variants.
    User-specific saving is not possible.
    'U' = only user-specific saving
    The user can only save display variants user-specifically
    'A' = standard and user-specific saving
    The user can save a display variant user-specifically and
    as standard display variant. The user chooses in the display variant
    save popup.
    Reward points if helpful.

  • Suggest book on SAP HR Functional for beginners

    Dear All,
    Request you to suggest me a book for SAP HR Functional
    for beginners.
    Thanks in advance for the help.
    Regards,
    Taranjit

    Benefit Administration:
    This section of the Implementation Guide (IMG) is where you set the SAP Benefits Administration component.
    Here you enter in the system all the details of the benefit plans offered by your company.
    Benefit Area:
    Benefit areas allow you to have separate administration of different benefit plan pools. This division is primarily for administrational purposes and would not normally be used for eligibility
    IMG Path: Personnel Management  Benefits  Basic Settings  Define Benefit Area
    Assign Currency to Benefit Area:
    In this step, you specify the currency for the benefit area
    IMG Path: Personnel Management  Benefits  Basic Settings  Assign Currency
    this step, you enter the providers of the benefit plans you offer.
    This could be the Insurance company, or Health Maintenance Organization that receives the benefit plan costs
    IMG Path: Personnel Management  Benefits  Basic Settings  Define Benefit Providers
    In this step, you set relevant benefit area for your Customizing activities
    If you have more than one benefit area to set up, you must set up each independently. After you have set up all the plans in one area, you must return to this view, set the next current benefit area and work through the IMG again, setting up the new benefit area.
    IMG Path: Personnel Management  Benefits  Basic Settings  Set Current Benefit Area
    Benefit Plan Types:
    In this step, you enter the benefit plan types that you require for the plan categories predefined in the system.
    The following plan categories are provided by MSD:
    • Health Plans
    o Medical
    o Dental
    o Vision
    • Insurance Plans
    o Basic Life
    o Supplemental Life
    o Accidental Death & Dismember
    • Savings Plans
    o 403B
    o 457
    o PERS (Public Employees retirement Scheme for CP Benefit Plan) & TRS
    (Teachers Retirement Scheme for TP Benefit Plan)
    • Flexible Spending Accounts
    o Health care
    o Dependent care
    IMG Path: Personnel Management  Benefits  Basic Settings  Plan Attributes  Define Benefit Plan Types
    Define Benefit Plan Status:
    It is important that you assigning statuses in order to be able to control the availability of plans with a minimum of effort. For example, you can control whether or not employees can enroll in a plan simply by changing its status
    IMG Path: Personnel Management  Benefits  Basic Settings  Plan Attributes  Define Benefit Plan Status
    Benefit Plan Status:
    In this step, you define parameter groups. You decide which groups you require in two stages:
    1. You consider which costs, credits, coverage and employee and employer contributions for your plans vary according to the age, salary and/or seniority of employees (or possibly the age of the employee's spouse).
    2. You determine the different ways in which you need to divide your employees according to different value ranges for these criteria.
    It is not possible to define overlaps of ranges for a criterion within a single parameter group. Therefore, if you require different employee groupings for different plans, you need to create a separate parameter group.
    For each unique combination of criteria and their values, you need to define a parameter group.
    In this step, you simply create the parameter groups to which you assign groups for the individual criteria in the following steps. You later refer to the parameter groups, where applicable, in the individual rule variants for plans. Since one parameter group can be referenced by multiple plans, Customizing effort is kept to a minimum. In the plan variant, you also have the flexibility of being able to specify that you only want to use certain criteria values belonging to a parameter group, for example, age ranges
    IMG Path: Personnel Management  Benefits  Basic Settings  Define Employee Groupings  Define Employee Criteria Groups  Define Parameter Groups
    Age Groups:
    In this step, you define the age groups for the parameter groups that you defined in a previous step.
    Depending on your needs, you may find for some parameter groups, you can leave out this step, if for example there is no requirement to differentiate between employees based on age
    IMG Path: Personnel Management  Benefits  Basic Settings  Define Employee Groupings  Define Employee Criteria Groups  Define Age Groups
    Age Groups under Parameter grouping “PAR1”
    Cost Groupings:
    In the parameter group you could differentiate between employees based upon age, salary and seniority. Here you can further differentiate between employees, based on other employee criteria, such as geographical location, job classification, marital status and so on. Only set up this feature, if you find that the parameter group does not adequately cover your needs, when specifying costs for different groups of employees
    IMG Path: Personnel Management  Benefits  Basic Settings  Define Employee Groupings  Define Cost Groupings
    Coverage Groupings:
    In the parameter group you could differentiate between employees based upon age, salary and seniority. Here you can further differentiate between employees, based on other employee criteria, such as geographical location, employment contract, residence status and so on. Only set up this feature, if you find that the parameter group does not adequately cover your needs, when specifying coverage for different groups of employees
    IMG Path: Personnel Management  Benefits  Basic Settings  Define Employee Groupings  Define Coverage Groupings
    Employee Contribution Groupings:
    In the parameter group you could differentiate between employees based upon age, salary and seniority. Here you can further differentiate between employees, based on other employee criteria, such as geographical location, weekly hours, residence status and so on. Only set up this feature, if you find that the parameter group does not adequately cover your needs, when specifying employee contribution for different groups of employees
    IMG Path: Personnel Management  Benefits  Basic Settings  Define Employee Groupings  Define Employee Contribution Groupings
    the parameter group you could differentiate between employees based upon age, salary and seniority. Here you can further differentiate between employees, based on other employee criteria, such as geographical location, weekly hours, residence status and so on. Only set up this feature, if you find that the parameter group does not adequately cover your needs, when specifying employee contribution for different groups of employees
    IMG Path: Personnel Management  Benefits  Basic Settings  Define Employee Groupings  Define Employer Contribution Groupings
    the parameter group you could differentiate between employees based upon age, salary and seniority. Here you can further differentiate between employees, based on other employee criteria, such as geographical location, weekly hours, residence status and so on. Only set up this feature, if you find that the parameter group does not adequately cover your needs, when specifying employee contribution for different groups of employees
    IMG Path: Personnel Management  Benefits  Plans  Health Plans  Define Employer Contribution Groupings
    the parameter group you could differentiate between employees based upon age, salary and seniority. Here you can further differentiate between employees, based on other employee criteria, such as geographical location, weekly hours, residence status and so on. Only set up this feature, if you find that the parameter group does not adequately cover your needs, when specifying employee contribution for different groups of employees
    IMG Path: Personnel Management  Benefits  Plans  Health Plans  Define Options for Health Plans
    Dependent Coverage Options:
    In this step, you define the dependent coverage that are used in health plans.
    Define all possible variations that you need, because this view is not specific to any plan or plan option
    IMG Path: Personnel Management  Benefits  Plans  Health Plans  Define Dependent Coverage Options
    Number of Dependents:
    In this step, you can restrict participation in a health plan under a dependent coverage option to certain types of dependent, as determined by the subtypes of the Family/Related Persons infotype (0021). You can also define a minimum and maximum number of persons of a particular type that can be covered. During enrollment, the system only includes those dependent coverage options in the benefit offer for which the appropriate dependents are available
    IMG Path: Personnel Management  Benefits  Plans  Health Plans  Define Minimum and Maximum Number of Dependents
    Define Cost Variants:
    In this step you define cost variants to determine which factors influence the cost of a health plan for an employee. Variants are plan-specific; each plan has its own variant(s).
    You do not enter any actual costs in this step. You simply define how costs vary according to:
    • Plan
    • Option
    • Dependent coverage
    • Employee data
    Before you start to define cost variants, you need to do the following:
    1. Determine how often costs vary for all the combinations of option and dependent coverage that you have defined in each plan.
    This indicates how many cost variants you need. You can use the same cost variant more than once, for example, if costs are always identical for the dependent coverages 'employee only' and 'employee plus family' within a plan, regardless of the plan option
    2. Determine how costs vary according to employee data.
    This determines how you need to set up your variants using employee groupings.
    For each variant, you can specify a parameter group and cost grouping to determine cost. You can also indicate whether the gender of employees and whether or not they are smokers are cost criteria
    IMG Path: Personnel Management  Benefits  Plans  Health Plans  Define Cost Variants
    Cost Rules:
    You need to define costs for each possible combination of employee grouping in the criteria you have attributed to each variant. If you have not specified any criteria in a variant, you assign one rule only
    IMG Path: Personnel Management  Benefits  Plans  Health Plans  Define Cost Rule
    Health Plan Attributes:
    In this step, you bring together all the definitions relevant to the health plan that you have made in the previous steps.
    You assign to each health plan:
    • Its options
    • Relevant dependent coverages
    • The cost variants for the combination of options and dependent coverages
    IMG Path: Personnel Management  Benefits  Plans  Health Plans  Assign Health Plan Attributes
    Insurance Plans:
    In this step, you define general data for insurance plans
    IMG Path: Personnel Management  Benefits  Plans  Insurance Plans  Define Insurance Plan General Data
    Coverage Variants:
    In this step, you define coverage variants to determined which factors influence the coverage an employee is entitled to in a plan. Variants are plan-specific; each plan has its own variant(s).
    You do not enter any actual coverage in this step. You simply define how coverage varies according to:
    • Plan
    • Coverage option
    • Employee data
    Before you start to define coverage variants, you need to do the following:
    1. Determine how often coverage varies for different coverage options.
    This indicates how many coverage variants you need. Note the following:
    • If a plan has set coverages (including salary multiples), you need a
    coverage variant for each.
    • If a plan allows employees to choose any amount of coverage within a
    range, you need only one coverage variant.
    • If a plan has options, you will need a coverage variant for each option.
    2. Determine how coverage varies according to employee data.
    This determines how you need to set up your variants using employee groupings. For each variant, you can specify a parameter group and coverage grouping to determine coverage
    IMG Path: Personnel Management  Benefits  Plans  Insurance Plans 
    Coverage Rules:
    In this step, you define the actual coverages for a plan.
    You need to define coverage for each possible combination of employee grouping in the criteria you have attributed to each variant. If you have not specified any criteria in a variant, you assign one rule only.
    Coverage can be defined as a flat amount or as a factor of salary
    IMG Path: Personnel Management  Benefits  Plans  Insurance Plans  Define Coverage Rules
    Cost Variants:
    In this step you define cost variants to determine which factors influence the cost of an insurance plan for an employee. Variants are plan-specific; each plan has its own variant(s).
    You do not enter any actual costs in this step. You simply define how costs vary according to:
    • Plan
    • Coverage option
    • Employee data
    Before you start to define cost variants, you need to do the following:
    1. Determine how often cost varies for different coverage options:
    • If an insurance plan has set flat coverage options and flat costs, you need
    to define a cost variant for each flat cost.
    • If you have set flat coverage options and the flat costs are directly
    proportional to the coverage stated in the flat cost, you need only one
    cost variant.
    • If an employee can choose any amount of coverage within a range and the
    cost of the coverage is directly proportional to the coverage, you need
    only one cost variant.
    2. Determine how costs vary according to employee data.
    This determines how you need to set up your variants using employee groupings.
    For each variant, you can specify a parameter group and cost grouping to determine cost. You can also indicate whether the gender of employees and whether or not they are smokers are cost criteria
    IMG Path: Personnel Management  Benefits  Plans  Insurance Plans  Define Cost Variants
    Cost Rules:
    You need to define costs for each possible combination of employee grouping in the criteria you have attributed to each variant. If you have not specified any criteria in a variant, you assign one rule only
    IMG Path: Personnel Management  Benefits  Plans  Insurance Plans  Define Cost Rules
    Insurance Plan Attributes:
    In this step, you bring together all those parts of an insurance plan, that you have already defined in the previous few steps.
    You define the insurance plan options, then associate to each insurance plan:
    • Cost variant
    • Coverage variant
    IMG Path: Personnel Management  Benefits  Plans  Insurance Plans  Assign Insurance Plan Attributes
    Combined Coverage Limits:
    When you define coverages for plans such as insurance, you can set limits on the coverage amount. This is often used when the coverage is an amount dynamically calculated when the employee chooses her coverage.
    However these limits apply only to one plan and yet you might need to define limits which combine the coverages of more than one plan.
    In this chapter, you define these combined limits as follows:
    1. The limit that might span 2 or more plans is reduced to a mathematical equation, where there is an amount on one side and plan coverages on the other side. The two sides of this equation are then DIVIDED BETWEEN the two views in this chapter.
    2. The first view defines the limit in monetary terms which is one side of the equation. It also defines the operator (equals, is greater than, and so on).
    3. The second view defines the other side of the equation in terms of the plan coverages
    IMG Path: Personnel Management  Benefits  Plans  Insurance Plans  Combined Coverage  Combined Coverage
    Combined Coverage Limit Expressions:
    In this step, you enter the second half of the equation, as discussed in combined coverage
    IMG Path: Personnel Management  Benefits  Plans  Insurance Plans  Combined Coverage  Define Combined Coverage Limit Expressions
    Imputed Income for Selected Benefits:
    In this section of the IMG, you define the criteria needed to calculate Imputed Income.
    Imputed Income is based upon benefits paid for by the employer and calculated using rates set by the Internal Revenue Service (IRS). This value is then treated as taxable income for the employee
    IMG Path: Personnel Management  Benefits  Plans  Insurance Plans  Combined Coverage  Review Age Groups for Imputed Income
    Review Calculation Factors for Imputed Income:
    In this step, you check that the Imputed Income Rate Table entries are correct.
    The imputed income age groups are associated with the rates/factors set by the IRS
    IMG Path: Personnel Management  Benefits  Plans  Insurance Plans  Combined Coverage  Review Calculation Factors for Imputed Income
    Savings Plans:
    In this step, you define general data for savings plans.
    You have defined the relevant type, status, and provider for each plan in the Basic Settings section of the Benefits IMG
    IMG Path: Personnel Management  Benefits  Plans  Savings Plans  Define Savings Plan General Data
    Employee Contribution Variants:
    In this step you define employee contribution variants to determine which factors influence the permitted employee contribution to a plan. Variants are plan-specific; each plan has its own variant(s).
    You do not enter any actual contributions in this step. You simply define how contributions vary according to:
    • Plan
    • Option (only for plans in the plan category Miscellaneous)
    • Employee data
    Before you start to define variants, you need to do the following:
    1. Determine how often employee contributions vary for plans and any plan options.
    This indicates how many contribution variants you need.
    2. Determine how employee contributions vary according to employee data.
    This determines how you need to set up your variants using employee groupings.
    For each variant, you can specify a parameter group and employee contribution grouping to determine employee contribution
    IMG Path: Personnel Management  Benefits  Plans  Savings Plans  Define Employee Contribution Variants
    Employee Contribution Rules:
    In this step, you define the employee contribution limits for each plan.
    You need to define employee contributions limits for each possible combination of employee grouping in the criteria you have attributed to each variant. If you have not specified any criteria in a variant, you assign one rule only.
    You can define minimum and maximum employee contribution in the following ways:
    • As a fixed amount
    • As a percentage of salary
    • As a contribution unit
    In Payroll, the total employee contribution is the sum of these amounts
    IMG Path: Personnel Management  Benefits  Plans  Savings Plans  Define Employee Contribution Rules
    Employer Contribution Variants:
    In this step you define employer contribution variants to determine which factors influence the contribution the employer makes to a plan. Variants are plan-specific; each plan has its own variant(s).
    You do not enter any actual contribution in this step. You only define how contributions vary according to:
    • Plan
    • Option (only for plans in the plan category Miscellaneous)
    • Employee data
    Before you start to define variants, you need to do the following:
    1. Determine how often employee contributions vary for plans and any plan options.
    This indicates how many contribution variants you need.
    2. Determine how employee contributions vary according to employee data.
    This determines how you need to set up your variants using employee groupings.
    For each variant, you can specify a parameter group and employer contribution grouping to determine employer contribution
    IMG Path: Personnel Management  Benefits  Plans  Savings Plans  Define Employer Contribution Variants
    Employer Contribution Rules:
    In this step, you define limits for the contributions made by the employer to employee plans. You so this for each employer contribution variant for each plan.
    You need to define employer contributions limits for each possible combination of employee grouping in the criteria you have attributed to each variant. If you have not specified any criteria in a variant, you assign one rule only.
    You can define the employer contribution and the contribution limit in either of the following ways:
    • As a fixed amount / as an amount per unit contributed by the employee
    • As a percentage of employee base salary or employee contribution
    IMG Path: Personnel Management  Benefits  Plans  Savings Plans  Define Employer Contribution Rules
    Assign Savings Plan Attributes:
    In this step, you complete the definition of savings plans by bringing together the relevant elements that you have already defined:
    • EE contribution variant
    • ER contribution variant
    IMG Path: Personnel Management  Benefits  Plans  Savings Plans  Assign Savings Plan Attributes
    Flexible Spending Accounts (FSAs):
    In this step, you define general data for flexible spending accounts (FSAs).
    Requirements
    You have created the appropriate plan type , plan status, and benefit provider in the preceding steps
    IMG Path: Personnel Management  Benefits  Plans  Flexible Spending Accounts (FSAs)  Define Spending Account General Data
    Assign Spending Account Attributes:
    In this step, you enter the details of your flexible spending accounts including contribution limits, an employer contribution variant (if required), and rules for the reimbursement of claims
    IMG Path: Personnel Management  Benefits  Plans  Flexible Spending Accounts (FSAs)  Assign Spending Account Attributes
    Flexible Administration:
    In this chapter, you define the flexible aspects of your Benefits administration. You define the availability of plans to your employees, in terms of the plans themselves. You also define aspects of the enrollment process.
    you enter parameters that apply to processing within an entire benefits area, including:
    • Open enrollment period dates
    • Default validity dates for adjustment/standard plan records
    • Advance availability of future plans
    • Dependent age limits
    IMG Path: Personnel Management  Benefits  Flexible Administration  Define Administrative Parameters
    Benefit Adjustment Groupings:
    In this step, you define adjustment groupings. These groupings allow you to specify different adjustment permissions for different groups of employees
    IMG Path: Personnel Management  Benefits  Flexible Administration  Benefits Adjustment Reasons  Define Benefit Adjustment Groupings
    Benefit Adjustment Reasons:
    In this step, you define adjustment reasons to control changes to employee enrollments according to company policy.
    The adjustment reason types that you define here are assigned as subtypes of Adjustment Reasons records (infotype 0378) in HR Master Data. Since a record can only have one subtype, a new record must be created for every adjustment reason an employee experiences.
    According to the adjustment concept, an employee can only make changes to her enrollments if she has an Adjustment Reasons record (infotype 0378) with the required adjustment reason as a subtype. The only exceptions to this are if changes are made during an open enrollment period or if an anytime adjustment reason is assigned to the plan type.
    In addition to defining adjustment reasons for certain events that can trigger changes, you may also want to define a special adjustment reason to allow changes to plans at any time
    IMG Path: Personnel Management  Benefits  Flexible Administration  Benefits Adjustment Reasons  Define Benefit Adjustment Reasons
    Adjustment Permissions:
    In this section, you assign adjustment permissions to each benefit plan type for an adjustment reason and any adjustment grouping that you have defined.
    Note that the elements for which you can define permissions are automatically determined by the system, dependent on the plan category
    Health Plans:
    In this step, you define the changes permitted for all plans of this type. You do this for each combination of adjustment reason, adjustment grouping, and plan type
    IMG Path: Personnel Management  Benefits  Flexible Administration  Benefits Adjustment Reasons  Define Adjustment Permissions  Health Plans
    this step, you define the changes permitted for all plans of this type. You do this for each combination of adjustment reason, adjustment grouping, and plan type
    IMG Path: Personnel Management  Benefits  Flexible Administration  Benefits Adjustment Reasons  Define Adjustment Permissions  Insurance Plans
    Savings Plans:
    In this step, you define the changes permitted for all plans of this type. You do this for each combination of adjustment reason, adjustment grouping, and plan type
    IMG Path: Personnel Management  Benefits  Flexible Administration  Benefits Adjustment Reasons  Define Adjustment Permissions  Savings Plans
    Spending Accounts:
    In this step, you define the changes permitted for all plans of this type. You do this for each combination of adjustment reason, adjustment grouping, and plan type
    IMG Path: Personnel Management  Benefits  Flexible Administration  Benefits Adjustment Reasons  Define Adjustment Permissions  Spending Account
    Programs:
    In this section of the IMG, you define benefit programs and the eligibility restrictions and termination conditions for the plans within these programs.
    Within a program, eligibility for plans can be determined on two levels:
    • Program groupings control eligibility on a high level (macro-eligibility) by allocating an employee a defined program, depending on his/her organizational and employment data.
    • Eligibility rules are optional and control eligibility on a low level (micro-eligibility) by determining whether an employee can participate in a plan within the relevant program. An employee must fulfill the conditions defined in the rule in order to be able to enroll. Eligibility rules are assigned to plans in programs by means of an eligibility variant.
    First Program Grouping:
    In this step, you define first program groupings. Later, you define programs for a combination of first and second program groupings.
    Identical attributes are available for the setup of both the first and second program groupings, and they are therefore interchangeable. The fact that you determine macro-eligibility for a program using two dimensions means that you are able to make finer distinctions between groups of employees
    IMG Path: Personnel Management  Benefits  Flexible Administration  Programs  Define First Program Grouping
    Second Program Grouping:
    In this step, you define second program groupings. Later, you define programs for a combination of first and second program groupings.
    Identical attributes are available for the setup of both the first and second program groupings, and they are therefore interchangeable. The fact that you determine macro-eligibility for a program using two dimensions means that you are able to make finer distinctions between groups of employees
    IMG Path: Personnel Management  Benefits  Flexible Administration  Programs  Define Second Program Grouping
    Employee Eligibility:
    In this section of the IMG, you define the criteria according to which you control eligibility for individual benefit plans within a benefits program (definition of micro-eligibility). You perform the following steps to set up eligiblity requirements:
    • You define eligibility grouping to identify groups of employees for whom
    certain eligibility criteria apply.
    • You create eligibility variants, which you later use to link eligibility
    rules to programs.
    • If necessary, you define dynamic eligibility conditions relating
    specifically to actual hours worked/length of service, or zip codes.
    • You bring your definitions together in the eligibility rule, where you
    can also specify further conditions for enrollment.
    IMG Path: Personnel Management  Benefits  Flexible Administration  Programs  Employee Eligibility  Define Eligibility Groupings
    Eligibility Variants:
    In this step, you define eligibility variants. These consist simply of an identifier and a description
    IMG Path: Personnel Management  Benefits  Flexible Administration  Programs  Employee Eligibility  Define Eligibility Variants
    Eligibility Rules:
    In this step, you define eligibility rules for the benefit plans offered by your organization. You define these rules for combinations of eligibility grouping and eligibility variant, thereby determining the eligibility conditions that will apply for different groups of employees
    IMG Path: Personnel Management  Benefits  Flexible Administration  Programs  Employee Eligibility  Define Eligibility Rules
    Participation Termination:
    In this section of the implementation guide you define criteria for the termination of benefit plans
    Termination Groupings:
    In this section of the implementation guide you define criteria for the termination of benefit plans
    IMG Path: Personnel Management  Benefits  Flexible Administration  Programs  Participation Termination  Define Termination Groupings
    Termination Variants:
    In this step, you define termination variants. These consist simply of an identifier and a description
    IMG Path: Personnel Management  Benefits  Flexible Administration  Programs  Participation Termination  Define Termination Variants
    Termination Rules:
    In this step, you define termination rules. You define these rules for every combination of termination grouping and termination variant, thereby determining the coverage continuation periods and termination day that will apply for different groups of employees
    IMG Path: Personnel Management  Benefits  Flexible Administration  Programs  Participation Termination  Define Termination Rules
    Define Benefit Programs:
    In this step, you define termination rules. You define these rules for every combination of termination grouping and termination variant, thereby determining the coverage continuation periods and termination day that will apply for different groups of employees
    IMG Path: Personnel Management  Benefits  Flexible Administration  Programs  Define Benefit Programs
    Dependent/Beneficiary Eligibility:
    In this step, you define family member groupings and determine how family members are allocated to these groupings
    IMG Path: Personnel Management  Benefits  Flexible Administration  Dependent/Beneficiary Eligibility  Define Family Member Groupings
    Dependent Eligibility Rule Variants:
    In this step, you define the dependent eligibility variants to which you want to assign dependent eligibility rules. You also specify whether you wish to use a family member grouping in the associated eligibility rule to restrict eligibility to types of family members with certain characteristics
    IMG Path: Personnel Management  Benefits  Flexible Administration  Dependent/Beneficiary Eligibility  Define Dependent Eligibility Rule Variants
    Dependent Eligibility Rules:
    In this step, you define dependent eligibility rules to determine which types of family member are eligible as dependents. You then assign your rules to the appropriate plans by means of a rule variant in the step Assign Eligibility Rule Variant to Plan
    IMG Path: Personnel Management  Benefits  Flexible Administration  Dependent/Beneficiary Eligibility  Define Dependent Eligibility Rules
    Beneficiary Eligibility Rule Variants:
    In this step, you define the beneficiary eligibility variants to which you assign beneficiary eligibility rules in the next step. You also specify the following:
    • Whether you want to use a family member grouping in the associated eligibility rule to restrict eligibility to types of family members with certain characteristics
    • Whether the following apply for plans to which the variant is assigned:
     The employee can be a beneficiary
     Contingency beneficiaries can be named
     Spouse approval is required if beneficiaries other than the spouse are to be amed (the system only takes this setting into consideration for plans of the category avings)
    IMG Path: Personnel Management  Benefits  Flexible Administration  Dependent/Beneficiary Eligibility  Define Beneficiary Eligibility Rule Variants
    Beneficiary Eligibility Rules:
    In this step, you define beneficiary eligibility rules to determine which types of family member are eligible as beneficiaries. You then assign your rules to the appropriate plans by means of a rule variant in the step Assign Eligibility Rule Variant to Plan
    IMG Path: Personnel Management  Benefits  Flexible Administration  Dependent/Beneficiary Eligibility  Define Beneficiary Eligibility Rules
    Assign Eligibility Rule Variant to Plan:
    In this step, you assign dependent eligibility variants and beneficiary eligibility variants to plans, thereby assigning the eligibility rules associated with these variants
    IMG Path: Personnel Management  Benefits  Flexible Administration  Dependent/Beneficiary Eligibility  Assign Eligibility Rule Variant to Plan
    COBRA Plans:
    In this step, you specify which health plans that you have already defined in the system are COBRA-relevant.
    When a clerk collects COBRA-qualified beneficiaries, the system only considers employee enrollments in the plans you select here as legitimate cases where COBRA must be offered to the employee
    IMG Path: Personnel Management  Benefits  COBRA  Choose COBRA Plans
    this step, you determine for which flexible spending accounts (FSAs) you will offer continuation of coverage under COBRA. You need to do this for each benefit area separately
    IMG Path: Personnel Management  Benefits  COBRA  Choose COBRA Spending Accounts
    Qualifying Event Coverage Periods:
    In this step, you define the events that qualify individuals for COBRA coverage, and the periods of permitted coverage continuation for each qualifying event type. COBRA legislation states the following regarding coverage continuation periods:
    • In the case of Termination of employment and Reduction in working hours, only 18 months coverage must be provided. If qualified beneficiaries are determined to be disabled within 60 days of the COBRA event, they are entitled to a further 11 months of coverage, as are the other qualified beneficiaries who experienced the original event.
    • For all other qualifying events except Bankruptcy of employer, a qualified beneficiary is entitled to 36 months continuation coverage, and there is no extension provision for disability.
    • In the case of the event Bankruptcy of employer, the coverage continuation period is the life of the retired employee or retired employee's widow/widower. You therefore do not need to define a continuation period in this case.
    IMG Path: Personnel Management  Benefits  COBRA  Define Qualifying Event Coverage Periods
    Assign COBRA Events to Personnel Actions:
    In this step, you define how the system recognizes COBRA-qualifying events from employee personnel actions (infotype 0000) records. You do this by creating a link between the two.
    The only COBRA-qualifying event types that you assign to personnel actions are:
    • Termination
    • Death of employee
    • Reduction in hours
    You need to assign these COBRA-qualifying event types since they are based on customizable entries in your HR master data and therefore cannot be delivered as standard.
    When the system collects COBRA-qualified beneficiaries, it considers employee records within the date range you specify in two stages as follows:
    1. The system searches for employee personnel action (infotype 0000) records. The COBRA qualifying events assigned to any personnel actions found are collected.
    2. The system checks other employee infotype records for specific information which corresponds to COBRA-qualifying event types
    IMG Path: Personnel Management  Benefits  COBRA  Assign COBRA Events to Personnel Actions
    Notification and Payment Intervals:
    In this step, you define details of COBRA administration for those states where state law concerning COBRA differs from federal law.
    Federal regulations are reflected in the state settings for the District of Columbia, which is also the system default.
    If you must comply with state regulations that differ from the federal regulations, you should create a new state entry. Otherwise, you can use the DC version for all employees, regardless of which state they reside in
    IMG Path: Personnel Management  Benefits  COBRA  Define Notification and Payment Intervals
    heck this one and let me know if there is anything else even arun has also given nice response so if u have any query pls revert back
    6

  • Help in using listagg function for more than 8000 char.

    Hi Friends,
    Need you urgent help in using listagg function for more than 8000 char.
    I did the below sample SQL and in "e_orig" and "d_orig" for upto 4000 char it is working fine but I have to use it for more than 8000 char. and it is giving error,
    I checked the listagg function is having limitation of 4000 char.
    I tried but I am unable to achive this. Can someone provide me a sample example to achive this
    select d.dname,d.loc,e.hiredate
    ,listagg(e.ename,',' ) within group (order by e.deptno) over (partition by e.deptno) as e_orig
    ,listagg(e.ename, ',') within group (order by e.sal) over (partition by e.deptno) as d_orig
    from emp e, dept d
    where e.deptno=d.deptno;[ This is my first post, I gone through the guideline for posting a post , and try to go according to that ( I have not pasted here create table and insert as I have used basic table emp, dept for example), please let me know if still I should give this, I will take care from my next post ]
    Thanks in advance

    Interesting, I didn't know you could do that, but...
    BluShadow wrote:
    You could write some PL/SQL code that does it all for you, but that would involve loops and would be slow.Well, objects are written in PL/SQL aren't they? And presumably there'll be implicit looping too? So it's not at all obvious that this method will be faster than doing the joining in PL/SQL in memory. The only way to find out is to benchmark them - so I have done that.
    I noticed that OP's ref cursor actually only ever retrieves a single record for a bound department number, so I decided the best thing would be to test using a procedure that passes an output string back. I selected all (109) employees and put spaces in to ensure above 4000 characters. I also noticed that as he is using PL/SQL he probably can use a VARCHAR2 type, but just not ListAgg in the query, so I wrote short procedures as follows:
    SimpleAggChr     - bulk collect and array processing, VARCHAR2 output
    ClobAggPrc     - the custom aggregation method, CLOB output
    SimpleAggClob     - bulk collect and array processing, CLOB output
    I then wrote a driving script that calls them in the order above and times each call (I like benchmarking so I have my own timing object to make it easy). I then print the lengths for checking, and my object writes the timings to my output table. Running a few times I got varying results, but generally it looks like there isn't a lot to choose between them for performance.
    Here's the procedure code:
    CREATE OR REPLACE TYPE char100_list_type AS TABLE OF VARCHAR2(100)
    CREATE OR REPLACE PROCEDURE SimpleAggChr (x_out OUT VARCHAR2) IS
      l_enames     char100_list_type;
    BEGIN
      SELECT first_name || '                                        ' || last_name
        BULK COLLECT INTO l_enames
        FROM employees
       ORDER BY salary;
      FOR i IN 1..l_enames.COUNT LOOP
        x_out := x_out || l_enames(i) || ',';
      END LOOP;
    END SimpleAggChr;
    CREATE OR REPLACE PROCEDURE SimpleAggClob (x_out OUT CLOB) IS
      l_enames     char100_list_type;
    BEGIN
      SELECT first_name || '                                        ' || last_name
        BULK COLLECT INTO l_enames
        FROM employees
       ORDER BY salary;
      FOR i IN 1..l_enames.COUNT LOOP
        x_out := x_out || l_enames(i) || ',';
      END LOOP;
    END SimpleAggClob;
    SHO ERR
    PROMPT ClobAggPrc
    CREATE OR REPLACE PROCEDURE ClobAggPrc (x_out OUT CLOB) IS
    BEGIN
      SELECT clobagg(first_name || '                                        ' || last_name || ',')
        INTO x_out
        FROM employees
       ORDER BY salary;
    END ClobAggPrc;
    SHO ERRand the driving script:
    SET SERVEROUTPUT ON
    SET TIMING ON
    DECLARE
      l_enames_c1     CLOB;
      l_enames_c2     CLOB;
      l_enames_v     VARCHAR2(32767);
      l_timer     timer_set_type := timer_set_type ('Aggregation');
    BEGIN
      Utils.g_id := 'Aggregation';
      SimpleAggChr (l_enames_v);
      l_timer.Increment_Time ('SimpleAggChr');
      ClobAggPrc (l_enames_c1);
      l_timer.Increment_Time ('ClobAggPrc');
      SimpleAggClob (l_enames_c2);
      l_timer.Increment_Time ('SimpleAggClob');
      DBMS_Output.Put_Line ('SimpleAggChr returned string of length ' || Length (l_enames_v));
      DBMS_Output.Put_Line ('ClobAggPrc returned string of length ' || Length (l_enames_c1));
      DBMS_Output.Put_Line ('SimpleAggClob returned string of length ' || Length (l_enames_c2));
      l_timer.Write_Times;
    END;
    SET TIMING OFF
    SET LINES 150
    SET PAGES 1000
    COLUMN id FORMAT A30
    COLUMN line_text FORMAT A120
    SELECT line_text
      FROM output_log
    WHERE id = 'Aggregation'
    ORDER BY line_ind
    /and the results:
    SimpleAggChr returned string of length 5779
    ClobAggPrc returned string of length 5779
    SimpleAggClob returned string of length 5779
    PL/SQL procedure successfully completed.
    Elapsed: 00:00:27.05
    LINE_TEXT
    Timer Set: Aggregation, constructed at 03 Nov 2011 16:27:07, written at 16:27:35
    ================================================================================
    [Timer timed: Elapsed (per call): 0.02 (0.000016), CPU (per call): 0.01 (0.000010), calls: 1000, '***' denotes corrected
    line below]
    Timer              Elapsed          CPU          Calls        Ela/Call        CPU/Call
    SimpleAggChr          9.84         0.36              1         9.84400         0.36000
    ClobAggPrc            9.37         0.32              1         9.37400         0.32000
    SimpleAggClob         8.25         0.22              1         8.25000         0.22000
    (Other)               0.00         0.00              1         0.00000         0.00000
    Total                27.47         0.90              4         6.86700         0.22500
    13 rows selected.

  • BAPI functions for FB60 and F-02

    Hi,
        Can any one please tell me the BAPI functions for FB60 and F-02 tcodes.
        I had searched in forum,but din't solved my purpose.
    Thanks.
    Sri
    Moderator message - Search harder. Maybe Google will help - post locked
    Edited by: Rob Burbank on May 8, 2010 6:25 PM

    This has been solved for FB50. The original variant for FB50 had never beer created in our QAS system! So I was able to get the screen variant menu selections to reappear by running SHD0, editing, and then saving the transaction variant 'STANDARD 1' (not sure if that is SAP's name for the default variant).
    Hope others find this information useful.
    J. Haynes
    Denver, CO

  • Variant config for MM quotation comparison

    Hi Experts
    I have used MM config functionality for a requirement as described below:
    I need to specify characteristics values for an equipment in Quotations from vendor. This is required for technical evaluation in addition to commercial evaluation.
    Hence, i marked the material as configurable and not as batch managed.
    Then i could maintain characteristic vlaues in respective quotation against charateristics for the class of type 300.
    Since the material is not batch managed, there are no characteristic values seen in GR. This is OK for me.
    But my querry: Is there any issue with this usage?
    warm regards
    ramSiva

    hi
    The procedure is as follows:
    Create a Material - KMAT type with Item category (002)
    Create Charateristics in CT04 - Zbike, where in values mention the Color of the bile like Red, Blue etc
    Create another characteristics in CT04 - ZPrice, where directly go the additional data tab and maintain the table SDCOM and field VKOND (ABAP Dictionary it will ask for)
    Assign these two characteristics to a Class in CL01 - ZBikeclass ( Type 300) in characteristics tab page.
    Then go to CU41 Configuration profile select the material and enter the description click on the class assignment ie assign Zbikclass.
    Now go back to CT04 - enter Zbike -go to values- select Red- go to extras - Other Dependencies - Select Procedure enter in front 10 write - $self.ZPrice='Red' and save
    Now go back go to extras - Other Dependencies - assignments and assign relationship ( by default it will come just save)
    Now select Blue- go to extras - Other Dependencies - Editor - Select Procedure enter in front of 10 write - $self.ZPrice='Blue' and save
    Now go back go to extras - Other Dependencies - assignments and assign relationship ( by default it will come just save)
    Now go to VK11 - Enter VA00 (Condition)(For Std RVA001 Pricing Procedure) - enter variant Red and Blue give the rates accordingly and create the sales order
    for the varient configuration refer following
    http://www.sap-topjobs.com/VARCONFG%5B1%5D.pdf
    http://help.sap.com/printdocu/core/Print46c/en/Data/pdf/LOVC/LOVC.pdf
    regards
    kunal
    award if helpful

  • CU65 Variant Function cannot be released - check function module interface

    Hi ,
    Getting this error while Releasing the variant Function in CU66. Function Module trigerred by this function is of the same name as well as correctly acitvated and released , but while releasing the Function I get this error :  'Function cannot be released - check function module interface' . Following are two characeteristics that are maintained in the variant function :
    1. Customer_Type
    2. Maintenance_Contract
    While executing the Function Module alone I get Raise Inernal Exception i.e it is not identifying the argument name 'Maintenance_Contract' in the FM 'CUOV_GET_FUNCTION_ARGUMENT' exception
    Below is the code for reference . Pls point out if any mistakes :
    ""Local Interface:
    *"  IMPORTING
    *"     REFERENCE(GLOBALS) TYPE  CUOV_00
    *"  CHANGING
    *"     REFERENCE(ZQUERY) TYPE  ZQUERY
    *"     REFERENCE(ZMATCH) TYPE  ZMATCH
    *"  EXCEPTIONS
    *"      FAIL
    *"      INTERNAL_ERROR
    " Data Declaration
    DATA : l_main LIKE CUOV_01-atwrt,
             l_cust LIKE CUOV_01-atwrt.
    " Get value of Input Characteristic Maintenance Contract
      call function 'CUOV_GET_FUNCTION_ARGUMENT'
        exporting
          argument            = 'MAINTENANCE_CONTRACT'
       IMPORTING
          SYM_VAL             = l_main
        tables
          query               = ZQUERY
        EXCEPTIONS
          ARG_NOT_FOUND       = 1
      if sy-subrc <> 0.
      RAISE INTERNAL_ERROR.
      endif.
      " Get value of Input Characteristic Customer Type
      call function 'CUOV_GET_FUNCTION_ARGUMENT'
        exporting
          argument            = 'CUSTOMER_TYPE'
       IMPORTING
          SYM_VAL             = l_cust
       tables
          query               = ZQUERY
        EXCEPTIONS
          ARG_NOT_FOUND       = 1
      if sy-subrc <> 0.
      RAISE INTERNAL_ERROR.
      endif.
       IF l_main EQ 'NO'.
        IF l_cust EQ 'CURRENT'.
          l_cust = 'NEW'.
        ELSEIF l_cust EQ 'VAR CURRENT'.
          l_cust = 'VAR NEW'.
         ENDIF.
         ENDIF.
    " Set value for the output characteristic
         call function 'CUOV_SET_FUNCTION_ARGUMENT'
           exporting
             argument                      = 'CUSTOMER_TYPE'
             vtype                         = 'CHAR'
             SYM_VAL                       = l_cust
           NUM_VAL                       =
           tables
             match                         = ZMATCH
           EXCEPTIONS
             EXISTING_VALUE_REPLACED       = 1

    ZMATCH and ZQUERY are two table types created in SE11 , both of type CUOV_01.

  • How to read variant info for a transaction

    Hi,
    I went through a couple of threads in this regards but could not find answer to my question. In my case I have a function module in which the logic requires me to read a variant say "Z020" in the J3AT transaction and read all the fields' values and use that in the function module.
    Is there any function module available where I say read this variant name in this transaction ?
    thks

    Hi,
    Use RS_VARIANT_VALUES_TECH_DATA function module to fetch variants values.
    Enter Report name which is linked to the transaction code and variant name for which you want to fetch the values. You will get all the values along with field names in VARIANT_VALUES which is tables parameter passed in to function module.
    KR Jaideep,

  • BI IP --- Planning function for File Upload

    Hai All,
    In BI IP , When I am trying to load the data (text file) by using Planning function for File Upload. I am getting an error message When I am clicking on Update .
    Error Message : Inconsistent input parameter (parameter: <unknown>, value <unknown>).
    In Text file I am using Tab Separation for each value
    Anyone help me out.
    Thanks,
    Bhima

    Hi Bhima
    Try one of these; it should work:
    1. If you are on SP 14 you would need to upgrade to SP 15. It would work fine
    2. If not, then -
         a] apply note 1070655 - Termination msg CL_RSPLFR_CONTROLLER =>GET_READ_WRITE_PROVIDS
         b] Apply Correction Instruction 566059 [i.e: in Object - CL_RSPLFR_CONTROLLER GET_READ_WRITE_PROVIDS,
    delete the block: l_r_alvl = cl_rspls_alvl=>factory( i_aggrlevel = p_infoprov ).
    and insert block - l_r_alvl = cl_rspls_alvl=>factory( i_aggrlevel = i_infoprov ).
    Goodluck
    Srikanth

  • Is there any functionality for AVERAGE in ALV, like do_sum, subtot?

    Hi Experts,
    In my_alv report, am doing sub/totals for prices, by using do_sum, subtot functions.........fine. But, I need to do/display the AVERAGE value for Discount % column?
    Is there any functionality for AVERAGE in ALV, like do_sum, subtot?
    thanq

    hi
    check these links out
    http://www.sapfans.com/forums/viewtopic.php?t=20386
    http://www.sapfans.com/forums/viewtopic.php?t=85191
    http://www.sapfans.com/forums/viewtopic.php?t=88401
    http://www.sapfans.com/forums/viewtopic.php?t=17335
    regards
    vijay
    reward points if helpful

Maybe you are looking for