When will SAP realize that inconsistent behavior is a bug?

[former_member181923]

Example 1:

Call a screen with an ALV on it, and do not create your container object before calling cl_salv_table->factory.

Everything will be fine.

Now, from a pushbutton on the ALV toolbar, call a second screen with an ALV on it, and again, do not create your container object before calling cl_salv_table->factory.

Everything is NOT fine.

Why?

Answer: on the first and only screen of a program, SAP will let you get away with not creating the container object before calling the factory method.

But if you are using more than one ALV screen within the same program, SAP gets confused unless you create the container object before calling the factory method.

What's wrong with this picture?

Duh! If it doesn't work ALL the time, it shouldn't work at all.

Example 2:

Create a sorted itab with a non-unique key containing just the first two of the key fields from VBFA - preceding doc and preceding item.

Fill this table with a FOR ALL ENTRIES that uses an itab with sales doc #'s and item #'s in it.

SOMETIMES your itab will fill with all the VBFA entries for an item ... and ...

SOMETIMES IT WON'T.

What's wrong with this picture?

Duh! If it doesn't work ALL the time, it shouldn't work at all.

(Note: solution to Example 2 involves using the COMPONENTS clause to make the itab primary_key containing all the fields of the VBFA key (except mandt, unless you need it), and then doing partial key READs with the COMPONENTS clause.)

[Lukas_Weigelt]

When hell freezes over.

Please also check SAP Note # 11, it will definitely solve your problem.

Currently I'm trying to convince the AGS in several cases that bugs are bugs (even more frustrating) and I'm not being taken serious and/or people are taking the p***, yet again. I'm even sending correction instructions doing THEIR work, to no avail.

Stupid mondayish Fridays, I'll just asdasdfasdgasfdgasdasd.

[Jelena]

Yeah, what Lukas said. When pigs will soar over the frozen hell lakes.

I had a truly bizarre experience just last year. We received a sales order via IDoc from an EDI customer and by mistake they put the delivery date 3 years ahead. SAP "ate" that and posted the order, but when customer service went to correct the order in VA02 they could not make any changes whatsoever in it because they were getting hard error that date is not in the factory calendar. (We don't usually maintain calendars that far ahead, I believe it's not unusual.)

After a long deliberation (including, of course, the usual ping-pong) SAP stated that because Plant is not entered when placing order (of course, how the heck would EDI customer know what our plants are?) it's not possible to validate the date, so any valid date is accepted. But the plant actually gets assigned while saving the order (there is only one anyway) and when you go to change it you get a middle finger error message. For  weeks I've tried to appeal to some basic human sensibilities, but this was the response:

As I have explained in my previous reply, this is a standard system
behavior which is confirmed by our developer. SAP will not change
thsi design.

Interestingly, the order couldn't even be deleted so - and I'm kidding you not - I had to write a program to fix the date in the database. I wonder if anyone read that "positive closure survey" I wrote...

[former_member181923]

Well look - you have to agree things have improved.  Back in the day, SAP would not have said "SAP will not change this design".  SAP would have said "You will like this design".  That's why almost all business school professors hate SAP - it's an attitudinal thing.