on 09-28-2011 11:59 AM
Hi,
Scenario - Allocation check in APO with SO creation in ECC.
Allocation is maintained for following char combination in APO (/sapapo/ac42)
Product allocation object - ABC
Product number - 123456
Sold to Party - ####################
Sales Org. - ####
Query :-
1. Why, in the 1st place, system is not
e.g. char combination - ABC
123456
8765 (sold to party)
3333 sales org (sales org)
2. Allocation check is getting triggred at this level during SO creation but system is not considering the allocated quantity.
System is confirming all the quantity even when it is more than allocated quantity at this level.
Anything to do with wildcard (masking indicator)?
Regards,
RS
Hi,
Check Sold to party char length characteris of collective cvc in Product allocation group and at Planning area.
Planning areas info object and /SAPAPO/KOMGO comp data format should match (length char). In you case number of # for customer in cvc from Planning area and Product allocation.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
error in sequence...
reposting the query ---
Scenario - Allocation check in APO with SO creation in ECC.
Allocation is maintained for following char combination in APO (/sapapo/ac42)
Product allocation object - ABC
Product number - 123456
Sold to Party - ####################
Sales Org. - ####
queries --
1. Allocation check is getting triggred at the level mentioned above during SO creation but system is not considering the allocated quantity.
System is confirming all the sales order quantity even when it is more than allocated quantity at this level.
Anything to do with wildcard (masking indicator)?
2. Why, in the 1st place, system is not checking the allocations at the level where all the 4 chars have values and allocation maintained for that combination (/sapapo/ac42)?
e.g. char combination - ABC
123456
8765 (sold to party)
3333 (sales org)
Regards,
RS
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi,
1. it has probably nothing to do with the wildcards character. Possible reasons might be: you run the product allocation check in neutral mode ? You consider further buckets ...check forwards and backwards consumption settings ! You trigger production after the allocation check ?
2. recheck the customizing of your allocation procedure with TA: /SAPAPO/ATPCQ_CHECK
Does the report show differences between the lengths of infoobject for sold-to and the KUNNR field ?
The field KUNNR in R/3 has only 10 digits. In APO a customer can have 20 digits. In the communication structure
/sapapo/komgo, the customer has also 20 digits.
- Choose an info object for the Sold-to which has 20 digits. You also have to use the conversion routine 'ALPHA', so you do not have to manually add the leading zeros. This is important (Txn: //MSP_ADMIN)
- This then has to be mapped to the field KUNNR in the allocation customizing.
- Then you have to delete the existing char combination from the infocube and from the product allocation char directory.
- You then recreate the char combinations in transaction /sapapo/mc62 with the conversion routine mentioned above in place.
- Then you transfer the char combs to the product allocation directory.
The last step is to map the char combinations sent from R/3 with the ones from APO. Unfortunately, in this special case, this is only possible by using a customer-exit in the product allocation area.
You have to use customer-exit EXIT_/SAPAPO/SAPLATPQ_018 in SAP APO
extension 'APOQT018'.
There you place the following code:
.....
data: lv_cust20 type char20.
field-symbols:
<atpfield> type /SAPAPO/ATPFIELD.
loop at ct_atpfield assigning <atpfield>
where kfdna eq 'KUNNR'
or kfdna eq 'PKUNAG'
or kfdna eq 'PKUNRE'
or kfdna eq 'PKUNRG'
or kfdna eq 'PKUNWE'.
lv_cust20 = <atpfield>-value.
CALL FUNCTION 'CONVERSION_EXIT_ALPHA_INPUT'
EXPORTING
INPUT = lv_cust20
IMPORTING
OUTPUT = lv_cust20.
<atpfield>-value = lv_cust20.
endloop.
.....
This will make sure that the characteristics sent from R/3 will be converted from 10 to 20 digits.
Afterwards the system should be able find the correct char combination during the ATP check and during the update.
best regards,
Michael
User | Count |
---|---|
9 | |
4 | |
3 | |
2 | |
2 | |
1 | |
1 | |
1 | |
1 | |
1 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.