K-Rise Systems

On the OrderHistory page, we select 2/15 on filters on page and that enters the datasource.
The result shown on the page is orders with date 2/14. This happens when the order shown is from K-Rise, UNIONed to the JDE query so it will show in the same grid (this is how that page works)
1. We query K-Rise EC_Order_Header with filter 2/15 to get the 1 order.
2. We convert for those results the date to be in JDE format. 2/15 becomes 122046
3. We union the results to the JDE query so the K-Rise order is found in the JDE results
4. The JDE query finds no JDE results, only the one K-Rise order which was the reuslt of the UNION. In the results it has date 122046
5. To display on the page, we convert the results from the JDE query to display format. 122046 becomes 2/14 (incorrect!)

We thought it was because the ToDate service is taking into account time zone logic and doing something wrong, but if we hard code the service to be exactly the same and accept 122046 and convert it, it returns 2/15 (correct).

Set up a test with CreateServiceNode with hardcoded date 122046 followed by the ToService referencing it dynamically. This one was not in a foreach like the one originally used (because based on an inquire results). This also converted to 2/15 (correct)

Next test. Disconnected the process databasource after the query to JDE had ran. Looked in the logs and grabbed the result that comes back from the query. Put that in a createservicenodefromxml. This test is now one CreateServiceNodeFromXml followed by a ToDate service referencing it. This also returned 2/15 (correct)
Thinking it was the lack of the foreach that made it successful, ran the same test but put the ToDate in a foreach (like it is in the actual service used). It again returned 2/15 (correct).

Next test. Disconnected the process datasource after the query to JDE had ran and directed it to a ToDate service set up the same way as it was originally when working dynamically but WITHOUT the foreach. This means it would never work in actual practice because the runquery would expect multiple results and this would only work for one, but just for the test. This one returned 2/14 (INCORRECT)
Also tested this by adding the foreach loop to the ToDate service so the ToDate is exactly like the one originally used in the datasource. This returned 2/14 also (INCORRECT)

Next test. Thinking referencing directly from the query introduced this bug, added an intermediary step. Set up the JDE query to save to database and used a CreateServiceNodeFromDatabase to pull from the query results and then use a ToDate service on that. This returned 2/14 (INCORRECT)

Here is the ToDate service how its set up when there is a foreach loop: And how it is when there isnt: Here is the output from the JDE Query:
<Output>
<Result SelectOutput="True">
<ADDRESSNUMBER>50004646</ADDRESSNUMBER>
<ORDERNUMBER>99999999</ORDERNUMBER>
<KRORDERNUMBER>ORH-10000834</KRORDERNUMBER>
<ORDERTOTAL>1900</ORDERTOTAL>
<ORDERNUMBERVISIBILITY>False</ORDERNUMBERVISIBILITY>
<ORDERTYPE>SI</ORDERTYPE>
<ORDERCOMPANY>00000</ORDERCOMPANY>
<REFERENCE>2.15.21.1</REFERENCE>
<DATEREQUESTED>122047</DATEREQUESTED>
<DATEUPDATED>0</DATEUPDATED>
<DATEORDER>122046</DATEORDER>
<HEADERSTATUS>Submitted</HEADERSTATUS>
<BUSINESSUNIT>200000</BUSINESSUNIT>
</Result>
</Output>

This issue is no longer present in the current version of EASYProcess.