When a Service Desk system includes cloned modules they take on the object names from the original module. For example if the Incident Management module is cloned the process object within the cloned module will also be called Incident.
You can (and normally would) rename the object to something relevant to the new module however this only changes the Title propery of the object and the Name propery remains "Incident". This is not an issue as throughout the product the object will be referred to by its Title. The exception to this though is printing from the new process object, which will try to load a Cyrstal report file based on the Name property, ie. Incident.rpt. If you already use an Incident.rpt for printing incidents this means you can't have a report for the new module too.
The attached Crystal report shows how to usea "master" Incident.rpt report to load one of multiple sub-reports based on the module of the object you're trying to print. Instructions for adding new reports is included within the report header (right-click the section and select "Don't Surpress" to make it easier to read). The example cloned module is called Service Request Management and includes the Out Of The Box Incident.rpt report for the original module. The naming convention used for the sub-reports can be anything, this example uses Module.Object.rpt for clarification such as IncidentManagement.Incident, ServiceRequestManagement.ServiceRequest.rpt.
The same technique can be used for a module cloned from any other module other than Incident Management. The report simply needs renaming (to Call.rpt, Problem.rpt, etc).and the correct sub-report added to replace IncidentManagement.Incident.rpt.