You can define new partner functions for those existing in the standard (sold-to party, ship-to party, bill-to party, payer).
Copy new partner function ‘representative number’ from the interface. Use Report RV60AFZA as a user exit:
FORM USEREXIT_AVBPAK_ADD. MOVE "VE" TO AVBPAK-PARVW. IF NOT XKOMFKGN-VRTNR IS INITIAL. AVBPAK-PERNR=XKOMFKGN-VRTRNR. ENDIF.
It is not yet possible to use user exits for document flow update with new partner functions.
See also:
The topic on updating the document flow in Working with User Exits.
Deviating CpD address data
In order to process deviating CpD address data in different partner functions using the general billing interface, you must modify the INCLUDE structure KOMFKZZ according to table structure
KOMFKGN as well as the user exit USEREXIT_AVBPAK_CPD (Report RV60AFZB).
There are, however, several limitations:
• The sold-to party (partner function AG) must be a CpD customer
• The bill-to party (partner function RE) must not be a CpD customer
• User exit USEREXIT_AVBPAK_CPD can only be used as delivered in the standard system
Another example:
• The sold-to party is a CpD customer
• The CpD address is valid for the sold-to party and bill-to party, independent of whether the partners are CpD customers
• The ship-to party has a different CpD address
• Sample report RVAFS01 which creates the sequential file would then contain the following coding:
* CpD fields
WA_KOMFKGN-CPD_PARVW1 = ‘AG’
WA_KOMFKGN-CPD_PARVW2 = ‘RE’
WA_KOMFKGN-CPD-ANRED = ‘Mr.’
WA_KOMFKGN-NAME1 (length 30) = ‘FIRST_CPD_NAME’
WA_KOMFKGN-LAND1 = ‘US’
WA_KOMFKGN-PSTLZ = ‘99999’
WA_KOMFKGN-ORT01 = ‘New York’
* Different address - Ship-to party (CpD customer)
WA_KOMFKGN-WE_PARVW = ‘WE’
WA-KOMFKGN-WE_ANRED = ‘Ms.’
WA_KOMFKGN-WE_NAME1 (length 30) = SECOND_CPD_NAME
WA-KOMFKGN-WE_LAND1 = ‘US’
WA_KOMFKGN-WE_PSTLZ = ‘9999’
TRANSFER WA_KOMFKGN TO DS_NAME1....
Partner functions in the billing document would appear as follows:
Billing document FX
Partner function Partner Name
SP Sold-to party ODL-CPD FIRST_CPD_NAME
BP Bill-to party ODL FIRST_CPD_NAME
PY Payer ODL Address in customer master
SH Ship-to party ODL-CPD SECOND_CPD_NAME
To add a different CpD address for all partners other than the sold-to party, change the user exit. Another example:
The sold-to party is a CpD customer
The CpD address is valid for the sold-to party A different CpD address is valid for all other partners
Sample report RVAFSS01 which creates the sequential file would then contain the following coding:
* CpD fields
WA_KOMFKGN-CPD_PARVW1 = ‘SP’
WA_KOMFKGN-CPD_ANRED = ‘Mr.’
WA_KOMFKGN-NAME1 (length 30) = ‘FIRST_CPD_NAME’
WA_KOMFKGN-LAND1 = ‘US’
WA_KOMFKGN-PSTLZ = ‘99999’
WA_KOMFKGN-ORT01 = ‘New York’
* Different address - Ship-to party (CpD customer)
WA_KOMFKGN-WE_PARVW = ‘XX’ (e.g. ‘BP’, ‘SH’, etc.)
WA-KOMFKGN-WE_ANRED = ‘Ms.’
WA_KOMFKGN-WE_NAME1 (length 30) = ‘SECOND_CPD_NAME’
WA-KOMFKGN-WE_LAND1 = ‘CH’
WA_KOMFKGN-WE_PSTLZ = ‘9999’
WA_KOMFKGN-WE_ORT01 = ‘Basel’
TRANSFER WA_KOMFKGN TO DS_NAME1.
Partner functions in the billing document would appear as follows:
Billing document FX
Partner function Partner Name
SP Sold-to party ODL-CPD FIRST_CPD_NAME
BP Bill-to party ODL SECOND_CPD_NAME
PY Payer ODL SECOND_CPD_NAME
SH Ship-to party ODL-CPD SECOND_CPD_NAME
User exit RV60AFZB appears as follows (changes can be identified by an ‘*’ at the beginning of the line):
IF XKOMFKGN-WE_PARVW NE SPACE. LOOP AT AVBPAK.
LOOP AT AVBPAK WHERE PARVW EQ XKOMFKGN-WE_PARVW.
MOVE '00000000'TO AVBPAK-ADRNR.
MOVE AVBPAK-PARVWTO AVBPAK-ADRNR(2).
*MOVE XKOMFKGN-WE_PARVWTO AVBPAK-ADRNR(2).
MOVE 'B' TO AVBPAK-ADRDA. MOVE 'X' TO AVBPAK-XCPDK. MODIFY AVBPAK.
*ENDLOOP.
CLEAR XVBADR.
MOVE '0000000'TO XVBADR-ADRNR.
MOVE AVBPAK-PARVWTO XVBADR-ADRNR(2).
MOVE XKOMFKGN-WE_PARVWTO XVBADR-ADRNR(2).
MOVE XKOMFKGN-WE_ANREDTO XVBADR-ANRED. MOVE XKOMFKGN-WE_NAME1TO XVBADR-NAME1. MOVE XKOMFKGN-WE_PSTLZTO XVBADR-PSTLZ. MOVE XKOMFKGN-WE_ORT01TO XVBADR-ORT01. MOVE XKOMFKGN-WE_LAND1TO XVBADR-LAND1. APPEND XVBADR.
* Fehlerprotokoll (Error log) *
PERFORM GN_CPD_CHECK USINGSY-SUBRC XKOMFKGN-WE_LAND1 *XKOMFKGN-WE_NAME1 *XKOMFKGN-WE_PSTLZ *XKOMFKGN-WE_ORT01. * *IF SY-SUBRC NE 0. EXIT. ENDIF. ENDLOOP. * ENDIF. ENDFORM.
Scheduling Agreements
Purpose
A customer scheduling agreement is an outline agreement with the customer containing delivery quantities and dates. These are then entered as schedule lines in a delivery schedule. You can either create schedule lines when you create the scheduling agreement or you can create them later.
You fulfill a scheduling agreement by creating the deliveries in the schedule as they become due. You process deliveries for a scheduling agreement in exactly the same way as you process a
normal delivery. After you have carried out the delivery, the system updates the Delivered
quantity field in the scheduling agreement item with the delivery quantity. The following graphic
shows the document flow for scheduling agreements.
Integration
You would use this component if you had outline agreements with the customer that contained future delivery quantities of materials that would be sent at certain times within a fixed time period.
If you work with scheduling agreements for the component supplier industry you also need to choose the "Electronic Data Interchange" (EDI) component.
Features
The same functions are at your disposal for processing scheduling agreements as there are for the sales order, including pricing and availability checks.
In addition to the standard scheduling agreements you can also manage scheduling agreements for the component supplier industry, with their special features that include:
• Working with scheduling agreements with EDI output
• Entering scheduling agreements in a forecast or just-in-time (JIT) delivery schedule
• Using different types of cumulative quantities
• Managing engineering change statuses
• Storing packing proposals
• Creating correction deliveries for the scheduling agreement
• Working with external service agents