版权声明:署名,允许他人基于本文进行创作,且必须基于与原先许可协议相同的许可协议分发本文 (Creative Commons)
Before appointment date change is really perform, there is a check against Logical date key. If check fails, update will terminate.
The involved profile name is Z00000000002. There must be some guy changes the configuration recently. I will check where this configuration is done now.
Yesterday there was a change implemented regarding what is saved in the contents of LOGICAL_KEY – apparently appointments need to be saved as “ORDERPLANNED” and not “ORDERACTUAL” for our means. I didn’t quite understand why this is necessary, if you need more information, I’ll have to refer you to our CRM consultant. Like last time, I only found out about this change when investigating this error.
I tried fixing this in the BADI implementation:
READ TABLE ct_input_fields WITH KEY objectname = 'APPOINTMENT' logical_key ='ORDERACTUAL' INTO cs_input.
IF sy-subrc EQ 0.
MOVE 'ORDERPLANNED' TO cs_input-logical_key.
INSERT cs_input INTO TABLE ct_input_fields.
DELETE ct_input_fields WHERE objectname = 'APPOINTMENT' AND logical_key ='ORDERACTUAL'.
ENDIF.
Unfortunately, no luck. Probably, either ORDERACTUAL comes up a second time in a different place I didn’t see, or there’s some additional customizing that needs to be performed. Either way, it seems we try to save 'ORDERACTUAL' but what we need to save now is'ORDERPLANNED'. 一个Date profile挂N个Date rule:
一个Date profile挂N个Date type:
一个Date type只能挂一个Date rule:
如果配置有问题,Fiori ui上没任何message,现象就是除了from 和to之外,其他field都能成功更新。这种问题客户除了自己debug,也没啥其它办法。