OK, let's hope I have this correct before I post! [B]
There's only two parts to the JDE Julian date -- the year and the day of the year. So, it must be one or both of those parts of the date value, right? Let's separate them:
SELECT
rpan8,
rpdoc,
rpdct,
rpkco,
rpsfx,
rpddj
,rpddj-mod(rpddj,1000) modyear
,mod(rpddj,1000) moddate
-- ,TO_DATE(TO_CHAR(rpddj + 1900000), 'YYYDDD') rpddj
-- ,TO_DATE(TO_CHAR(rpddnj + 1900000), 'YYYYDDD') rpddnj
-- ,TO_DATE(TO_CHAR(rpdivj + 1900000), 'YYYYDDD') rpdivj
FROM
crpdta.f03b11
ORDER BY 7
-- DESC
;
This SELECTs the primary key (and AN8 for good measure) from your Customer Ledger table, along with the dreaded DDJ date that we'll troubleshoot. It also gives us MODYEAR, which is the year portion of the date, and MODDATE for the day portion. It then ORDERs the output by column 7, which is the JDE Julian year part of DDJ.
Looking at the first 500 rows that Toad returns, you should be able to tell if you see any garbage in the first few rows of MODYEAR. If not, uncomment the DESC part of the ORDER BY and run again, examining the first few rows of the new results.
Repeat, but ORDER BY 8, which is MODDATE. If you have any issues with DDJ, you should see them here. You can then use AN8 or the primary key columns retrieved to correct the dates via SQL (hopefully you have business procedures in place to be able to do that!).
Since your original SQL also referenced DDNJ and DIVJ, you'll likely want to check those as well.
Fire this up and let us know if/how it worked!
GL!
Rich
p.s. Noticed I have the SQL above running in PY -- please test this in a lower environment first, if possible!