SAP Logistics

Standard SAP provides routine to maintain at output procedure level to trigger output type when post goods issue is completed.  But however, SAP hasn't given any routine to trigger output when packing status is incomplete. To enable this functionality, we have to create a new custom routine in the 9* series with the below logic and assign it to the respective output type in the output determination procedure. IF  KOMKBV2-PKSTK = 'C' AND ( KOMKBV2-KOSTK EQ 'C' ).     SY-SUBRC = 0.   ELSE.     SY-SUBRC = 4.   ENDIF.

Ideally Storage Location is determined through standard SAP functionality maintained at delivery type level based on the below criteria : Shipping point + Plant + Storage Condition (MALA) Plant + Situation + Storage Condition (RETA) but however, if business requires to deviate from standard SAP criteria then we have to leverage the below exit to accomplish the requirement : V02V0002  EXIT_SAPLV02V_002

 RKANBU01 - Transfer Purchase Requisition and Purchase Order Commitments RKACOR04 - Adjustment Betw. Line Items and Totals Records (Act.Cost + Commitment) CJEN - Reconstruct Project info database CJBN -  Re-construct availability check for projects S_ALR_87013558 - Budget - Actual - Commitment report

Automatic POD Concept For customer proof-of-delivery (POD) confirmations for an outbound delivery, you can define a time window in which the confirmation from the customer must occur. This time window is specified in units of days and stored in the field 'POD timeframe' of the customer master data for the sales area (KNVV-PODTG). If the current date and time in the local time zone (!) of the user running the transaction lies before the end of the time window, the transaction / program does NOT process the delivery, because the confirmation of the customer could still happen.   Logic for POD date calculation The end of the time window in which the POD is expected from the customer is calculated as the delivery date (LIKP-LFDAT) plus the POD timeframe as a net duration. Net duration means that only the working hours according to the factory calendar of the delivery (LIKP-KNFAK) are used for this scheduling. The factory calendar of the delivery is usually determined from the calen

  Proforma invoice Goods issue is not required to create delivery related proforma invoice. Order related billing document If business requires to raise invoice before goods are delivered to customer or Service items then order related billing document is used Delivery related billing document If business requires to deliver goods to customer before raising commercial invoice then delivery related billing document is used

Shipping Point 1 As soon as the material availability date or the transportation scheduling date for a schedule line is reached, the schedule line becomes due for shipping. I.e., Order will be displayed in the delivery due list VL04. Point 2 Delivery block can be controlled in Sales document type (Header Level) and Schedule line Category (Schedule line level) Point 3 Delivery status of an order is updated upon creation of the delivery document. Delivery status is updated at header and Item level of sales document Point 4 Shipping Point Determination Shipping point is an independent organisation unit within which processing and Monitoring of the deliveries as well as goods issue is carried out. A delivery is processed by one shipping point only. Shipping point can be determined for each item based on the below criteria. Shipping conditions from customer master data + Loading group from Material master record + Delivering Plant. Delivery can be process

Message type ' CRESTA ' (FM -  IDOC_INPUT_CRESTA )  is used to distribute the credit management information between SAP systems and Non-SAP to SAP systems in case of business uses central finance. Standard SAP has provided transaction Code 'FCV1' is create A/R summary report which will subsequently generate CRESTA IDoc with customer credit information. This program creates A/R summary data within a control area per credit account. This data can then be used either within distributed credit management, or in a non-distributed system. CRESTA IDoc will not update the credit master data (FD32) in the the target system instead it will update  A/R summary data in the credit master data. In technical terms, System will not update table KNKK ( Credit Master data) instead it updates KNKKF* tables (Credit Management: FI Status Data). While creating the sales order, system will perform credit check based on the data from