Just wondering if anyone has came across a similar issue here.
when a data element is created with a binding to a DDIC type of timestamp, unfortunately rules is creating a number element instead of a date element. So if then you have to compare it against another date, you are stuck where you cant even use the "get date part" formula as it will complain it is not a time point
this behavior is "correct" and is a consequence of the basic BRFplus types:
The basic element for a timestamp in BRFplus is given by the data element FDT_TIMESTAMP. This is assigned to the domain TZNTSTMPS (DEC15,0). BRFplus will therefore only assign the timestamps that fit to this domain to the BRFplus elementary type of a timestamp
In your case you use the dataelement TZNTSTMPL which is assigned to the domain TZNTSTMPL (DEC 21, 7) and that is not fitting for the BRFplus internal representation of a timestamp including the consequences that you came across (like the comparison as for BRFplus "your" timestamp is a number.