Sum material require by customer
Hi all,
is any way to sum material require by customer in mrp. i want to see the sum quantity by customer in MD04.
THANKS!
JAMES
Hello James,
Your post is not a SAP GUI issue, therefore, you will not get a useful reply.
Before posting, read the 'Scope of the SAP GUI Forum' post and see if there is an entry for PP-MRP-BD
Similar Messages
-
To do one operation on returned material as per requirement of customer.
Dear all ,
Finish material has been confirmed, qulity confirmed , dispatched to customer also .
But as per customer requirement one more operation has to do on the finish material .So that customer has returned that material & it is in return stock .
So please reply me
Abhay
Edited by: abhay patil on Feb 19, 2008 8:19 AMHi
Create a Rework production order in CO07 (without article). Enter your site, production order number(for which rework operation to be done ie the parent order number) and enter the order type (enter if u have a separate order type for rework).
Now enter the details and the Reference operation set to be assigned to the order for rework. -
MDM 5.5 Material, Vendor, Employee & Customer Repositories
Hi,
MDM 5.5 comes with object repositories for Material, Vendor, Employee & Customer. Can anyone help me in finding a way to synchronize these with R/3 ?
I am able to see Corresponding IDoc names as data sources in Import Manager for these repositories. But, my question is, what are the steps required for synchronizing with R/3 so that I can import/export these data from/to R/3.
Thanks in Advance,
Rajani Kumar Klook at this doc:
MDME 5.5 - ConfigGuide - MD Consolidation & MD Harmonization
at Quick Link:/nw04installation
Kevin -
Hi Gurus,
My client is processing the raw material which is provided by customer and also the same raw material is been procured by client.Now he wants to differentiate between customer & self procured material due to price diff. He does not want two diff. no. for the same material. I have gone through various links in SDN but no suitable solution have been found. And also how to generate requirement for customer provided material.
Regards,
DevenHi! Devendra,
You should receive customer supplied material against the sales order with movement 501(if you don't want to valuate the material in your inventory). System will show that material separately as customer stock. If you want to show that material in your inventory but want to valuate it separately then you will have to use split valuation as was suggested earlier.
I suppose this will help you in resolving the issue.
Regards,
Uday -
Material Provided by Customer table MKUB
There is a table in SAP "MKUB Material Provided by Customer"
My question is how is this table used?
We currently manage material that our customer owns and have not yet found a good process.
If there is a standard SAP process it would be great.
Thanks in advance
BradPK
Thanks for the additional information.
However a 501 E movement does not update table MKUB.
The reason I am asking about MKUB is because usually if a table has been created by SAP there is a process in place that uses the table. Just by the name of the table " Material Provided by Customer" it indicates to me that there may be a standard SAP process for what I am trying to accomplish.
The 501 E mvt requires that I sell the material back to the customer using the same sales order that was used to bring the material into stock.
What we need is the ability to bring in material owned by the customer, have it identified in SAP as owned by that customer, and be able to ship the material out to the customer as new orders are created.
In this case we are acting as a 3PL warehouse for the customer.
Any additional thoughts or suggestions would be great.
Thanks
Brad -
HI FRIENDS,
CAN ANYONE SEND ME THE ABAP-HR MATERIAL .
THAXS AND REGARDS.
HITESHMaybe this link can be helpfull
http://www.sapdevelopment.co.uk/hr/hr_infotypes2.htm
Have a look at http://www.sap-img.com/human/how-to-create-a-hr-infotype.htm, but have also a look at this thread
https://www.sdn.sap.com/sdn/collaboration.sdn?contenttype=url&content=https%3A//forums.sdn.sap.com/thread.jspa%3FthreadID%3D9945%26messageID%3D63016
found this link probably can be helpful to someone
http://help.sap.com/saphelp_46b/helpdata/en/f7/2fe034ee251f34e10000009b38f83b/frameset.htm
http://sap.ittoolbox.com/groups/technical-functional/sap-hr/how-to-create-z-infotype-in-organizational-management-745603
How to create a HR infotype?
1) Go to Transaction PM01.
2) Enter the custom Infotype number which you want to create (Should be a 4 digit number, start with 9).
3) Select the Employee Infotype radio button.
4) Select the PS Structure Infotype.
5) Click on Create A separate table maintenance window appears
6) Create a PS structure with all the fields you want on the Infotype
7) Save and Activate the PS structure
8) Go back to the initial screen of PM01.
9) Click on All push button. It takes a few moments.
10) Click on Technical Characteristics. Infotype list screen appears
11) Click on Change(pencil) button
12) Select your Infotype and click on Detail (magnifying glass) button
13) Give T591A as subtype table
14) Give T591S as subtype txt tab
15) Give your subtype field as subtype field
16) Save and come back to PM01 initial screen
17) Click on Infotype Characteristics Infotype list screen appears
18) Click on Change (pencil) button
19) Click on New Entries
20) Enter your Infotype number and short text
21) Here we have to set different Infotype Characteristics as per the requirement. (Better open another session with some standard Infotypes infotype characteristics screen and use as the reference to fill yours)
22) Save your entries.
23) Now the Infotype is created and ready to use.
24) If you want to change the layout of the Infotype as per your requirement
25) In the PM01 initial screen Select Screen radio button and give 2000 as the screen name, then click on edit.
26) In the next screen.. Select Layout Editor and click Change.
27) Screen default layout appears here you can design/modify the screen..change the attributes of the fields..etc.
28) Save and activate. (Dont forget to Activate at every level)
InfoSets in the HR Application
You can use SAP Query in HR to report on HR data. Queries are maintained as described in Creating Queries. The special features of queries created for HR are described in Maintaining Queries in the Human Resources Application. The maintenance procedure for HR InfoSets differs from the described procedure inasmuch as HR data fields are grouped together in infotypes.
InfoSet management in SAP Query is also used for InfoSet Query. For further information, see Functions for Managing InfoSets.
If you want to create InfoSets for HR, you can use logical databases PNP, PAP, and PCH (see HR Logical Databases). The database you must use to create your InfoSet depends on the component in which the data you want to report on is stored.
The reports you can execute using InfoSets based on logical databases PNP or PCH are similar, but differ in that they can select different objects. The following table describes the connection between the logical database, and the infotypes you can include in an InfoSet. It also provides you with one or two examples of reports that you can execute using the appropriate InfoSets.
Logical database PNP PCH PAP
Selection of Persons Objects from Personnel Planning Applicants
Infotypes that can be included in the InfoSet Infotypes for
Personnel Administration (0000-0999)
Time Management (2000-2999)
Payroll infotypes
Infotypes for Personnel Planning objects that can be related to persons If the object type is specified:
Infotypes for the object type
Infotypes for objects that can be related to the specified object type
If the object type is not specified:
All infotypes Infotypes for Recruitment (4000-4999)
Some infotypes for Personnel Administration (such as 0001 and 0002)
Customer infotypes
Reporting examples Selection of all persons who participated in a specific business event, output of prices for reserved business events
Selection of all persons assigned to a specific personnel area, output of qualifications held by these persons Selection of all business events held in London in March, output of all persons who participated in these business events
Selection of all positions assigned to a specific organizational unit, output of all persons assigned to the positions Selection of all applicants hired last year to work on special projects, output of addresses for the applicants selected
Creating InfoSets
The maintenance procedure for HR InfoSets differs from the procedure described so far in this section inasmuch as HR data fields are grouped together in infotypes. To set up an InfoSet for the HR application, proceed as follows:
1. On the initial screen for maintaining InfoSets, enter a name for the InfoSet and choose Create.
2. On the next screen, enter a name for the InfoSet and select one of the HR logical databases in accordance with your reporting requirements.
Customer infotypes can be created on all HR logical databases. In each individual case, therefore, you must decide which database to select so that you can report on customer infotypes.
This screen enables you to enter an authorization group. All of the queries that are subsequently created using this InfoSet can only be executed by persons who have this authorization group.
3. Choose .
This takes you to the Infotype Selection for InfoSet .
The logical HR database uses the table APPLICANT. You must declare it in the TABLES statement.
At the GET APPLICANT event, the APPLICANT structure contains the data for an applicant number chosen on the basis of selection screen entries.
The APPLICANT-APLNO field contains the applicant number which is selected for processing.
Only the APPLICANT-APLNO field should be read from the work area of the APPLICANT table. The other fields are intended for internal use only.
2.7 Authorization Checks in Reporting (PA-APP)
Generally, authorization checks in reporting do not differ from those in the transactions. Since data access in reporting is always of the read type, the system checks for a read authorization; the authorization group must be R or *.
In some situations, you may want to use a simplified authorization check when running reports. The object RPABAP is required for the check as well as the object RPORGIN; if these authorizations are available, a simpler and faster check is performed.
If the report cannot read certain applicant data due to lack of authorization, data for these persons is not processed at the GET APPLICANT time point. A note appears at the end of the list stating the number of applicants who were skipped due to lack of authorization.
2.8 Views
Introduction
When evaluating data, we distinguish between the logical and the physical view.
The physical view corresponds to the form in which the infotype data is stored in the HR tables. This data is stored in infotype records with a validity period.
In the logical view, the validity periods of individual fields are determined for several infotype records. For example, for an evaluation, the time period during which an employee worked at a particular job may be important, irrespective of whether a company code, personnel area or cost center change occurred during this time.
Data from several infotypes can also be provided for a specific partial period. When calculating partial payroll periods, it is especially important that data on basic pay, work schedule and cost distribution are provided for the relevant partial period.
These two types of logical views are implemented in the projection and join.
 Join
 Projection
 Join and Projection
 Time-Dependent Control Tables
 Generalization of the View
Join
A join processes records from two or more infotypes. The data from these infotypes is provided for a specific partial period.
 We would like to know in which time period an employee worked at which job and at which address he or she resided during this time.
The following address data is available:
January June Hamburg
June December Munich
The following work center data is available:
January April Programmer
May December Course instructor
If the address and work center data are provided for specific partial periods, the following cases result:
January April Hamburg / programmer
May June Hamburg / course instructor
July December Munich / Course instructor
The ABAP syntax of this join is as follows:
PROVIDE * FROM Pomp
FROM Pnnnn
BETWEEN PN-BEGDA AND PN-ENDDA.
The partial periods for infotypes Pomp and Pnnnn as well as for all other infotypes of the join are defined in the fields BEGDA and ENDDA.
The data of each infotype in the join must be available during the entire validity period of the infotype. The time periods of infotype records may not overlap; therefore, the join may not contain infotypes with time constraint "three".
The time periods of records overlap if an infotype is read without any subtype restrictions. For example, the Address infotype has the subtypes Permanent residence, Temporary residence and Home address.
Time periods will ultimately overlap if all addresses are read. Therefore, you must always select a subtype for a join, and this subtype may not have the time constraint "three".
The program code for the above join for work center and address data is as follows:
REPORT RPABAP03.
TABLES: PERNR.
INFOTYPES: 0001, 0006.
GET PERNR.
PROVIDE * FROM P0001
FROM P0006 BETWEEN PN-BEGDA AND PN-ENDDA
WHERE P0006-SUBTY eq '1'.
WRITE: / PERNR-PERNR, P0001-STELL,
P0006-STRAS, P0006-BEGDA, P0006-ENDDA.
ENDPROVIDE.
Sometimes no data is available for a particular infotype in the selected partial period. Infotype validity periods may not overlap but gaps are permitted.
For example, gaps can occur when personal data is joined with address data:
Personal data
January 1960 - May 1998 Miller
May 1998 - December 1998 Smith
Address data:
January 1998 - December 1998 Hamburg
A join for personal and address data is presented as follows:
January 1960 - December 1997 Miller
January 1998 - April 1998 Miller / Hamburg
May 1998 - December 1998 Smith / Hamburg
Only personal data is available in the first partial period. Since the record does not provide the required information, the join's function of providing data from all associated infotypes has not been fulfilled.
The variables Pnnnn_VALID recognize that only incomplete data is available for a particular partial period.
This variable is formed when the report is run for each Pnnnn infotype included in a join.
If data exists in the partial period for the Pnnnn infotype, the variable Pnnnn_VALID is filled with X.
These variables are evaluated as follows:
REPORT RPDEMO03.
TABLES: PERNR.
INFOTYPES: 0002,
0006.
GET PERNR.
PROVIDE * FROM P0002
FROM P0006 BETWEEN PN-BEGDA AND PN-ENDDA
WHERE P0006-SUBTY = '1'.
IF P0006_VALID EQ 'X'.
WRITE: / PERNR-PERNR,
P0002-BEGDA DD/MM/YYYY,
P0002-ENDDA DD/MM/YYYY,
P0002-NACHN,
P0006-ORT01.
ENDIF.
ENDPROVIDE.
A list is generated only if address data is available. The first partial period, for which only personal data is available, is suppressed.
Projection
All data of an infotype is stored on the database with its period of validity.
When you change one or more fields of an infotype record, the system creates a new record with a new validity period. The date on which you changed the record is the start date of this new record.
Therefore, the data fields that are not affected by the changes contain the same data over several infotype records and validity periods.
From a logical perspective, these fields are valid in all infotype records until they are changed.
When seen from this logical perspective, each field of an infotype has its own validity period.
This is illustrated in the following case:
An employee has worked as a programmer for three years in three different personnel areas.
The following organizational assignment data is available:
January 1992 - December 1992: Programmer /personnel area 1
January 1993 - December 1993: Programmer /personnel area 2
January 1994 - December 1994: Programmer /personnel area 3
If you only require the time period during which an employee performs a specific job and not his or her personnel area for an evaluation, the following applies:
January 1996 - December 1998: Programmer
The physical view has three infotype records, the logical view one.
To create meaningful evaluations and avoid redundancies, create logical views for infotype records.
Select the infotype fields that are important for the evaluation and disregard the others.
In the above example, the data in the other fields is invalid for the evaluation since it is unknown which personnel area the employee belonged to from 1996 - 1998.
This view of the validity period of a group of infotype fields is known as projection.
The program code for the projection is:
PROVIDE FROM Pnnnn
BETWEEN PN-BEGDA AND PN-ENDDA .
The infotype data for a projection must be available throughout the entire validity period. If the time periods of certain infotype records overlap, the data cannot be clearly assigned to one period.
Therefore, you should not use projections for infotype records with time constraint three. The report for the above projection is:
REPORT RPABAP04.
TABLES: PERNR.
INFOTYPES: 0001.
GET PERNR.
PROVIDE STELL FROM P0001 BETWEEN PN-BEGDA AND PN-ENDDA.
WRITE: / PERNR-PERNR, P0001-STELL, P0001-BEGDA,
P0001-ENDDA.
ENDPROVIDE .
The logical validity for the activity period is included in the infotype BEGDA and ENDDA fields.
Join and Projection
You can combine the two logical views of infotype data, the join and the projection.
We read the data from several infotypes and create new partial periods. We select the infotype fields that are important for the evaluation and combine these partial periods again.
The following example illustrates this.
An employee works as a programmer in the current year and marries in May. Her name does not change.
Organizational assignment:
January - December Programmer
Personal data:
January - April Donna Debug - single
May - December Donna Debug - married
When the data from both infotypes is read concurrently, the result is:
January - April Donna Debug - single /
programmer
May - December Donna Debug - married /
programmer
Since we can disregard her marital status in the evaluation, we project on her first and last names:
January - December Donna Debug / programmer
The following report exemplifies the above case:
REPORT RPDEMO04.
TABLES: PERNR.
INFOTYPES: 0001,
0002.
GET PERNR.
PROVIDE STELL FROM P0001
NACHN VORNA FROM P0002
BETWEEN PN-BEGDA AND PN-ENDDA
IF P0001_VALID = 'X'.
WRITE: / P0002-NACHN, P0002-VORNA,
P0001-BEGDA DD/MM/YYYY,
P0001-ENDDA DD/MM/YYYY,
P0001-STELL.
ENDIF.
ENDPROVIDE.
This report combines the associated validity periods and provides the data of relevant infotype fields for a specific period.
 Fields which are not accessed have their initial value in the projection.
Provision of data for a specific partial period is especially important for partial period factoring in payroll.
If an employee's basic pay or the cost distribution changes during the payroll period, you must calculate the salary proportionately for the resulting partial periods.
However, if the payroll administrator of the organizational unit changes, this has no effect on payroll.
By linking a join and a projection, you can read the master data for a specific partial period.
Time-Dependent Control Tables
Infotype data is generally coded as a key (for example, infotype P0006, address type 1 = permanent residence) to allow fast data entry and space-saving storage. When you process infotypes, the texts or attributes of the keys are read from the relevant control tables.
In many control tables, storage of data is time-dependent and therefore assigned a validity period.
In HR, this applies to the following areas:
Work schedules
Pay scale structures
Wage types
Wage type valuation
Bank data
Positions
Payee codes
When you read the data for an infotype key from time-dependent control tables, you must determine which record is valid in the specified validity period.
If you use a transaction to process an infotype, the system reads the table record which is valid on the start date.
Generalization of the View
You can use the logical view to edit and output data according to user specifications.
The special feature of HR views is the time dependency of the data. Personnel data is almost always related to specific validity periods. A HR view provides data for specific time intervals.
In general terms, a HR view is a logical perspective of interval-dependent internal tables.
See also:
Processing All Infotype Records (PA-PAD)
Processing All Infotype Records (PA-APP)
Processing a Specific Infotype Record (PA-PAD)
Processing a Specific Infotype Record (PA-APP)
3 Import/Export Files in HR
The following sections describe the purpose of files PCL1 and PCL2 and explains how to access them.
Files PCL1, PCL2, PCL3 and PCL4
Storing Data in PCLn Files
PCLn Buffer
Cluster Directory Manager
3.1 Files PCL1, PCL2, PCL3 and PCL4
Which information is stored in the files?
File PCL1 is the basis for the HR work area data. It contains information from the time data recording, for example, incentive wage time tickets or infotype supplement texts.
File PCL2 contains derived information, for example, payroll results. It also contains all generated payroll schemas.
File PCL3 contains applicant data.
File PCL4 contains the change documents for HR master data and recruitment.
The structure of PCLn files corresponds to that of the INDX file which you may be familiar with from other applications. The structure of all PCLn files (n = 1, 2, 3, and 4) is identical.
Structure of Files
Like in almost all SAP files, the key element with the highest priority is the client; data within a client is grouped according to basic relations (field PCLn-RELID).
The type of basic relation is known as a cluster and characterizes the stored data according to the type, for example, cluster RX contains the payroll result for country X (from table T500L) and cluster TE contains the trip costs data.
Depending on the cluster, the structure of PCLn-SRTFD is defined in a field string xx-KEY, which is defined in an include RPCnxxy0.
Naming conventions
n = 1, 2, 3, or 4 (for PCL1, PCL2, PCL3, or PCL4)
xx = for the cluster
y = 0 for international clusters
y = country grouping according to T500L for national clusters
The personnel number is usually the first component of xx-KEY.
Importing and Exporting Data
The import/export files PCLn are managed with the ABAP/4® commands IMPORT and EXPORT . These commands store objects such as fields, field strings, or internal tables on the database, or read these from the database. Data is read from and written to the database using a unique key( xx-Key).
Please note that the RMAC macros RP-IMP-Cn-xx and RP-EXP-Cn-xx are provided for importing and exporting data. Only these macros should be used.
See also Macro Modules
3.2 Storing Data in PCLn Files
Data from the different HR application areas is stored in data clusters in PCLn files (n = 1, 2, 3, or 4).
This collection of data objects can consist of:
Fields used within reports
Field strings
Internal tables
The structure of the PCLn files provides a framework for the individual application areas.
Each application area must have a two-character cluster name (relation ID). It must also have a key structure; 40 bytes of the SRTFD field are available for this structure.
When a record is exported to the PCLn file, the cluster ID is written to the RELID field and the key value to the SRTFD field.
Naming convention for includes when defining clusters:
RPCnxxy0 n = 1, 2, 3 or 4 (for PCL1, PCL2, PCL3, PCL4)
xx = cluster ID
y = country indicator
Description of Cluster Data using Cluster RX as an Example
The data definition is stored in the include RPC2RX00 in accordance with the above naming conventions.
Structure of cluster key:
Data: BEGIN OF RX-KEY.
INCLUDE STRUCTURE PC200.
DATA: END OF RX-KEY.
The DDIC structure PC200 contains the fields PERNR (personnel number) and SEQNO (sequential number).
The data definition of the cluster also contains other internal tables.
For a list of available data clusters, refer to the domain description in the Data Dictionary.
xx Key
The xx key name is dependent on the cluster.
The RX KEY is used for all Rx and Xx clusters. In all other cases, the name of the xx key corresponds to that of the cluster.
Cluster xx Key
RA RX-KEY
B1 B1-KEY
G3 G3-KEY
XA RX-KEY
3.3 PCLn Buffer
To keep the number of database accesses to a minimum, import and export data is stored in the main memory buffer. Buffer management routines ensure that exported data can be stored in the PCLn files.
The following two examples illustrate which problems can occur without a buffer.
Retroactive accounting of payroll results
Starting payroll in the test mode
Retroactive Accounting of Payroll Results
In February 1998, a retroactive accounting run is executed for January.
FOR PERIOD 199801 IN PERIOD 199802
The payroll results for January are recalculated and then written directly to the database.
Result:
The database now contains the results of the following payroll periods.
FOR-PERIOD 199801 IN-PERIOD 199802
FOR-PERIOD 199801 IN-PERIOD 199801
Payroll is then run for February.
FOR-PERIOD 199802 IN-PERIOD 199802
If problems should arise during the payroll run for this period, the February record is not stored on the database.
Result:
The current January record on the database is:
FOR-PERIOD 199801 IN-PERIOD 199802
This problem does not arise if you use the buffer since all data of a transaction is always updated collectively. In the above example, the recalculated January result would be stored in the buffer and, if the payroll run for February were terminated prematurely, the database would not be updated.
The current January record on the database would thus be:
FOR-PERIOD 199801 IN-PERIOD 199802
Starting Payroll in the Test Mode
In a test run, the database is not updated. Since the payroll results from the previous period are used as the basis for calculating the results of the following period, the results of the actual payroll run would differ from those of the test run, if this test run were executed over several periods.
The use of the buffer enables trouble-free access to the required results for the previous period.
What is required for exporting/importing data to/from the PCLn files using the buffer?
 The following includes contain the data definition for the buffer. They must be included in the report that writes the data to or reads the data from the database.
RPPPXD00
RPPPXD10
 Include RPPPXD10 must be in the common part BUFFER .
Include RPPPXM00, which contains the buffer management routines, is also required.
The macros for importing and exporting data must comply with the following naming convention:
Naming Convention for EXPORT/ IMPORT Macros:
RP-aaa-Cn-xy
where aaa = IMP / EXP, n=1 for PCL1, 2 for PCL2, 3 for PCL3, 4 or PCL4
and xy = cluster name.
This guarantees consistency between the export and import of data and also ensures that all exported objects are imported again.
Export Using the Data Buffer
When macros are used for exporting, records are written to a main memory buffer and not directly to the database. When the program run has been completed, the records in the buffer are stored in the appropriate PCLn database.
Import Using the Data Buffer
When the macros are used to import data, the data records are not read directly from file PCLn. Instead, the system checks the buffer directory to see whether the main memory already contains a record with the same key. If this is not the case, the record is read from PCLn to the buffer and then retrieved from the buffer for the report.
If the import is successful, the return code RP-IMP-xy-SUBRC = 0 is set. When data is read from the buffer, the system carries out a check for cluster authorization. Standard import programs follow the naming convention RPCLSTxy (xy = cluster name).
 report rpttcdmg.
tables:
pernr,
pcl1,
pcl2.
include rpppxd00. "buffer definitions
data: begin of common part 'BUFFER'.
include rpppxd10. "PCLx buffer
data: end of common part.
data: begin of common part 'CLUSTER_DIRECTORY'.
include rpc2cd00. " "cluster directory definitions
data: end of common part.
include rpc2rdd0.
get pernr.
rp-init-buffer. "reset buffer
cd-key-pernr = pernr-pernr.
rp-imp-c2-cd. "read cluster CD from
buffer/DB
perform cd_manager using ... .
alternative: call function rp_evaluation_periods...
rx-key-pernr = pernr-pernr.
rx-key-seqno = rgdir-seqnr.
rp-imp-c2-rd. "read cluster RD from
buffer/DB
rp-exp-c2-rd. "update cluster RD in buffer
perform prepare_update using 'V'. "update database (DB)
Subroutines CD manager and Cluster buffer
include rpcmgr00. "Cluster Directory Manager
include rpppxm00. "module pcl1(2)-buffer
3.4 Cluster Directory
Finding Payroll Results for a Specific Query
Payroll results are stored in cluster Rx of the PCL2.
The cluster key is non-mnemonic. It contains the PERNR (personnel number) and SEQNO (sequential number) fields.
The internal table RGDIR contains a directory entry for each payroll result. This entry is a sequential number (RGDIR-SEQNR) which uniquely identifies the payroll result.
Payroll results can only be imported if the payroll cluster key contains the personnel number and sequential number.
Before you can import a payroll record, you must select the entry in the RGDIR on the basis of existing data such as for-period, for-payroll area, for-payroll category, in-period, in-payroll area, in-payroll category, and so on, in order to determine the sequential number.
You will probably always have the same queries when importing payroll records. For example, "Which payroll results (original and retroactively accounted records) were written for a specific payroll run (defined by IN payroll category, IN payroll area, IN period)"?
There are standard modules that can be used. It is advantageous to use the standard modules rather than self-programmed solutions because no program modifications will be required if the payroll directory changes. The modules are described in the following section:
Function Modules for Selecting Payroll Results
3.5 Function Modules for Selecting Payroll Results
The employees payroll directory is always transferred to the function modules using the table RGDIR.
The modules then transfer the payroll records which satisfy the specified selection criteria using a table whose type corresponds to that of the RGDIR but which has a different name. The selection parameters differ according to the function of the module. For more information, read the module documentation.
All module names begin with CD_.
Function Module: CD_EVALUATION_PERIODS
Function Module: CD_READ_PREVIOUS
Function Module: CD_READ_PREVIOUS_ORIGINAL
Other Modules for the Payroll Cluster
Sample Report
Function Module: CD_EVALUATION_PERIODS
This module transfers the payroll results to a payroll run as A records (current). It also transfers the accompanying P records (previous).
This is the module most frequently used in evaluation programs.
Table contents before the function module is accessed:
SEQNR FPPER FPBEG FPEND INPER IPBEG IPEND BONDT PAYTY PAYID INPTY INPID
00001 01.1996 01.01.96 01.15.96 01.1996 01.01.96 01.15.96
00002 01.1996 01.01.96 01.15.96 01.16.96 01.16.96 B 0
00003 01.16.96 01.16.96 01.16.96 01.16.96 01.16.96 B 0 B 0
00004 01.17.96 01.17.96 01.17.96 01.17.96 01.17.96 A 0 A 0
00005 01.17.96 01.17.96 01.17.96 01.17.96 01.17.96 A 1 A 1
00006 02.1996 01.16.96 01.31.96 02.1996 01.16.96 01.31.96
00007 02.1996 01.16.96 01.31.96 03.1996 02.01.96 01.15.96
00008 03.1996 01.16.96 01.31.96 03.1996 01.01.96 02.15.96
The following parameters are transferred:
- BONUS_DATE = '00000000'
- INPER_MODIF = '02'
- INPER = '199803'
- PAYTY = ' '
- PAYID = ' '
Result:
SEQNR FPPER FPBEG FPEND INPER IPBEG IPEND BONDT PAYTY INPTY INPID SRTZA
00006 02.1996 01.16.96 01.31.96 02.1996 01.16.96 01.31.96 P
00007 02.1996 01.16.96 01.31.96 03.1996 02.01.96 02.15.96 A
00008 03.1996 01.16.96 01.31.96 03.1996 02.01.96 02.15.96 A
Explanation of individual fields
Function Module: CD_READ_PREVIOUS
This module transfers a previous payroll record for a payroll record; this is the newest record for the payroll period (or daily payroll run) which was written before the transferred payroll record and contains the same FOR data as the transferring record.
Table contents before the function module is accessed:
SEQNR FPPER FPBEG FPEND INPER IPBEG IPEND BONDT PAYTY PAYID
00001 01.1996 01.01.96 01.15.96 01.1996 01.01.96 01.15.96
00002 01.1996 01.01.96 01.15.96 01.16.96 01.16.96
00003 01.16.96 01.16.96 01.16.96 01.16.96 01.16.96 B 0
00004 01.17.96 01.17.96 01.17.96 01.17.96 01.17.96 A 0
00005 01.17.96 01.17.96 01.17.96 01.17.96 01.17.96 A 1
00006 02.1996 01.16.96 01.31.96 02.1996 01.16.96 01.31.96
00007 02.1996 01.16.96 01.31.96 03.1996 02.01.96 02.15.96
00008 03.1996 01.16.96 01.31.96 03.1996 02.01.96 02.15.96
The following parameters are transferred:
- Record with SEQNR '00007'
Result:
SEQNR FPPER FPBEG FPEND INPER IPBEG IPEND BONDT PAYTY SRTZA
00006 02.1996 01.16.96 01.31.96 02.1996 01.16.96 01.31.96 P
Explanation of individual fields
Function Module: CD_READ_PREVIOUS_ORIGINAL
This module reads the previous original payroll result.
Table contents before the function module is accessed:
SEQNR FPPER FPBEG FPEND INPER IPBEG IIPEND BONDT PAYTY PAYID
00001 01.1996 01.01.96 01.15.96 01.1996 01.01.96 01.15.96
00002 01.1996 01.01.96 01.15.96 01.16.96 01.16.96
00003 01.16.96 01.16.96 01.16.96 01.16.96 01.16.96 B 0
00004 01.17.96 01.17.96 01.17.96 01.17.96 01.17.96 A 0
00005 01.17.96 01.17.96 01.17.96 01.17.96 01.17.96 A 1
00006 02.1996 01.16.96 01.31.96 02.1996 01.16.96 01.31.96
00007 02.1996 01.16.96 01.31.96 03.1996 02.01.96 02.15.96
00008 03.1996 01.16.96 01.31.96 03.1996 02.01.96 02.15.96
The following parameters are transferred:
- Record with SEQNR '00008'
Result:
SEQNR FPPER FPBEG FPEND INPER IPBEG IPEND BONDT PAYTY SRTZA
00006 02.1996 01.16.96 01.31.96 02.1996 01.16.96 01.3196 P
Explanation of individual fields
3.6 Other Modules for the Payroll Cluster
Modules which derive information from the payroll cluster are available in addition to the modules for payroll result selection.
1. CD_RETROCALC_PERIOD
This module differentiates between original payroll records and retroactive accounting records.
Table contents before the function module is accessed:
SEQNR FPPER FPBEG FPEND INPER IPBEG IPEND BONDT PAYTY PAYID
00001 01.1996 01.01.96 01.15.96 01.1996 01.01.96 01.15.96
00002 01.1996 01.01.96 01.15.96 01.16.96 01.16.96
00003 01.16.96 01.16.96 01.16.96 01.16.96 01.16.96 B 0
00004 01.17.96 01.17.96 01.17.96 01.17.96 01.17.96 A 0
00005 01.17.96 01.17.96 01.17.96 01.17.96 01.17.96 A 1
00006 02.1996 01.16.96 01.31.96 02.1996 01.16.96 01.31.96
00007 02.1996 01.16.96 01.31.96 03.1996 02.01.96 02.15.96
00008 03.1996 01.16.96 01.31.96 03.1996 02.01.96 02.15.96
The following parameters are transferred:
- Record with SEQNR '00008'
Result:
- CALCD = ' '
Explanation of individual fields
2. CD_PAYROLL_UNTIL
This module reads the RGDIR for the date up to which the regular payroll run was executed for an employee.
3. CD_HIGHEST_PAYDT
This module reads the most recent check date for an employee from the RGDIR.
4. CD_GET_INFO
This module provides information (most recent check date, accounted to date) for a particular personnel number.
3.7 Explanation of Individual Fields
For-Information
The FPPER, FPBEG, FPEND, BONDT, PAYTY, PAYID, ABKRS, PERMO, PAYDT, JUPER fields contain information on the period for which payroll is run.
In-Information
The INPER, IPEND, INPTY, INPID, IABKRS, IPERM fields contain information on the period in which payroll is run.
SEQNR
The field is used as a key to uniquely identify the payroll record.
This field also defines the sequence of payroll results (history).
Control Indicator (SRTZA)
Control indicator Meaning
a Current
p Previous
o Old
 For more information, see the online documentation for the individual function modules.
3.8 Sample Report
REPORT RPTTMWBS.
DATA: RGDIR LIKE PC261 OCCURS 0 WITH HEADER LINE.
DATA: EVPDIR LIKE RGDIR OCCURS 0 WITH HEADER LINE.
DATA: PREVIOUS_RESULTS LIKE RGDIR OCCURS 0 WITH HEADER LINE.
DATA: CALCD TYPE C.
DATA: IN_ENTRY LIKE PC261.
DATA: OUT_ENTRY LIKE PC261.
INCLUDE RPCCCD09.
CALL FUNCTION 'CU_READ_RGDIR'
EXPORTING
PERSNR = '00021218'
TABLES IN_RGDIR = RGDIR
EXCEPTIONS
NO_RECORD_FOUND = 1
OTHERS = 2.
Read RGDIR
CALL FUNCTION 'CD_EVALUATION_PERIODS'
EXPORTING
BONUS_DATE = '00000000'
INPER_MODIF = '02'
INPER = '199603'
PAY_TYPE = CD_C-REGULAR
PAY_IDENT = ' '
TABLES
RGDIR = RGDIR
EVPDIR = EVPDIR
IABKRS =
EXCEPTIONS
NO_RECORD_FOUND = 1
OTHERS = 2.
output:
00006
00007
00008
Read regular payroll results for January
A results (original result plus retroactive calculations)
and P results
LOOP AT EVPDIR WHERE SRTZA = CD_C-ACTUAL.
Only current results (00007 and 00008)
CALL FUNCTION 'CD_RETROCALC_PERIOD'
EXPORTING
ENTRY = EVPDIR
IMPORTING
CALCD = CALCD
EXCEPTIONS
OTHERS = 1.
Determine, whether original result
CHECK CALCD = ' '.
Special processing: Only the original period
March is processed (seqnr 00008).
IN_ENTRY = EVPDIR.
CALL FUNCTION 'CD_READ_PREVIOUS_ORIGINAL'
EXPORTING
IN_RECORD = IN_ENTRY
IMPORTING
OUT_RECORD = OUT_ENTRY
TABLES
RGDIR = RGDIR
EXCEPTIONS
OTHERS = 1.
out_entry now contains the previous results
Input 00008 ----> Output 00006
ENDLOOP.
LOOP AT EVPDIR WHERE SRTZA = CD_C-ACTUAL.
IN_ENTRY = EVPDIR.
CALL FUNCTION 'CD_READ_PREVIOUS'
EXPORTING
IN_RECORD = IN_ENTRY
TABLES
RGDIR = RGDIR
OUT_RGDIR = PREVIOUS_RESULTS
EXCEPTIONS
NO_RECORD_FOUND = 1
OTHERS = 2.
Input 00007 ---> 00006
Input 00008 ---> no record found
Output structure is a table, since there can be
several previous results: for example, if legal person
changes, and is retroactively deleted
ENDLOOP
4 Specific Commands
The following sections describe the different specific commands in HR.
Function modules in HR
Macro modules
4.1 Function Modules in HR
Function modules are program modules which have a defined interface and allow type testing of parameters.
They are managed with transaction SE37 and combined to function groups according to relevant criteria. You can access this transaction under Tools  ABAP Workbench  Function Builder.
The HR function groups use the naming convention RPxx or HRxx where xx is an identifier of your choice.
You can use the SHOW FUNCTION * editor command to branch from report processing to function module display.
4.2 Macro Modules
Definition
An module that can be called within an ABAP program.
Use
Like subprograms and function modules, macro modules are a means of presenting programs in modular form. Macro modules (macros) are used often in the Human Resources application component (HR).
Defining and Calling Modules
Two options are provided:
Macros can be defined in reports or includes using the ABAP command DEFINE. A macro can be used within a report or within an include. If a macro is used in a report, and the macro is defined in an include with the DEFINE command, the include must be integrated.
 Macros have the following advantages:
If a macro is changed, each report using this macro is automatically regenerated when it is executed.
Macros can also be defined as RMAC macros. The source code of these modules is stored in the function section of the control table TRMAC (Macros in ABAP Programs). The coding is grouped under a specific name in the table key.
According to conventions, the first two letters of the name must stand for the application. The rest of the name is freely definable.
 Customer-specific RMAC modules should begin with a special character.
The macros defined in the control table TRMAC can be used by all reports.
 When you change a RMAC macro in the table TRMAC, the reports that use this macro are not regenerated automatically. You must regenerate them manually.
The following section includes a list of programming utilities for the logical databases PNP and PAP.
5 Utilities in HR
The following utilities are available.
General Utilities
Report Meaning
RPUACG00 Code generation / authorization check
RPUAUD00 Infotype auditing
Programming Utilities
Report Meaning
RPINCL10 String search in reports
Cluster Utilities
Report Meaning
RPCLSTyy Display cluster for PCLx (yy = RELID)
RPUPxD00 Delete cluster for PCLx (individual data records)
RPUPxD10 Delete cluster for PCLx (several data records)
6 References:
Different parts of the document has been prepared with the help of articles available on Internet
Following websites are referred :
a). http://help.sap.com
b). http://sapfans.com
c). http://www.sap-basis-abap.com/saphr.htm -
Forecasting future sales orders all material requirement.
Hi All
I have a requirement in our company :
The Material is Having Strategy Group as 20 for our product ( Make to Order Scenario)
The requirement is such that the sales team get some forecast sale orders from the customers which are intimated to Production team manually to keep the analysis; but based on the forecast order details they are not executing anything; once the sale order is confirmed by the customer then then only the production teams will do the planning (MRP) and production execution.
How can i send the forecast sale order details to production through system on for his analysis purpose.
But we need to use strategy 20 for our business.
Please tell how to resolve our requirement.
Thanks in Advance !!
Thanks,
KesavaHello
If i understood your business requirement, you want to see the sales order on MD04, but you don't want to plan it until the customer confirmation. Is that right?
On the requirement class customizing (transaction OVZG) there is a setting called 'No MRP', where you can set the value '1 - Requirement not planned, but displayed'.
Your sales order should be created with a requirement type assigned to this requirement class. Later, when the customer confirm the order, you should change the requirement type to the default used by strategy 20.
BR
Caetano -
Help with material group and customer
this is what i'm trying to do. i've segregated all my ferts into material groups. now when i go into va01 to create sales order and enter customer, i want it the system to suggest material that is only relevant for that customer, by material group, not by sales view which is the current setting. is there a way i can link customer to a material group? and if i do that will it suggest material for that customer when i goto the line item to enter material??
Dear Friend,
Frist difference Dynamic Product Proposal & Listing / Exclusion:
Dynamic Product Proposal is just list of Materials that is proposed as soon as you enter Customer Code in Sales Order. Customer can order materials that are not contained in Dynamic Product Proposal. It is for ease of Order Entry.
Listing / Exclusion is a List of maintained in system which restricts Customer to Order mateirals not mentioned in LIsting,
Thus in your case List / Exclusion is better option
As far as Config is concerned if you want to restrict the Materials based on Customer Code then no config. changes is required because the standard table 001 (Customer / Material) is already available.
Just maintain Condition Record in VB01 & try to create Sales Order. You will clearly see the effect.
Only config. you will need is this:
IMG - Sales and Distribution - Basic Functions - Listing/Exclusion - Activate listing/exclusion by sales document type (To activate Listing / exclution for your Sales Document Type. Maintain A00001 & B00001 here.
Hope this helps.. .
Thanks,
Jignesh Mehta -
Disable Delete icon in Material Requirements from
hi
can anyone tell me how to disable the "Delete" icon and the "Delete option" in the "Edit menu" in the Material requirements form in WIP.
is it possible through form personalization??
is yes, please tell me the method...
reply
thanks
anandcHi,
check the program name for the transaction and create a screen exit for the same.
Also u can go for copying the code in customer namespace and then add ur own functionality to dactivate or remove the delete function.
Pls reward points for the answer.
Regards,
Ameet -
Pass on Material requirements to MRP areas within Plant
- We are on ECC 6.0 & have a scenario wherein material requirements from depots are passed on to respective plants according to the settings defined in the Special Procurement key in the Material Master (MRP View)
- The requirement from depots are passed on to the manufacturing plant & further down to the Plant in which MRP areas are defined, in the form of Planned Orders, if the stock is not sufficient at depot.
- For Subcontracting, we have various MRP areas within a single separate plant. The requirement is that PR that is generated for STO should be able to pass the requirement to an MRP area (after stock checking at MRP area level), (system to decide the MRP area to be selected for passing on the requirements).
- Currently the system is passing the requirements & checking the stock at plant level only.
- Stock determination rules donu2019t seem to work here.
- The opening up of the u2018Issue storage locationu2019 in STOu2019s by config: (u201CPurchase order-> - Set up Stock Transport order - > Set up Stock Transfer between storage locationsu201D) is yet to be tested.
- But in that case, only a single MRP area is defined for the material & therefore the requirements may flow directly to that particular MRP area. In case of Multiple MRP areas being defined for a single material, how can we ensure that the system determines a stock checking at one particular MRP area & pass on the requirements to it.
Seeking guidance as to how this issue can be resolved.
Precisely,
REQ.FRM>FLOW TO>AS (MRP element)
Depot>Plant 1>Planned order (PlOrd)
Plant 1>Plant 2>Material reservation (MtlRes)
Plant 2>MRP area of Plant 2>Transfer reservation (TrnRes)dear colleague,
Please check the following info that can be useful:
1) Note 358936 is relevant for MRP areas of type storage location and
not for Subcontractor MRP areas (which you would be knowing).
2) Secondly this note was created as an advance development and not
for any particular customer problem. It was also feasible to
develop this functionality with a small change.
3) The feature of procurement with Schedule lines for components
in subcontractor MRP areas is not available in the standard SAP
suite and there are no plans to develop this in the near future.
This feature would be an advance development.
best regards -
Material Requirement for the Lot Based Job
Hi,
I'm creating an Lot based Job through the request 'Import Lot Based Jobs' . I need to insert values into the table Wip_Requirement_Operations. That is the Lot Based Job form -> Press button component - > Material Requirement Form
I would like to know whether there is any interface available for loading the value into this table.
Can anyone help me in this ?
Thanks
GMOracle Manufacturing APIs guide is not clear on this subject.
Lot based job are loaded through interface WSM_LOT_JOB_ INTERFACE and one option is ALLOW_EXPLOSION which tells if the BOM used is the standard one or if you provide a custom BOM . In this case, the user guide does not provide you any method.
(it tells : ALLOW_EXPLOSION: determines whether the system uses the standard bill of
material (BOM) and routing or a custom BOM and routing that you supply. If
this flag is set to N or n, you must manually provide a custom BOM )
=> You should ask Orcle how the custom BOM should be provided to the Lot based job interface.
I do not know if this is the same as for discrete jobs:
For discrete jobs, such data are loaded through interface table WIP_JOB_DTLS_INTERFACE.
Maybe once you have created your job, you can use this WIP_JOB_DTLS_INTERFACE to load component requirements ? -
Hi All,
How to create a Platinum,Gold and Silver Customer and how to set different price for a single material based on customer?
Assume Material is Pen.
While creating Sales Order in VA01 how to bring different price for the same material for Platinum,Gold and Silver Customers.
Kindly help me out.
Thanks,
Renjith JoseA good place to start is http://www.javaworld.com/javaworld/javatips/jw-javatip34.html
Also, do a search in this forum on HttpURLConnection. That class allows you to use POST method to send form data to a web server.
"Hidden" variables are only hidden in HTML. The HTTP that gets POSTed to the web server doesn't distinguish between hidden and not hidden. That is, the content you would write to the HttpURLConnection.getOutputStream() would be something like:
hidden=1&submit=ok(Of course, the variable names would depend on what the web server was expecting from the form.)
Also, be sure to set the Content-Type request parameter to "application/x-www-form-urlencoded" -
Creating a planned order with error "Material requires configuration"
Dear All,
I am facing a problem for creation of a planned order with error "Material requires configuration".
To follow the note 180317, I change Account Assignment Category to "U" (Unknown).
However, the system still does display the same error.
Could you please help provide possible solution for this?
Regards,
PhongSee also the following blog post:
Configurable planned order for material variants: Exception "53: No BOM explosion due to missing configuration"
BR
Caetano -
Creation Indicator in PR: B Material Requirement planning
Hi All,
I am facing an unusal scenario.
User is claming that PR is getting generated for a material after running the MRP, even there is enough stock.
I checked material & I found that MRP type is ND, there is no entry in the planning file for this material.MRP list & stock requirement list of this material is showing nothing. So there is no way that PR will be created automatically via MRP run for this material.
When I checked one PR for this material, Plant & storage location, creation indicator is showing as B Material Requirement planning.
Could you please help me that why creation indicator is showing as B>
I further checked these PRs are created long back when MRP type was V1. Later they changed it to ND.
How to delete MRP generated PR manually when PO has been created for these PR.
Regards
Shilpi
Edited by: sapmm1234 on Dec 14, 2011 6:10 PMAs you said; the PR was created long ago by MRP, when it was not ND.
If it was already converted into a PO, there's no need to delete it, right? If not, just delete it manually.
In the future, when you change MRP type from a valid type to ND, always remember to do 2 additional things, as the system will not do them automatically:
1- delete the MRP list
2- delete any planning elements if they exist, like planned orders and MRP generated PRs. -
How to issue the non stock material to the customer place through delivery?
Dear All,
I have created a service order with one operation,and for executing the operation i need one spares material which should be sent to the customer place.So i put that as non stock item in the line item of the order.
Result : It Creates PR with account assignment and with reference to the PR i craeate a PO with the same account assignment order.
Now when i take MIGO against the PO,it is directly consumed to the order,wherein i have to send that material to the customer place and then consume.
How can i handle this process.
Regards,
VenugopalHi,
The material which u sending to Customer place mark those item as return in Purchase order and then do Goods movement by 161. If that material is non val. then No Accounting will generate.
Vikramraj
Maybe you are looking for
-
Why is my mid-2010 macbook pro having trouble booting and crashing?
I have a mid-2010 13 inch macbook pro that has recently began to have severe problems. It started after I shut it down one night and woke up to the sound of my mac's fans running loudly and my computer running extremely hot. Apparently, it must not h
-
ITunes Will Not Open and I have Tried Everything Posted...
Please Help! I have downloaded the latest version, deleted it and tried again. I have deleted folders, turned off my Norton protection and still no go. Can anyone here help me from this 7 hour nightmare? I had an iPod and iTunes on this computer befo
-
How can i remove the phone number from the text messages that i receive in the notification center
how can i remove the phone number from the text messages that i receive in the notification center?
-
I have tons of .mov files, but none of them are playing any audio since I upgraded to 7.1. Has anyone had a similar problem? Windows XP Pro
-
How to make QT the default internet player?
How do I make QT the default internet player?