SU01. Every effin' time I unlock a user I get "User ... unlocked, if this is permitted in this system". Well, if this is not permitted then how come I just did it, huh?
Throwing "something may or may not be wrong" message must be the epitome of lazy programming.
It's poorly worded but think you did global unlock in cua. If child system is locally locked by admin then it will remain locked
Unlike password reset, you don't get to choose which system to unlock so cua attempts to unlock all systems where user exists
My question is why cua unlocking/locking couldn't mimic password so you chooss which systems
Just because I'm curious... Was any of the bugs mentioned in Part 1 fixed? :)
Don't think so. SAP eventually fixed the "umbrella... ella..." in ABAP Editor but apparently they found out even before it was posted on SCN.
There was a very long reply from an SAP employee but they insisted on going through Customer Connection even after I pointed out that the topics available for that "Connection" do not include ABAP. It's not as easy as SAP seems to think. No one is going to do that just to remove a ridiculous message.
My question regarding why SAP wants us to jump through hoops to ask for small improvements while apparently they have time to change things no one asked for remains unanswered.
I've opened an incident to fix incorrect lock in FILE transaction (that did not remove the redundant messages though). Had to go back and forth with SAP Support for a long time explaining to them how the locks work and what the problem was exactly and why. "Ain't nobody got time for that".
Instructions in the SAP Note 433920. I'm not sure why this is a modification and couldn't have been done through customizing or something but anyways.
The note says to use SE51 to modify some standard screens. These are literally the instructions given:
"Screen SAPLV60F4204, subobjects 'Fullscreen editor'. In the 'Table Contrl' ('Payment cards') block, add the field *FPLTC-CSOUR [...]"
None of this even exists. First of all, there is no "screen SAPLV60F4204". SAPLV60F is a program name and 4204 is a screen name. Good thing I have mad analytical skills to figure that out.
Second, there is no "subobjects" and no "block". You have to go to the screen layout and add a field manually there. If this was just self-explanatory then fine, no big deal. But it ain't like that at all.
I have not dealt with table control changes in Dynpro in 10 years but thankfully found the instructions in an old discussion on SCN. Of course, we are adding a column to the table but there is no "add a column" or anything like that. You have to drag an I/O field (which is a totally separate control) onto the table control. Then you also have to add a header manually even if the field is maintained in Dictionary.
Of course, the instruction even got that part wrong: it said to add text first and then I/O field. That would be very difficult because there is no space until you add I/O field and you are just getting a "collision with so-and-so" message if you try such stint.
I'm not sure if this worked differently in, say, 4.0 (it's an old note) but the note has been updated in 2017 and actually has separate steps for 6.0. Yet apparently no one bothered to check if the instructions even correspond to reality.
Bonus - no "star rating" because it's a note, not KBA.
Mmmm, menus... :) (SE80/SE84, EHP6)
This is what in EHP8
Apparently SAP is waiting for a customer to submit an incident to fix such things. Not sure why. One would think some kind of internal process should exist for this. And it should've been caught in UAT in the first place.
Horst Keller - any thoughts?
SQ01 -> query name -> Change -> exit (no changes made) = OK.
SQ01 -> query name -> Change -> Basic List -> exit (no changes made) = this:
Why?
Silly usability mis-feature: On HANA we have SE16H with some great new features as a replacement for SE16N (which surprisingly few people use).
Except... that the least used field (database connection) is the first one with the cursor on it. 99% of the time we want to look at a table in the first instance, but that requires several tab presses to get to the table name field. Just make it like SE16N! Please?
Edit: Now that I'm in front of a system, here's a screenshot:
Smartforms coding editor
Thanks for the nice blu screen, but if i can have a wider editor it would be better....
You just need to switch to Adobe-Forms. Then suddenly your screen is too small to have everything in place ;-)
But to add something here to the list.
Why is it possible to edit a form with adobe even when just display. That stole me some hours of my lifetime:-(
~Florian
This kind of check... if could be avoided would be great!
That made me laugh out loud! :D
Isn't that a correct use case of "embrace change" - aka be preparred for innovative mathematical axioms...?
(That being said, "if (1==0)" or "if (false)" are not that rare within C/C++ code to exclude blocks or WHERE 1=0 within SQL to ignore conditions...)
Actually there are some good reasons for this, mainly for searching via where-used..
You can use this to 'comment out' code but leave it searchable.
Another use is to 'index' an obscure dynamic statement/method/function/message, useful for difficult support scenarios (e.g. stuff running in RFC) and/or delegated message raising. So if someone sees the message they can do a where-used and track down the piece of code where it's raised:
funkymessagelogthingy->fail( id = 'ZMYAPP' num = 104 ).
if 1 = 2. message e104(zmyapp). endif. "Find via where-used
i find very difficult to see why it should be searched a piece of code or a structure or a message or anything in a place where is not triggered.
If i need to search the message, i prefer to look at the call stack after setting a watch point :)
But it's just me being old fashioned! :P
"If i need to search the message, i prefer to look at the call stack after setting a watch point :)"
...in an inbound RFC? :)
Yes there are longer ways, but taking the error message from a BDOC status and doing a where-used makes life a lot easier for the poor soul who has to fix a production issue.
OK, this is a big one.
1. Some currencies (like JPY) are configured in SAP with 0 decimals. That is fine but for some reason (I guess expensive disk space in the 1970s?) the amounts in this case are also stored "shifted" by 2 decimal places. E.g. 3000 JPY would be stored in the database as 30.00. And we have to jump through hoops to convert the numbers back and forth.
2. XK15 & Co do not like any decimals. E.g. if you try entering "3000.00" it causes a hard error "Decimals are not allowed". You have to enter 3000 exactly, no funny business with dots or "no soup for you". See Note 2099501 on this. Love the verbiage: "This is correct and from a business perspective totally fine." No, dear SAP, it's f*g far away from "fine".
3. BAPI_CURRENCY_CONV_TO_EXTERNAL didn't get a memo and it can only deal with a very specific format with 4 decimals. Even though it actually reads configuration settings, it couldn't care less about the decimals-shmecimals and just blindly shifts any number by 2 places. So, after currency conversion not only you don't get "3000" but you even get "3000.2100".
4. OK, we can use WRITE ... TO ... CURRENCY..., right?
5. Well, that adds a thousand separator and (dun-dun-duh!) enter "3,000 cannot be interpreted as a number" short dump.
But you have wonderful CONVERT_TO_LOCAL_CURRENCY !
Why do you complain!? :P
It's like someone came up with this on purpose. Probably someone evil.