ORA-01722: invalid number when creating materialized view - oracle

Question

I am creating a view and the same view converted into materialized view in the same system. But doing the same thing in another system I got error ORA-01722: invalid number when creating the materialized view. Why?
create materialized view MV_EMP_VALI
refresh complete with rowid start with SYSDATE+1/24 AS
(select * from V_CHA1);
View:-
CREATE OR REPLACE VIEW V_CHA1 AS(SELECT EMPNO,
MONTHYEAR,
to_number(SUM(CPFEMO)) AS EMOLUMENTS,
to_number(SUM(CPEPF)) AS EMPPFSTATUARY,
to_number(SUM(AEMO)) AS AEMO,
to_number(SUM(APEPF)) AS APEPF,
MAX(recsts) AS recsts
FROM ((SELECT RECDATE,
(CASE WHEN (REPFEMOFLAG='N') THEN
round(NVL(trim(EMO), 0))
ELSE
round(NVL(REVISEMO, 0)) END ) as CPFEMO,
round(NVL(trim(EPF), 0)) AS CPEPF,
0 as AEMO,
0 as APEPF,
'' as recsts,
EMPNO
FROM EMP_VALI
WHERE EFLAG = 'Y' AND SFLAG = 'N' AND EMPNO IS NOT NULL and
RECDATE >'01-Apr-2011')
union all
(SELECT NDT.RECDATE AS RECDATE,
sum(round(NVL(trim(NDT.EMO), 0))) as CPFEMO,
sum(round(NVL(trim(NDT.EPF), 0))) as CPEPF,
0 as AEMO,
0 AS APEPF,
NDT.EMPNO
FROM EMP_VALI VAL, EMP_SUPP NDT
WHERE VAL.EMPNO = NDT.EMPNO AND VAL.EFLAG = NDT.EFLAG AND
VAL.EFLAG = 'Y' AND VAL.SFLAG = 'Y' AND
NDT.SLIFLAG='N' and
VAL.EMPNO is not null and
NDT.RECDATE = VAL.RECDATE
GROUP BY NDT.RECDATE, NDT.EMPNO) UNION ALL
(SELECT DT.RECPAIDDATE AS RECDATE,
0 as CPFEMO,
0 as CPEPF,
sum(round(NVL(trim(DT.EMO), 0))) as AEMO,
sum(round(NVL(trim(DT.EPF), 0))) AS APEPF,
max('') as recsts,
DT.EMPNO
FROM EMP_VALI VAL, EMP_SUPP DT
WHERE VAL.EMPNO = DT.EMPNO AND VAL.EFLAG = DT.EFLAG AND
VAL.EFLAG = 'Y' AND VAL.SFLAG = 'Y' AND
VAL.EMPNO IS NOT NULL and dt.RECDATE=val.RECDATE AND DT.SFLAG IS NOT NULL AND DT.SFLAG not in ('N','F')
GROUP BY DT.RECPAIDDATE, DT.EMPNO)UNION ALL
(SELECT DT.RECPAIDDATE AS RECDATE,
SUM((CASE
WHEN (DT.ECR4FLAG = 'C') then
round(NVL(trim(DT.EMO), 0))
else
0
end)) as CPFEMO,
sum((CASE
WHEN DT.ECR4FLAG = 'C' then
round(NVL(trim(DT.EPF), 0))
else
0
end)) as CPEPF,
sum((CASE
WHEN DT.ECR4FLAG = 'A' then
round(NVL(trim(DT.EMO), 0))
else
0
end)) as AEMO,
sum((CASE
WHEN DT.ECR4FLAG = 'A' then
round(NVL(trim(DT.EPF), 0))
else
0
end)) as APEPF,
max(EMPRECOVERYSTS) as recsts,
DT.EMPNO
FROM EMP_VALI VAL, EMP_SUPP DT
WHERE VAL.EMPNO = DT.EMPNO AND VAL.EFLAG = DT.EFLAG AND
VAL.EFLAG = 'Y' AND VAL.SFLAG = 'Y' AND
VAL.EMPRECSTS = 'DEP' AND VAL.EMPNO IS NOT NULL and
dt.RECDATE = val.RECDATE AND DT.SFLAG IS NOT NULL AND
DT.SFLAG in ('F')
GROUP BY DT.RECPAIDDATE, DT.EMPNO))
GROUP BY RECDATE, EMPNO)
/

Answer 1

It's hard to tell from the statement, but if I had to guess, I put my money on the expression:
RECDATE >'01-Apr-2011'
assuming the column RECDATE is actually of type DATE. Therefor Oracle tries to convert the character value '01-Apr-2011' to a DATE as well. As you did not specify an format mask for this, the default NLS settings are used. If they define a number for the month then the above value would fail conversion.
You should never rely on implicit data type conversion. Especially not with dates. Use an ANSI literal instead:
RECDATE > DATE '2011-04-01'
or use the to_date() function with a format mask:
RECDATE > to_date('01-Apr-2011', 'dd-mon-yyyy')
Note that this could still fail for certain settings of NLS_LANG. In French you would need to specify 'Avr' instead of 'Apr'. So unless you are absolutely certain you can control all NLS_XXX settings all the time I'd strongly suggest to use month numbers instead. If you are more comfortable using to_date() than ANSI literals, you can use:
RECDATE > to_date('01-04-2011', 'dd-mm-yyyy')
Edit
if it's not the date column you need to check any other column for implicit data conversions.
These expression:
sum(round(NVL(trim(DT.EMO), 0)))
round(NVL(trim(EMOLUMENTS), 0))
round(NVL(trim(DT.EMO), 0))
round(NVL(trim(DT.EPF), 0))
look suspicious. If the columns in there are real numbers, then trim() is invalid and useless. If those are not numbers they could cause that error depending on the content of the column.
This expression to_number(SUM(CPFEMO)) is also useless as sum() will already return a number there is no reason to call to_number on a number(). Although I doubt it could raise your error you should still avoid it as it does not make any sense.