SAP Agentry {Eclipse Editor} - Transaction Validat...

A = Current Date B = New Date

1. How do you a create transaction validation rule to compare two fields with NULL dates?

Logic: If A & B are blank then a warning message should be fired upon validation rule execution.

2. How do you create transaction validation rule for two fields with dates that are less than?

Logic: If B is NOT Null and A is Null -> B < sysdate; Null value for A is allowed ..... warning message {older date than sysdate/current date}

If B is Null and A is NOT Null -> Null value for B is allowed .... warning message {No new date entered}

If B is NOT Null and A is NOT Null -> B < A ...... warning message {New date is less than current date/sysdate}

3. How do you create a transaction validation rule for a given fiel with greater than?

Logic: If B > sysDate (current date)

SAP Managed Tags:
Mobile

You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.

Comment

Accepted Solutions (0)

Answers (5)

Watched video ----- no breakthrough yet.......

Experts - your assistance is needed....

You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.

Comment

As a lot of things have happened with this thread it is hard to follow everything.

So let's try this
What type of properties are the fields, String, Date, Date Time?

How do users update the fields (Screenshot)?

Can you post a screenshot of how your current validation rules look, with a note of the expected behavior of it?

Field Properties = Date only [not Date & Time}

Here is the business logic for the Validation Rules:

Fiels "A" = Current Date ; Field "B" = New Date

- Field "A" values are pulled from the backend database or can be updated on mobile unit if blank; Field "B" values are updated on the mobile device during inventory and PM completion.

- During Xmit - Field "B" values update Field "A" values in the backend database. Field "B" was created on mobile device - it doesn't exist in the backend database (i.e. no object property).

Validation Rules:

1. If both A & B are blank - Warning message should be fired {both A & B are blank}

AND

EQNUM

LENGTH

😆 "Field A" Property

x = -1

EQNUM

LENGTH

😆 "Field B" Property

x = -1

2. If A is Null and B is NOT Null; B < Sys Date [Null value for A is allowed - not a required field] - Warning message should be fired {New Date is older than current date}

AND

EQNUM

LENGTH

😆 "Field A" Property

x = 1

EQNUM

LENGTH

😆 "Field B" Property

x = -1

3. If A is NOT Null; B is Null [Null value for B value is allowed] - Warning message should be fired {New date hasn't been entered}

AND

EQNUM

LENGTH

😆 "Field A" Property

x = -1

EQNUM

LENGTH

😆 "Field B" Property

x = 1

4. If A is NOT Null and B is NOT Null; B < A - Warning message should be fired {New date is less than Sys Date}

AND

EQNUM

LENGTH

😆 "Field A" Property

x = 1

EQNUM

LENGTH

😆 "Field B" Property

x = 1

5. If B > Sys Date (current date) - an Error message should be displayed {New Date cannot be greater than Sys Date}

😆 "Field B" Property

x = sysdate

- Created a Transaction Validation Rule and defined Special Value = NULL to allow for NULL date values for field B (New Date)

- The first validation rule works perfectly in isolation. After adding subsequent validation rules: all validation fields are parsed one after another - implying the logic doesn't seem to work.

- Ideally a validation rule setup as a Warning - the user should see message and may decide to continue or stop (not mandatory to make any updates). If user continues the next rule will be evaluated and, may be executed if conditions are met. However, this is not happening but instead all 5 validation rules are being parsed one after the other; despite each validation rule being based on unique data conditions.

- In the case where a validation rule is setup as an Error - the error message should pop-up and the user is forced to make changes before proceeding with the transaction (i.e. mandatory to make updates/corrections). However, this action is not taking place as intended.

Can't seem to figure out where is the break or missing link....

Date fields are internally a Int field. Int fields need to have a value, it defaults to 0 and can't be blank. I would think a better check would be:

1. If both A & B are blank - Warning message should be fired {both A & B are blank}

NOT

- AND

- - EQNUM

- - - 😆 "Field A" Property

- - - x = 0

- - EQNUM

- - - 😆 "Field B" Property

- - - x = 0

2. If A is Null and B is NOT Null; B < Sys Date [Null value for A is allowed - not a required field] - Warning message should be fired {New Date is older than current date}

NOT

- AND

- - EQNUM

- - - 😆 "Field A" Property

- - - x = 0

- - AND

- - - NOT

- - - - EQNUM

- - - - - 😆 "Field B" Property

- - - - - x = 0

- - - LT

- - - - 😆 "Field B" Property

- - - - DATE

3. If A is NOT Null; B is Null [Null value for B value is allowed] - Warning message should be fired {New date hasn't been entered}

In this cause internally it should not posable as it is the same as Rule 1, there is nothing different

4. If A is NOT Null and B is NOT Null; B < A - Warning message should be fired {New date is less than Sys Date}

NOT

- AND

- - NOT

- - - EQNUM

- - - - 😆 "Field A" Property

- - - - x = 0

- - AND

- - - NOT

- - - - EQNUM

- - - - - 😆 "Field B" Property

- - - - - x = 0

- - - LT

- - - - 😆 "Field B" Property

- - - - 😆 "Field A" Property

5. If B > Sys Date (current date) - an Error message should be displayed {New Date cannot be greater than Sys Date}

NOT

- GT

- - LT

- - - 😆 "Field B" Property

- - - DATE

Hi Stephen,

I implemented the validation rules as advised. However, all validation rules are being parsed one after the other despite there being different data field conditions as elaborated in each scenario.

When "OK" (check mark) button is selected a pop up with the 1st validation rule is displayed, with an option of either OK or Cancel. When OK is selected the 2nd validation rule pops up.... pressing OK the 3rd validation rule pops up.... and so on until the 5th (last) validation rule is displayed. Selecting "Cancel" at any point reverts the transaction back to the edit screen - which is the ideal expectation.

The logic fails to filter the right transaction validation rule that needs to be fired based on the existing data field conditions - so that only a specific validation rule is applied. OK option should accept the data fields as is - record saved and allow user to move to the next transaction. Cancel option should revert transaction back to the edit screen - where user can make further edits and data entries.

What is missing link or where is the break?

Kiran,

Hi. I browse thru all the message above and I am not sure if I am coming from the correct context. I am sorry if my statement below is not from the correct context of the current discussion.

You were asking what is the missing link or where is the break?

If I have to gauge what is wrong from a third party perspective this is what I can tell:

You said # 1: "The logic fails to filter the right transaction validation rule that needs to be fired based on the existing data field conditions - so that only a specific validation rule is applied."

and

You also said # 2: "

1. If both A & B are blank - Warning message should be fired {both A & B are blank}

AND

EQNUM

LENGTH

😆 "Field A" Property

x = -1

EQNUM

LENGTH

😆 "Field B" Property

x = -1

My view:

First of all, the AND statement above is not like an AND statement in a SQL query. The AND statement above is a logical AND.

A logical AND means provided that one of the parameters return 0 (incorrect or failed) that means all parameters of that AND are pulled to Zero. There is no need to calculate the other parameter (logic) as it is already 0. This is similar to electronics (So when you are designing a computer transistor or AND gate). Once the AND logic is zero, the circuit is grounded (your power is zero) - there is no need to calculate the other logic (it is grounded).

So it may be that your rule needs to be tweaked. You may try EQSTR (or EQNUM) in your rule instead if A AND B are NULL then you can try that (The EQSTR can have n amount of Parameter).

Example:

EQSTR
|__'Hello' - from field one
|__'Hello' - from filed two
|__''

- this should always return false. But if the first one is blank and the second one is blank then this EQSTR will return true (Digital design - binary logic concept). By doing the one and zero 1/0 digital binary logic - design style, you can eventually get your rule to work.

Another thing about which validation to fire first. As a designer you have the option to prioritize which validation fires first in your transaction. You can control this by the up or down button. The first one is normally the higher priority or which gets run first.

I am just sharing from a third person perspective what may be missing in this endeavor. But again, provided that you have the data in your Agentry Test Environment you can play more with it.

Hope this helps.

Mark Pe
SAP Platinum Support Engineer

If you want all the options you be checked at one time, all validations need to be in 1 one, not a rule for each one.

This is because each validation rule is checked after the last one is completed. When a validation rule is set to error, it stops with the pop-up error and doesn't show the rest until that rule passes. When it is a warning the user has the option to pass the warning, but it goes pass the error and then the next rule will show.

If you want only 1 pop-up to show for all the rules then you need to do something like the following:

- Check 1
- Check 2
- Check 3
etc

Then for the warning message, you will want a new rule to combine all the errors into one popup.

CONCAT
OR
- IF
- - NOT
- - - Check 1
- - AND
- - - Message One
- - - NEWLINE
- IF
- - NOT
- - - Check 2
- - AND
- - - Message 2
- - - NEWLINE
ETC

I would like all conditions to be evaluated and the correct validation rule to be fired - either a Warning or an Error. Combining all options into one validation rule versus individual validation rule for each condition sounds plausible but, the question is that how would you structure the validation rule and customize the error or warning based on a given condition. This seems to be quite challenging since a validation rule can only have one error or warning message associated with it though the validation rule might incorporate different conditions. I don't need 1 pop-up to show for all the rules since this seems like a one-size-fit-all approach which doesn't meet the requirements. Experts - can you illustrate on the validation rule structure; error message and warning messages.

Kiran,

I think the trick here is to analyze which of your validation rule has priority.

Example (in your Agentry Editor Validation for Transaction1 )

Transaction 1:

|__Validation

Validation 1 - message warning - user A please do this
Validation 2 - message error - This is a critical error you have to redo
Validation 3 - message warning - User A please do this other thing
Validation 4 - message error - This is a failed entry

You as the designer have to decide the priority. Let us say validation 1 has the highest priority, then you make that the #1 validation to be checked in order in the Editor. Normally the highest priority trumps all other as it is the highest priority then go to the next one in order.

This is how we teach our students or designer (upcoming support engineers or developers) when it comes to validation.

Best Regards,

Mark Pe
SAP Platinum Suport Engineer

Mark,

Here are the validation rules in terms of priority (highest to lowest):

Validation Rules:

1. If both A & B are blank - Warning message should be fired {both A & B are blank}

2. If A is Null and B is NOT Null; B < Sys Date [Null value for A is allowed - not a required field] - Warning message should be fired {New Date is older than current date}

3. If A is NOT Null; B is Null [Null value for B value is allowed] - Warning message should be fired {New date hasn't been entered}

4. If A is NOT Null and B is NOT Null; B < A - Warning message should be fired {New date is less than Sys Date}

5. If B > Sys Date (current date) - an Error message should be displayed {New Date cannot be greater than Sys Date}

Currently, each validation rule is being parsed one after the other despite differences in field data values based on each transaction - implying that the logic is not working as intended.

How do you structure the rules in such a way that given a set of data values in fields A & B within a transaction only a specific validation rule will be fired as opposed to all validation rules being fired in sequence at the same time.

Logic should evaluate data conditions in fields A & B and fire only the applicable validation rule that matches the data conditions for a given transaction. In case of a Warning: selecting "OK" should validate the transaction; "Cancel" should return transaction back to the edit screen. In case of an Error when OK is selected: transaction cannot be validated until data fields are edited to match the set conditions; "Cancel" should return transaction back to the edit screen.

Ideally, when transaction is completed and OK is selected the logic should evaluate field data values and based on the conditions set within each validation rule, only one specific validation rule should be fired either as a Warning or Error.

A simple illustration of how-to would paint a better picture!

Because you want only one popup to show up, then you need to have the warning ones have a check to see if the warning one has already pop-up and return true if a message has already been shown, you can do this by adding the validation rule as a subrule in message one.

Do don't need to do this for error because if a error one pop-ups up you can't pass the transaction until it is fixed.

Can you illustrate using the 5 validation rules

Kiran,

Hi. You may also watch this video.

Enterprise Support Academy (QuickIQ):

https://service.sap.com/sap/bc/bsp/spn/esa_redirect/index.htm?gotocourse=X&courseid=70248548

Objective and Purpose: After the tutorial, the designer will be able to take the difference between two dates using the Agentry rules and learning more about the epoch date.
Benefit: The benefit of taking this session is to be able to learn how to use the Agentry rules to calculate the difference between two dates. This is useful in designing work duration (From to To with respect to dates).

With this tutorial hopefully the knowledge on comparing dates will assist you.

Best Regards,

SAP Mobile Support Team

You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.

Comment

Mark,

Authentication is required - what is the username and password?

Kiran

Mark,

Can you provide a pdf version of the recommended video or tutorial.

Apparently, I can't access the video...

--- Kiran

Kiran,

Normally different level of support in SAP have different privileges. The SAP Enterprise Academy host a variety of tutorial and video for SAP customers (with voice). If you have no access it may be that your team/company didn't sign up for the privileges or option for academy support. You may reach out to your SAP Account Executive to see if you want to engage in this option.

In the meantime, check this picture for an example. The tutorial explains the science or technology behind the rules on how it works but I cannot attach a file in this thread but will only give the final example from the tutorial. It will be nicer if you listen to the video versus looking at the final example.

The picture above is an example of substracting two dates but the Science of epoch time explained in the tutorial for customers who has access to the tutorial (to see video and hear the voice and explanation).

Regards,

Mark Pe
SAP Platinum Support Engineer

Agentry Mobile Experts,

Can anyone point me in the right direction...

--- Kiran

You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.

Comment

Hi Kiran,

As Stephen said this is the best approach to achieve this.

Date, Time and DateTime type fields can't be null in Agentry.

If you could little bit elaborate the exact business requirement then I will try to help you.

-Sudhir.

You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.

Comment

Business requirement:

- to include current install date when downloading asset record to the client. current install date is created during asset creation but is dynamic depending on when PM is completed which prompts entry of a new install date.

- new install date (created on client but not present in the backend system); new install date should to be updated if necessary <may be blank if no PM is performed> i.e. Null value should be permitted if no PM has been completed.

**** current install date is linked to object property matching backend schema***

**** new install date is only linked to transaction property linked to object property on the client - since field doesn't exist on backend app****

**** if new install date is entered on client the new install date is updated in the backend app under current install date field*** through java coding

- initially current install date was included during asset creation on handheld but was not being displayed when asset record was being called i.e. during inventory.

****this piece has been fixed. created two fields: current install date and new install date which are showing when assets are being called on the client. the two date fields are editable and can be updated - created hidden rule for both***

Here is a schematic illustration of the issue:

A= Current Install Date B = New Install Date

1. How do you a structure transaction validation rule to compare two fields with NULL dates?

Logic: If A & B are blank then a warning message should be fired upon validation rule execution {i.e. A & B are blank}

2. How do you structure transaction validation rule for two fields with dates that are less than?

Logic: If B is NOT Null and A is Null -> B < sysdate; Null value for A is allowed ..... warning message {older date than sysdate/current date}

If B is Null and A is NOT Null -> Null value for B is allowed .... warning message {No new date entered}

If B is NOT Null and A is NOT Null -> B < A ...... warning message {New date is less than current date/sysdate}

3. How do you structure transaction validation rule for a given field with greater than?

Logic: If B > sysDate (current date)..... Error: new install date cannot be greater than system date

Challenge:

Created a transaction validation rule for edit asset and defined Special Value=NULL to allow for NULL date under new install date. This works fine when both dates are null i.e. current install date=NULL {coming from backend with NULL value; new install date=NULL -> validation rule should be fired to provide warning as illustrated above but instead no warning message is displayed; transaction is accepted hence, validation fails....)

- if current install date is NULL(blank) and new install date is updated to sysdate -> validation rule fires the warning message {i.e. A & B are blank} ... validation rule is not working per logic..... this above scenario is true in the reverse i.e. if current install date is NOT NULL and new install date is NULL(blank); the validation rule fails when both fields are updated {new install date is greater than current install date but <= sysdate

- validation rule #1 not working.... once it works then will work on #2, #3 and so on...

*** how do you compare two Date fields with value=NULL(blank)???

**** how do you make a Date field not to be required???

Sudhir, any thoughts???

Hi Kiran,

Here is my comments...

Let's assume you have two fields A(Date type)= Current Install Date B(Date type) = New Install Date, c(boolean)=To notify current install date is blank or not.

As you said current install date(A) comes from SAP and new install date(B) is filled on mobile.

1. How do you a structure transaction validation rule to compare two fields with NULL dates?

Ans :-

As we know the Agentry does not support the date field as blank or null. we will have to create one more new field(C) which will have value true/false to notify current install date is set or not, this logic need be written in JAVA while downloading the Asset.

1.When Asset reaches on mobile the value of C will be true/false, easily we can write a rule to decide whether current install date is blank or not.

2. For New install date, please set the special value which will display the UI as attached, So user can select auto to ignore the current install date. In this case the Transaction will hold the value as blank. we can easily write a rule to check the blank value.

2. How do you structure transaction validation rule for two fields with dates that are less than?

Ans :- It's straight forward mathematical condition, just use lt/gt function on date type fields to evaluate this.

3. How do you structure transaction validation rule for a given field with greater than?

Ans :- It's also same.

Please refer this :-

Thanks,

Sudhir.

I was able to validate for NULL values for fields A & B by defining NULL as a special value under Transaction property.

However, I have additional validation rules that need the be parsed and corresponding validation rules to be fired appropriately. This is not working since it is only the NULL condition validation rule that is being triggered.

Here are additional conditions that need the be parsed:

If A=NULL and B=IS NOT NULL

If A=IS NOT NULL and B=NULL

If A=IS NOT NULL and B=IS NOT NULL

If B>System Date

Should I structure one Validation rule to parse for all conditions or can multiple validation rules work? How do you structure multiple validation rules to check the field status and fire the correct warning or error?

Your validation rule needs to return True to indicate it passed validation or False to indicate the message should be displayed. If you setup as a warning the user will see your message and can decide to continue or stop. If they continue the next rule will be executed. If you setup the rule as an Error if the rule returns false it will display the message and stop the processing.

If the rule returns True it simply goes on to the next rule without displaying any message. If all rules return True the validation passes and it continues.

As for if you need to combine them or keep them separate will depend on your logic and intentions.

--Bill

Bill,

All validations are retuning True. However, the most recent created validation rule is the only one that is being parsed. For instance when both fields are blank; the NULL validation rule should be called and warning message should be displayed. Initially, this was working perfectly until I added a new validation rule i.e. If A=IS NOT NULL and B=NULL. In this case when fields A & B are blank - NULL validation is not being evaluated and fired instead, the 2nd validation rule {If A=IS NOT NULL and B=NULL} is being executed which doesn't fit the data set logic. Where is the break?

It's really hard to say without seeing your definitions and/or logs. I would recommend running this in the ATE (part of the editor) and turning on Rule debugging for your validation rules and check the log to see what is occurring. Remember to set the level to Low to see the most detail.

--Bill

Can you look at these two transaction validation rules - does this make sense...

1st rule: A= NULL; B=NULL validation rule:

AND

EQNUM

LENGTH

Field A property

x-=NULL

EQNUM

LENGTH

Field B property

x=NULL

Above rule runs OK by itself. Fails once 2nd rule is included.

2nd rule: A= NULL; B=IS NOT NULL validation rule:

AND

EQNUM

LENGTH

Field A property

x=NULL

EQNUM

LENGTH

Field B property

x=IS NOT NULL

Do I need to tweak the validation rules or define which one should be evaluated first then other rules to follow?

Can you use the Test Client within the Editor to debug the rules and post what is going on. This way we can see how the client is behaving with the real data.

Bill / Stephen,

See sample debug log below... any insights???

0000/00/00 13:16:42.261: Opening log file

0000/00/00 13:16:42.261: + Module=Auditor

0000/00/00 13:16:42.261: + Action=EditAsset

0000/00/00 13:16:42.261: + Transaction Step='EditAsset'

0000/00/00 13:16:42.261: + Rule=Edit_Asset_NewDate_Validation

0000/00/00 13:16:42.261: + Function=@IF

0000/00/00 13:16:42.261: + Function=@AND

0000/00/00 13:16:42.261: + Function=@EQNUM

0000/00/00 13:16:42.261: Result<Integer>= 0

0000/00/00 13:16:42.261: + Rule=Edit_Asset_NewDate_Validation

0000/00/00 13:16:42.261: + Function=@IF

0000/00/00 13:16:42.261: + Function=@AND

0000/00/00 13:16:42.261: + Function=@EQNUM

0000/00/00 13:16:42.261: + Function=@LENGTH

0000/00/00 13:16:42.261: + Property=:>\042CurrentDate\042 Property

0000/00/00 13:16:42.261: Result<String>= ''

0000/00/00 13:16:42.261: Result<Integer>= 0

0000/00/00 13:16:42.261: + ConstantTerm=NULL

0000/00/00 13:16:42.261: Result<Integer>= 0

0000/00/00 13:16:42.261: Result<Boolean>= true

0000/00/00 13:16:42.261: + Function=@EQNUM

0000/00/00 13:16:42.261: + Function=@LENGTH

0000/00/00 13:16:42.261: + Property=:>\042NewDate\042 Property

0000/00/00 13:16:42.261: Result<String>= '1/1/2001'

0000/00/00 13:16:42.261: Result<Integer>= 8

0000/00/00 13:16:42.261: + ConstantTerm=NULL

0000/00/00 13:16:42.261: Result<Integer>= 0

0000/00/00 13:16:42.261: Result<Boolean>= false

0000/00/00 13:16:50.794: + Rule=Edit_Asset_NewDate_Validation1_2

0000/00/00 13:16:50.794: + Function=@IF

0000/00/00 13:16:50.794: + Function=@AND

0000/00/00 13:16:50.794: + Function=@EQNUM

0000/00/00 13:16:50.794: + Function=@LENGTH

0000/00/00 13:16:50.794: + Property=:>\042CurrentDate\042 Property

0000/00/00 13:16:50.794: Result<String>= ''

0000/00/00 13:16:50.794: Result<Integer>= 0

0000/00/00 13:16:50.794: + ConstantTerm=NULL

0000/00/00 13:16:50.794: Result<Integer>= 0

0000/00/00 13:16:50.794: Result<Boolean>= true

0000/00/00 13:16:50.794: + Function=@EQNUM

0000/00/00 13:16:50.794: + Function=@LENGTH

0000/00/00 13:16:50.794: + Property=:>\042NewDate\042 Property

0000/00/00 13:16:50.794: Result<String>= '1/1/2001'

0000/00/00 13:16:50.794: Result<Integer>= 8

0000/00/00 13:16:50.794: + ConstantTerm=IS NOT NULL

0000/00/00 13:16:50.794: Result<Integer>= 0

0000/00/00 13:16:50.794: Result<Boolean>= false

0000/00/00 13:17:00.653: + Rule=Edit_Asset_NewDate_Validation

0000/00/00 13:17:00.653: + Function=@IF

0000/00/00 13:17:00.653: + Function=@AND

0000/00/00 13:17:00.653: + Function=@EQNUM

0000/00/00 13:17:00.653: Result<Integer>= 0

0000/00/00 13:17:00.653: + Rule=Edit_Asset_NewDate_Validation

0000/00/00 13:17:00.653: + Function=@IF

0000/00/00 13:17:00.653: + Function=@AND

0000/00/00 13:17:00.653: + Function=@EQNUM

0000/00/00 13:17:00.653: + Function=@LENGTH

0000/00/00 13:17:00.653: + Property=:>\042CurrentDate\042 Property

0000/00/00 13:17:00.653: Result<String>= ''

0000/00/00 13:17:00.653: Result<Integer>= 0

0000/00/00 13:17:00.653: + ConstantTerm=NULL

0000/00/00 13:17:00.653: Result<Integer>= 0

0000/00/00 13:17:00.653: Result<Boolean>= true

0000/00/00 13:17:00.653: + Function=@EQNUM

0000/00/00 13:17:00.653: + Function=@LENGTH

0000/00/00 13:17:00.653: + Property=:>\042NewDate\042 Property

0000/00/00 13:17:00.653: Result<String>= '1/1/2001'

0000/00/00 13:17:00.653: Result<Integer>= 8

0000/00/00 13:17:00.653: + ConstantTerm=NULL

0000/00/00 13:17:00.653: Result<Integer>= 0

0000/00/00 13:17:00.653: Result<Boolean>= false

0000/00/00 13:17:05.302: + Rule=Edit_Asset_NewDate_Validation1_2

0000/00/00 13:17:05.302: + Function=@IF

0000/00/00 13:17:05.302: + Function=@AND

0000/00/00 13:17:05.302: + Function=@EQNUM

0000/00/00 13:17:05.302: + Function=@LENGTH

0000/00/00 13:17:05.302: + Property=:>\042CurrentDate\042 Property

0000/00/00 13:17:05.302: Result<String>= ''

0000/00/00 13:17:05.302: Result<Integer>= 0

0000/00/00 13:17:05.302: + ConstantTerm=NULL

0000/00/00 13:17:05.302: Result<Integer>= 0

0000/00/00 13:17:05.302: Result<Boolean>= true

0000/00/00 13:17:05.302: + Function=@EQNUM

0000/00/00 13:17:05.302: + Function=@LENGTH

0000/00/00 13:17:05.302: + Property=:>\042NewDate\042 Property

0000/00/00 13:17:05.302: Result<String>= '1/1/2001'

0000/00/00 13:17:05.302: Result<Integer>= 8

0000/00/00 13:17:05.302: + ConstantTerm=IS NOT NULL

0000/00/00 13:17:05.302: Result<Integer>= 0

0000/00/00 13:17:05.302: Result<Boolean>= false

You can remove the IF portion of the rule since the AND returns a True False which is what you want back from your validation rule.

When checking if the date is empty using LENGTH your EQNUM should be to 0 not a String "NULL"

AND

EQNUM

LENGTH

DateField A

EQNUM

LENGTH

DateField B

Your second rule

AND

EQNUM

LENGTH

DateField A

NOT

EQNUM

LENGTH

DateField B

--Bill

Bill,

I mirrored your rules and here are the results:

Rule 1 works perfectly before introducing rule 2.

Once I create rule 2: when field A & B are both O, validation rule for rule 2 is being evaluated as opposed to validation rule for rule 1 which should be fired first.

I went ahead and left field A "blank" and updated field B with date (less than current date). Validation rule for rule 1 is triggered instead of validation rule 2.

Therefore, in a nutshell both validation rules 1 & 2 seem to work in reverse. Where is the disconnect?

I would like to add to rule 2 another condition whereby Field B is < (less than) System Date. What is the best way to structure rule 2 while incorporating this additional condition?

Any insight pertaining to this issue is much appreciated.

--Kiran

Date fields are saved on the client as numeral fields, so there is no way a data is a Null date, as the first day is something like 1/1/1990

You can compare date fields just be using the Greater / Less then fields to the Function System "Date"

You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.

Comment

field A (current date) is coming from backend app; field is not required. In this case current date doesn't imply sysdate but rather the most current date in the backend system. Conversely, field B is updated at transaction level and validated through transaction property validation rule. Upon successful validation field B may be left blank; updated with new date but cannot be less than current date or greater than sysdate. You're right - date fields are saved on client as integral numbers however, through use of Special value under field B detail screen you can define NULL as a special value which can allow user save record with NULL date value. The dicey part is the validation rule doesn't work and still recognizes field A & B as null even in the case where both date fields are populated with real dates. To all the Experts - any insight on theis issue will be appreciated....

just to add on - field B is eventually updated into backend system upon validation and Xmit through java code...

Ask a Question

Top Q&A Solution Author

User

Count