版权声明：署名，允许他人基于本文进行创作，且必须基于与原先许可协议相同的许可协议分发本文 （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，也没啥其它办法。