Access not executed while creating an output, but requirement is blank

[Former Member]

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

[Lalit]

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

[Former Member]

The Storage mode is 3: Print and Archive. We are using archiving for all invoices. I tried with the changing  but the result is still the same...

[former_member182378]

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

[Former Member]

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

[Former Member]

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.

[Former Member]

I have removed both. but still it is not appearing...do you have any idea of any other Spot where this might be relevant?

[VeselinaPeykova]

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?

[Former Member]

i have changed 890:

KOBED_890:

sy-subrc = 4.

IF T683S-KSCHL EQ 'YREL' AND KOMKBV3-ERDAT GE '20120803'.

sy-subrc = 0.

ENDIF.

KOBEV_890:

exactly the same as KOBED_890. Thats why I did not mention which part it is,

[Former Member]

Result is still the same.

[VeselinaPeykova]

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.

[Former Member]

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.

[VeselinaPeykova]

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.

[Former Member]

do you mean the Transaction code NACE? Where do I find the point "Access to conditions" ?

[VeselinaPeykova]

Here is the setting I referred to - accessable from NACE (you can double-click on the output type to get to the screen):

In case you have to change this setting, you will need a customizing request in non-sandbox clients.

From the screenshot you can see the tab Storage system as well .

[Former Member]

Ah Ok, now I get it. It is set as X.

Sadly it Looks as I have a lot of user-Exit Debugging in front of me....

[Lakshmipathi]

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

[Former Member]

I have done thouse routines myself and they have basically no Content other than sy-subrc = 0. But the bigger issue is why the requirement is shown as blank in the Systems message...

[VeselinaPeykova]

Are the routines properly activated and is the corresponding program regenerated?

[Former Member]

Yes. They are generated and activated.

[VeselinaPeykova]

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?

[Former Member]

I hav tried to remove and look if it works. Both Things did not lead to any result.

Manual only is not checked.

[Former Member]

I have attached the corresponding screenshots. The condition Setting is valid if you have a Partner role "ZR" in Country "CH". the document provides this.

[Former Member]

Furthermore, please see a screenshot of the Acces determiniation w/o clear indication of the faulty Requirement:

[former_member182378]

Deb,

Please check in your billing document if VBRK-EXPKZ is activated i.e. Z? As this is one of the fields in your condition table.

TW

Message was edited by: TW Typewriter

[Former Member]

I have checked, it has the value Z.

[VeselinaPeykova]

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.