Wednesday, February 27, 2013

BW SD MM FI DATASOURCES


MM 

Data Sources Tables
Purchasing
2LIS_02_SCL EKKO, EKBE, T001, T001W, EKET, EKPA.
2LIS_02_HDR EKKO, EKBE, T001, EKPA.
2LIS_02_ITM EKKO, EKBE, T001, T001W, EKPO, TMCLVBW, T027C, ESSR, T147K, T147
2LIS_02_SCN EKET, EKES, EKPO.
2LIS_02_CGR EKBE, EKES, EKPO.
2LIS_02_SGR EKET, EKBE, KKPO

Inventory
2LIS_03_BX stock tables, MCHA, MARA, T001, T001W, CALCULATED FROM MBEW, EBEW, QBEW.
2LIS_03_BF MSEG, MBEW, MKPF.
2LIS_03_UM BKPF, MBEW, QBEW, EBEW, BSEG.
MM   
Purchasing   Datasources
ODS  
 0PUR_O01  2LIS_02_ITM, 2LIS_02_SGR, 2LIS_02_CGR, 2LIS_02_SCN.
 0PUR_O02  2LIS_02_HDR, 0PUR_O01
 0PUR_DS03  2LIS_02_SCL and 2LIS_02_SGR.
CUBE  
 0PUR_C10  2LIS_02_SCL and 2LIS_02_SGR.
 0PUR_C07  
 0PUR_C08  
 0PUR_C09  0PUR_O02, 80PUR_O01, 2LIS_02_HDR
 0SRV_C01  2LIS_02_S174
 0PUR_C04  2LIS_02_S011, 2LIS_02_SCL, 2LIS_02_ITM, 2LIS_02_HDR
 0PUR_C01  2LIS_02_S012, 2LIS_02_ITM, 2LIS_02_SCL
 0PUR_C02  2LIS_02_S013
 0PUR_C05  0MM_PUR_VE_01
 0PUR_C06  0MM_PUR_VE_02
 0PUR_C03  2LIS_02_S015
Inventory Management  
CUBE  
 0IC_C03  2LIS_03_BX, 2LIS_03_BF, 2LIS_03_UM
 0IC_C02  2LIS_03_S195, 2LIS_03_S197
 0IC_C01  2LIS_03_S196, 2LIS_03_S198
SD 
 Data sources Tables
 2LIS_11_VAKON VBUK, VBUP, VBAK, VBAP, VBKD, KOMV, T001.
 2LIS_11_VAHDR VBAK, VBUK, T001
 2LIS_11_VAITM VBAP, VBUP, VBAK, VBKD, VBAJP, T001, VBUK, PRPS.
 2LIS_11_VASCL VBAP, VBUP, VBAK, VBEP, VBKD, T001, PRPS
 2LIS_11_VASTH VBUK
 2LIS_11_VASTI VBUP, VBUK
 2LIS_11_V_ITM VBAP, VBAK, VBKD, VBUP, T001, PRPS, VBUK.
 2LIS_11_V_SCL VBUP, VBEP, VBKD, VBAP, VBAK, T001, PRPS.
 2LIS_11_V_SSL VBAP, VBEP, LIPS, WVBEP, VBUP
 2LIS_13_VDKON VBUK, VBRP, KOMV, T001, VBRK.
FI 
 DATASOURCES Tables
Cost Center Accounting 
 0CO_OM_CCA_1 COSP, COSS
 0CO_OM_CCA_2 COSP, COSS
 0CO_OM_CCA_3 COSL, COKL.
 0CO_OM_CCA_4 COSR
 0CO_OM_CCA_5 COSB
 0CO_OM_CCA_6 COOMCO
 0CO_OM_CCA_7 BPJA, BPPE.
 0CO_OM_CCA_8 COST, TKA07,COOMCO, CSLA, COST, COKL.
 0CO_OM_CCA_9 COVP (COEP& COBK), COSP, COST, COEJ, COEP, T001.
 0CO_OM_CCA_10 COOI, COSP_VTYPE.
Product Cost Controlling 
 0CO_PC_PCP_01 KEKO, TCKH3, TCKH8.
 0CO_PC_PCP_02 KEKO, TCKH3.
 0CO_PC_PCP_03 CKIS, T001K, TKA02, KEKO, MARA, MBEW.
 0CO_PC_PCP_04 CKIS, T001K, TKA02, KEKO, MBEW, MARA
 0CO_PC_01 AUFK, AFPO, COSS, COSP, COSB, COSL, COKEY, TKA09, TKV09
 0CO_PC_02 AUFK, AFPO, COSS, COSP, COSB, COSL, COKEY, TKA09, TKV09

Wednesday, February 13, 2013

V1 and V2 Update Modules


V1 and V2 Update Modules Locate the document in its SAP Library structure
An update is divided into different modules (see also Update Request). Each module corresponds to an update function module.
There are two types of module.
The SAP System makes a distinction between primary, time-critical (V1) and secondary, non-time-critical (V2) update modules. The system also supports collective runs for function modules that are used on a regular basis.
This distinction allows the system to process critical database changes before less critical changes.
  • V1 modules describe critical or primary changes; these affect objects that have a controlling function in the SAP System, for example order creation or changes to material stock.
  • V2 modules describe less critical secondary changes. These are pure statistical updates, for example, such as result calculations.
The V1 modules are processed consecutively in a single update work process on the same application server. This means that they belong to the same database LUW and can be reversed. Furthermore, V1 updates are carried out under the SAP locks of the transaction that creates the update (see  The SAP Lock Concept). This ensures that the data remains consistent; simultaneous changes to the objects to be updated are not possible.
All V2 updates are carried out in a separate LUW and not under the locks of the transaction that creates them. If your SAP System contains a work process for V2 updates, these are only carried out in this work process. If this is not the case, the V2 components are processed by a V1 update process.
All V1 modules of an update must be processed before the V2 modules.
Example
Let us assume that a transaction makes planning changes to a material and balance sheet, and updates two sets of statistics.
Each of these changes is represented by means of an update module (call update function module) in the update request - the two planning changes by a V1 update module (time critical), and the statistical changes by a V2 update module (less critical). (The V1 modules have priority, although the V2 modules are usually also processed straight away).
This is described in greater detail in the section entitled The Update Process.

Friday, February 1, 2013

What is tickets? Ticketing examples



The typical tickets in a production Support work could be:
1. Loading any of the missing master data attributes/texts.
2. Create ADHOC hierarchies.
3. Validating the data in Cubes/ODS.
4. If any of the loads runs into errors then resolve it.
5. Add/remove fields in any of the master data/ODS/Cube.
6. Data source Enhancement.
7. Create ADHOC reports.
1. Loading any of the missing master data attributes/texts - This would be done by scheduling the info packages for the attributes/texts mentioned by the client.
2. Create ADHOC hierarchies. - Create hierarchies in RSA1 for the info-object.
3. Validating the data in Cubes/ODS. - By using the Validation reports or by comparing BW data with R/3.
4. If any of the loads runs into errors then resolve it. - Analyze the error and take suitable action.
5. Add/remove fields in any of the master data/ODS/Cube. - Depends upon the requirement
6. Data source Enhancement.
7. Create ADHOC reports. - Create some new reports based on the requirement of client.
Tickets are the tracking tool by which the user will track the work which we do. It can be a change requests or data loads or whatever. They will of types critical or moderate. Critical can be (Need to solve in 1 day or half a day) depends on the client. After solving the ticket will be closed by informing the client that the issue is solved. Tickets are raised at the time of support project these may be any issues, problems.....etc. If the support person faces any issues then he will ask/request to operator to raise a ticket. Operator will raise a ticket and assign it to the respective person. Critical means it is most complicated issues ....depends how you measure this...hope it helps. The concept of Ticket varies from contract to contract in between companies. Generally Ticket raised by the client can be considered based on the priority. Like High Priority, Low priority and so on. If a ticket is of high priority it has to be resolved ASAP. If the ticket is of low priority it must be considered only after attending to high priority tickets.
Checklists for a support project of BPS - To start the checklist:
1) Info Cubes / ODS / data targets 2) planning areas 3) planning levels 4) planning packages 5) planning functions 6) planning layouts 7) global planning sequences 8) profiles 9) list of reports 10) process chains 11) enhancements in update routines 12) any ABAP programs to be run and their logic 13) major bps dev issues 14) major bps production support issues and resolution .

What are the tools to download tickets from client? Are there any standard tools or it depends upon company or client...?
Yes there are some tools for that. We use Hpopenview. Depends on client what they use. You are right. There are so many tools available and as you said some clients will develop their own tools using JAVA, ASP and other software. Some clients use just Lotus Notes. Generally 'Vantive' is used for tracking user requests and tickets.
It has a vantive ticket ID, field for description of problem, severity for the business, priority for the user, group assigned etc.
Different technical groups will have different group ID's.
User talks to Level 1 helpdesk and they raise ticket.
If they can solve issue for the issue, fine...else helpdesk assigns ticket to the Level 2 technical group.
Ticket status keeps changing from open, working, resolved, on hold, back from hold, closed etc. The way we handle the tickets vary depending on the client. Some companies use SAP CS to handle the tickets; we have been using Vantage to handle the tickets. The ticket is handled with a change request, when you get the ticket you will have the priority level with which it is to be handled. It comes with a ticket id and all. It's totally a client specific tool. The common features here can be - A ticket Id, - Priority, - Consultant ID/Name, - User ID/Name, - Date of Post, - Resolving Time etc.
There ideally is also a knowledge repository to search for a similar problem and solutions given if it had occurred earlier. You can also have training manuals (with screen shots) for simple transactions like viewing a query, saving a workbook etc so that such queried can be addressed by using them.
When the problem is logged on to you as a consultant, you need to analyze the problem, check if you have a similar problem occurred earlier and use ready solutions, find out the exact server on which this has occurred etc.
You have to solve the problem (assuming you will have access to the dev system) and post the solution and ask the user to test after the preliminary testing from your side. Get it transported to production once tested and posts it as closed i.e. the ticket has to be closed.