Crystal Report printed with empty layout in Apps10

Hi ​@Mounika ,

Yes — this usually means the report is being called correctly, but the data context is not being passed the same way as when you print from the application.

From what you’ve shown, the Crystal layout is opening, but only the static structure prints and not the transaction data. That normally points to missing parameters / missing language / wrong print job context / wrong LU keys in the backend call.

 What’s happening

When you print from the UI:

• IFS passes the full report context
• including:
  • report id
  • key values
  • language
  • print job/session context
  • sometimes user/session-dependent data

When you print from a script/event:

• the Crystal Report opens
• but if one of the required attributes is missing or wrong,
• it prints the empty template

 So this is usually not a Crystal layout issue itself
It is more often a parameter/context issue

 What I would check first

1. Report key / parameter values

In your code I can see:

• wo_no_ := :paramet...
• and then:
• Client_SYS.Add_To_Attr('WO_NO', wo_no_, report_attr_);

That is the first thing I’d validate.

 Make sure:

• the parameter really contains the expected WO number
• datatype matches
• the report dataset uses the same key the UI printing uses

A very common issue is:

• backend event passes a value
• but not in the exact format expected by the Crystal data source

2. Language / report language

You are passing:

• LANG_CODE
• PDF_LANGUAGE_CODE

That is good, but I’ve seen cases where:

• wrong or null language code
• causes report data fetch issues or fallback behavior

So check whether:

• Language_Code_Fnd_Session_API.Get_Language returns valid value
• same language is used when printed from UI

3. Printer / print job attributes

You are using:

• PRINTER_ID
• PRINT_JOB_ID
• MESSAGE
• ARCHIVING

Sometimes the report prints empty when:

• print job is created
• but the backend call does not fully initialize the same runtime context as online printing

 Compare against a working standard server-side print example in Apps10

4. Layout type mismatch

This is another common one.

If the Order Report was originally RDL and later switched to Crystal:

• backend/event logic may still be using assumptions from old RDL flow
• while online print handles Crystal correctly

So I’d verify:

• report rule points to Crystal layout
• no old RDL-specific setup is still hanging around
• correct report layout is active for that report id

 What people usually do

✔ Option 1 — Compare UI print vs backend print

Best practical step:

• print the same report from UI
• trace the report parameters / attributes
• compare with the event/script call

This usually exposes:

• one missing attribute
• wrong key field
• or wrong report id/layout/lang

✔ Option 2 — Check the report dataset directly

If Crystal prints only structure:

• report opened successfully
• but returned no rows

So check the report source view / query with the exact WO number passed from event.

 If no data comes back there, the issue is in the key/context, not the layout.

✔ Option 3 — Test with a hardcoded known-good key

Try one test with:

• fixed WO number
• fixed language
• same report id

If that prints values, then the issue is definitely with:

• event parameter mapping
• or value formatting from the trigger

 My likely suspicion here

From experience, the most likely causes are:

• wrong/missing parameter value from event
• report called with incomplete backend context
• Crystal layout expecting data source keys that are not being passed exactly as online print does

The fact that the layout structure appears is the big clue:

the report is found and rendered, but the dataset is empty at runtime