OTC

Purchase Requisition

A requisition order is a form that a department must submit to whichever department controls the financial activities of the business. Although individual forms vary by business, requisition orders generally require certain information, including the department requesting materials, the exact number of supplies requested, a general description of those supplies, the legal name of the supplier and the expected price of the purchase. A requisition order is either approved or denied by the financial department of the business.

Purchase Requisition to Purchase Order

Purchase Order

Once the financial office of a business has approved the requisition order submitted by a department, it issues a purchase order to the supplier of the requested goods. Purchase orders should include certain information, such as the name of the purchasing office, supplies being purchased, ship-to address, payment terms, invoicing instructions and purchase order number. To assist in record keeping, purchase orders will have the same number as the requisition order that generated them.

Account Assignment
Some Purchase Orders can have Account Assignment. They are assigned to give information on who to bill internally. Some examples are
If a PO is assigned Cost Center under Account assignment, then for that PO Cost center is billed(?)
If a PO is assigned Sales Document , that means , the PO was created to satisfy a Sales Order. This is valid in the case, where a company buys some items from 3rd Party vendors and then sells them to their clients.

EKKN table has all POs which are have Account Assignments. If a PO is not present in this table, then is not assigned anything.
TCode : ME2L

Extra notes on Account Assignment https://wiki.scn.sap.com/wiki/display/ERPSCM/Account+assignment+in+purchasing+document

ORDET TO CASH

This is the integration of SD and FI.
https://toughnickel.com/business/SAP-Order-To-Cash-SAP-OTC

Vendor

 Master Data Table : LFA1

TCode : XK01 /02 / 03

Delta Management

Types of Delta

There are different types of delta available

ABR - Complete Delta with Deletion Flag Via Delta Queue
After Before Reverse - Here for every change, there is a Before and After image generated and deletions are captured in Reverse Image.
These can be loaded directly to a cube or DSO.
In cube it is only summation and here, for every change we get a -ve and +ve value.
An after image shows the status after the change, a before image shows the status before the change with a negative sign and the reverse image also shows the negative sign next to the record while indicating it for deletion

For say a quantity is 10 initially and loaded to cube, next time if it changes to 8, we get two records.
Record Mode | 'X' | Before image | -10
Record Mode | '  '  | After image | 8


AIE - After Images Via Extractor
Only the after images flow to BW. For the same example, when the change occurs only one record flows into BW
Value 8.
It cannot be loaded to cube directly as in cube there is only Summation and the value becomes 10+8 = 18.
These extractors need to have a DSO with 'overwrite' feature and 10 gets replaced with 8. There records can further be loaded to cube where dso generates before and after images for cube to handle.

RecordMode | ROCANCEL

ROCANCEL

This is a default field in all datasoures which work on delta - ABR.

Whenever a change occurs, system generates 2 records

ROCANCEL = 'X' -- Old record

ROCANCEL = ' '   -- New record

ROCANCEL = 'R  -- Deleted record

Mapping of ROCANCEL and 0RECORDMODE

For example, your PSA has one PO with 2 line items 10 and 20. Line 10 comes with a change , so there is 'X' record with Old values and ' ' record with  with New values. Line 20 is deleted in source, so Line 20 comes with 'R' image.

ROCANCEL is mapped to 0RECORDMODE in the DSO

This is mostly the way the mapping is done.

ROCANCEL is mapped to RECORDMODE in Technical Rule Group.

Once the DTP is run, you get the PO with 2 Lines - Line 10 with after image value and Line 20 with R to the NEW Data table.

When activated, only Line 10 is added to the DSO. Line 20 is deleted.

0RECORDMODE is blank constant.

Both PO Lines items flow to New Data and then up on activation both lines are available in DSO. you would not know that the entry is deleted in the source. 

In this scenario, what you are making RECORDMODE as BLANK , so when data is being loaded to the DSO, it does not know what kind of record you are loading to the DSO and treats all records as new records and just overwrites them.

0RECORDMODE = 'R'

This is used when you want to delete entries from DSO. If you want to do delete some data using transformation, make 0RECORDMODE = 'R'. So what ever record passes through the transformation is considered as Reverse Image and when loaded to the DSO and activated will get deleted.

Extra Notes : ROCANCEL | RECORDMODE

https://archive.sap.com/kmuuid2/a080ea68-fba2-2e10-8cb7-d42d5bfba09c/0RECORDMODE%20and%20Delta%20type%20Concepts%20in%20Delta%20Management.pdf

Pulling Delta to BW

Steps : 

• Run the V3 jobs in the source ( Either manually / or the standard V3 jobs ). This is only for Queued Delta.
• Check LBWQ entries. Once the V3 jobs run, all the data move from LBWQ to RSA7.
• Run the infopackage to pull data from RSA7 to BW.

RSA7

As you know delta entries to BW are pulled from RSA7 queue. But, sometimes, even when changes are done in PE system, when you pull delta, the new changes donot get pulled to BW. Thats because, these changes didnot come to RSA7 yet.

LBWQ

When changes happen in the source system, they get written to LBWQ .The delta entries, for the datasources of mode 'Queued Delta' get accumulated in LBWQ of the corresponsing queue . Each application component has a different Q. Below is a picture of LBWQ tcode

LBWE V3 Jobs

The way data comes to LBWQ is that, there will be V3 jobs running in the system, which help move the data from LBWQ to RSA7.The V3 jobs are scheduled to run every 15 mins or 30 mins depending on the company. Along with the scheduled job, we can also run the V3 jobs directly from LBWE - Job Control. Below are the V3 jobs in the system.

 1  RMBWV311         

 2  RMBWV312         

 3  RMBWV313         

 4  RMBWV302           

 5  RMBWV303            

some code

Getting Runtime

GET RUN TIME FIELD var_start.

PERFORM f_calculation.

GET RUN TIME FIELD var_end.

var_diff = var_end - var_start.

* Declare var_start.var_end as type 'i'. var_start would be 0 initially.

Getting the -ve number to the starting

var_csign TYPE /BIC/OITDATASOU .

CLEAR:var_csign.

var_csign = var_tranamt.

SEARCH var_csign FOR ‘-‘.

IF sy-subrc EQ 0 AND sy-fdpos NE 0.

SPLIT var_csign AT ‘-‘ INTO var_csign var_sign.

CONDENSE var_csign.

CONCATENATE ‘-‘ var_csign INTO var_csign.

ELSE.

CONDENSE var_csign.

ENDIF.

Notes: Change the datatype to CHAR

Hash Table

DATA :int_target TYPE HASHED TABLE OF y_target

WITH UNIQUE KEY

COMPANYCODE

CCTXTLG

ACCOUNT

ATXTLG

ERPID

ICP

ICPTXTLG

TRANSCURR

DATASOU

LCURR,

wa_target TYPE y_target. * Moving values to Hash Table to use Collect.

LOOP AT it_target INTO ls_target CLEAR:wa_target.

MOVE-CORRESPONDING ls_target TO wa_target.

Moving Field Symbol value to variable

data f1(4) value ‘ABC’.

DATA: v_val TYPE char4 VALUE ‘XYZA’.

field-symbols <f>.

assign f1 to <f>.

write<f>.
<f> = ‘ABD’.

Getting Source System
SOURCE_SYSTEM  = p_r_request->get_logsys( ).

Enabling/Disabling 3.X content
we made the value of one of the filed blank in RSADMINC table Value of field RSAWBN_HIDE_FUNC = ‘X’ in the table rsadminc table we made the value blank for that field this will enable the 3.x functionality

F4 Help code

INITIALIZATION.

AT SELECTION-SCREEN ON VALUE-REQUEST FOR s_obj-low.
  PERFORM f_help_object_class CHANGING s_obj.

*&---------------------------------------------------------------------*
*&      Form  F_HELP_OBJECT_CLASS
*&---------------------------------------------------------------------*
*       text
*----------------------------------------------------------------------*
*      <--P_P_OBJ  text
*----------------------------------------------------------------------*
FORM F_HELP_OBJECT_CLASS  CHANGING P_OBJ. " no definition of p_obj is required

TYPES : BEGIN OF ty_tab,
        object TYPE CDOBJECTCL,
        obtext TYPE CDOBTEXT,
        END OF ty_tab.

DATA : lt_tab TYPE STANDARD TABLE OF ty_tab,
       lt_ret TYPE STANDARD TABLE OF DDSHRETVAL,
       lw_ret TYPE DDSHRETVAL.

"" Here lt_tab is the data you want to see in the output of the F4 help. It is populated using a select statement.
            lt_ret is the standard table used for the FM

SELECT OBJECT OBTEXT from TCDOBT
              INTO TABLE lt_tab
             WHERE spras = 'EN'.

CALL FUNCTION 'F4IF_INT_TABLE_VALUE_REQUEST'
  EXPORTING
*   DDIC_STRUCTURE         = ' '
    RETFIELD               = 'OBJECT'    " This is the field name defined in the internal table you want to see in the output.
    VALUE_ORG              = 'S'           " This is standard. 'C' or 'S' can be used. C didnot work.So 'S' :P
* IMPORTING
*   USER_RESET             =
  TABLES
    VALUE_TAB              = lt_tab
    RETURN_TAB             = lt_ret
 EXCEPTIONS
   PARAMETER_ERROR        = 1
   NO_VALUES_FOUND        = 2
   OTHERS                 = 3
          .
IF SY-SUBRC EQ 0.
  READ TABLE lt_ret INTO lw_ret INDEX 1. " Index 1 is the data row you have selected once the pop up for the F4 help opens. The selected value is present in 'fieldval' field
  p_obj = lw_ret-fieldval.
ENDIF.


ENDFORM.                    " F_HELP_OBJECT_CLASS