Version 2

    Requirement:

    Upload CRM.pad signed reports into D1/D3 instead of D2 with the following use case:

    • User Opens a report on the CRM.pad
    • Client signs the report directly on the iPad
    • CRM.pad stores the signed report in the database

     

    Environment:

    BtB - Enterprise Edition

    CRM.win v10.1.20

    CRM.web v10.1.20

    CRM.pad v4.0.0 (iOS 10.3.3)

    ISI Template v9.3.20.643

     

    Use Case:

    Creating a new Ticket (KM) & Service Report (TPR3) for an existing company in CRM.pad

    Once the service report is signed, checking CRM.win and CRM.web reveals, that signed reports are stored not only in TPR3’s Document field (D2), but also as Document (D1) and Document Link (D3)

     

    Technical Implementation:

    No deviation from the (BtB & ISI Template) standard was implemented to achieve this behavior. It should be possible to re-use the existing product behavior in regard to CRM.pad service reports (TPR3/PR) for other reports as well.

    Configuration details:

     

    Judging from the existing Triggers and references towards the “Document (38)” field of PR, it’s not entirely clear which logic effectively creates the D3 and D1 records.

     

    Conclusion:

    The requirement “Upload CRM.pad signed reports into D1/D3 instead of D2” can only partially be met:

    Saving reports into D1 and D3 is possible within the standard product - the existing TPR3 implementation can serve as guidance if the reporting needs to be implemented for an info area other than PR.

    The CRM.pad’s client-side logic would need to be adjusted in order to completely skip saving into D2, as the device currently displays the signed report based on the “Document” field (1:1 relationship) and would not be able to load the correct report from within D3/D1 (1:n relationship) without additional logic being added to the product itself to determine which of the attached reports is supposed to be displayed.

     

    The component which copies the D2 document into D1 and D3 would need to be researched in detail in case rebuilding the existing TPR3 reporting settings within another infoarea doesn’t suffice to achieve the desired result.