on 10-23-2015 10:51 AM
Dear all,
I have an Output condition problem while creating Invoice.s
Customizing:
For the Output Types while invoicing, I have created an Output type YREL which is connected to a specific requirement 890 (as specified in the Access sequence).
This Output type is also part of the Output Determination Procedure Z10099 which is connected to a specific requirement 962.
Both requirements are not basically doing anything more than setting sy-subrc = 0.
Conditions:
I have set up an Output condition through NACE for YREL using the Fields VKORG and LAND1.
Now, if I save an invoice now and look through debugging, both requirements 890 and 962 are OK --> Setting sy-subrc = 0.
But the condition YREL is not appearing. If you look in to the Determination Analysis, I can see the message for YREL:
"Access not executed (Requirement not fulfilled)"
Problem: The Requirement is blank! I cannot see which one is not fulfilled! Does anybody have an idea why it is not showing? Is that a common Problem?
Thanks and Best Regards,
Debashish
Hi Debashish,
Just to verify, please check your NACE settings for your output type.
the Storage mode in the tab storage system should be either "1. Print only" or blank.
If you are not using an invoice archiving and the storage mode is selected as option 2 or 3 then the output wont be process or determine.
for a testing purpose first you can change the storage type in your output condition determined in the billing document in "communication method"
Regards,
Lalit
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Debashish,
As members have asked, please explain the logic (condition) in each of these requirements:
both requirements 890 and 962
which is at output procedure level and which is at table level?
TW
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi
The System takes the requirement assigned at the O/P Determination procedure, as the 1st priority.
Once the O/P condition type is determined, the condition records determination come into picture.
Pls check, by removing the requirement at access sequence level & see, if the requirement given at the procedure is displayed.
BR
Sumanth G
requirement 890:
If T683S-kSCHL eq 'YREL'
and komkbv-erdat ge '20120803'.
sy-subrc = 0.
Endif.
requirement 962:
sy-subrc = 4.
CHECK : KOMKBV3-UVALL CA ' C'.
sy-subrc = 0.
We have reasons to split the requirements, but currently (for testing purposes) we use it only with this. When debigging, they are both ending up as sy-subrc = 0 --> valid.
Your 890 requirement seems a bit odd - probably you did not type it correctly in the response.
1. Aren't you supposed to set sy-subrc to a non-zero value before executing the check?
2. komkbv-erdat - where did you get that from? I know of no such standard structure - there is komkbv3, but I see no erdat field in it. Probably you meant a selection from NACH? Please consult with your developer - the logic does not make much sense even if it is a requirement for testing purposes.
VOFM routines have KOBEV and KOBED parts - which one did you paste?
How did you get it to compile successfully?
This would result in syntax error (unless you have extended KOMKBV3 with ERDAT field).
If you have extended the print structure with a new field you are expected to fill it at some point if you wish to use it. What is the logic implemented and have you validated it?
If you have not extended KOMKBV3 with ERDAT:
Of course you would be able see the error only if you have rebuilt the object list and have activated the routine.
Are you absolutely sure that the program actually goes through this code and sets sy-subrc to 0 as a result (breakpoint at the IF statement)? If I remember correctly, in case the result of the precondition (KOBEV) sets sy-subrc to a non-zero value, the actual condition table for will not be taken into account at all.
Probably asking one of the developers in your company to assist you in creating the VOFM routines or using the ones provided in standard would be a more effective way to resolve the issue.
I have Extended the structure KOMKBV3 with erdat. I am absolutely sure that the Programm goes through this code,, has the correct values for erdat and Ends up sy-subrc = 0. 100 % Sure! sy-subrc is always Zero in those routines. The other developers also cannot find out what to do, because this error makes no sense.
I have not asked that before, but in NACE for YREL Access to conditions is set to 'X', is this correct?
If the output determination does not work even after you have removed both requirements - have you checked for custom logic in the user exits?
If you are unable to find any logic in a user exit that might cause such behaviour - then there is still the really ugly solution - to continue with F5 after getting sy-subrc = 0 from your routine... you will get at some point where the condition record will be removed.
Regarding requirement not fulfilled message in the determination screen: please have a look at sap note 2174655, probably the attached corrections could give you some idea on how to capture the actual message.
Since it is a customized routine coded for specific business process, you have to take the help of your ABAP team to see what validation is there due to which, the output is not triggering.
G. Lakshmipathi
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Have you tried to remove the first requirement and test to see if there will be a successful determination, then remove the second one, add the first and test again?
Mnual only indicator is not set, I hope you have checked that already.
Could you share screenshots of your access sequence setup and the output procedure?
Do you get the output determined automatically on any other level?
Try creating condition records for some of the higher acesses and remove requirement 890. This is to eliminate the impact of 962.
Another possibility - I have seen at some clients that in case of determining output type A, output type B should not be determined at all. Check if you have such business cases - if yes, how it was implemented - print requirements, user exits etc.
I believe that at the time you checked EXPKZ, you ensured that all used fields are filled with the correct (expected values), so I am not going to question that part.
User | Count |
---|---|
101 | |
12 | |
11 | |
6 | |
6 | |
4 | |
3 | |
3 | |
3 | |
3 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.