Skip to Content

BRF + Timestamp to date convertion issue using formula expression

Mar 28, 2017 at 05:33 AM


avatar image
Former Member

Hi all,

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

10 |10000 characters needed characters left characters exceeded
* Please Login or Register to Answer, Follow or Comment.

1 Answer

Best Answer
Christian Lechner
Mar 30, 2017 at 07:30 AM

Hi George,

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.

Best regards,


Show 2 Share
10 |10000 characters needed characters left characters exceeded
Former Member

Apologies on the late response here. I did figure out that, if you are using a short timestamp as Christian has pointed out, BRF+ will convert it properly. For the long time stamps (DEC 21,7) you are pretty much stuck. In my case unfortunately I wasn't in a position to change the binding of the timestamp to a short one. Hence had to move the actual rule outside of BRF+ and was done in ABAP and passed the result back into rules as a flag. Thanks for the detailed explanation Christian. appreciate it.




As a matter of interest, why could you not change the binding?

I find it a really useful feature that BRFplus just matches elements based on name.

Only recently I had a similar situation where a single field in a DDIC structure needed to be of a different type within BRFplus. I just changed the element definition and that was it. I don't know how it would handle data types with different structures though, such as your example.