HCM Processes & Forms: More Fun with Attachments

I wrote a blog a long while back that talked about attachments and all the “neat” things you can do with them with HCM P&F configuration (making them required/optional, showing they exist but not allowing the user to open/download, show/hide, etc). The idea for this blog is a bit different though and came from an interesting requirement from a previous client.

The client’s requirement was simple, but had me scratching my head at first.  As part of a “Hiring” process, the initiator can (optional) attach a “Sign On Reimbursement Letter” (ie. sign on bonus).

Likewise, there are fields on the form to enter Sign On Bonus information.

After the initiator sends this on to the next person, the client wanted us to put logic in place that would see if the initiator entered a Sign On Bonus amount, and if so, it should check to see if a “Sign On Reimbursement Letter” was attached. After checking for the attachment, it should display a message on the form about whether an attachment was found or not and what this meant. For example, if an attachment was found, it appears as (displays icon and message “Sign On Agreement is attached.”):

If the attachment was not found, it appears as (displays icon and message “Sign On Agreement is NOT attached. This payment will be locked until the Sign on Agreement is received.”) :

So that was that. Sounds easy enough, right? Maybe? No? Well, for me, this one was quite new. I had to come up with a way for the form to check “outside” of itself in a manner of speaking….and this actually turned out to be much simpler than I expected.

On the HCM P&F side, I set up a single field, “FLAG_SIGNON_ATTACH” defined as CHAR1 (one character data type).  Then I wrote a very simple generic service with and operation “CHECK_SIGNON”  that mapped over the FLAG_SIGNON_ATTACH field and the PROCESS_REFERENCE_NUMBER field (the standard, reserved field that the framework handles for us to hold our process reference number for our process). I wrote a private method generic enough to handle any attachment type that was configured in HCM P&F (in that way, this generic service could be reused for any attachments). The call to the method appears as:

*== Call our method for actual Business Logic and data collection
*       Check for sigon agreement

        CALL METHOD me->check_attachment_exists
          EXPORTING
            proc_ref_num    = w_proc_refnum
            attach_type     = c_signon_agreement
          IMPORTING
            flag_attached   = w_flag_signon
            message         = message_dummy.

Where C_SIGNON_AGREEMENT  is a constant (attribute of our class) defined with our attachment type “code” as configured in our process. In our case, it was “ZH_SIGNON” . The method would then return back to us a value of “X” if the attachment was found or empty/blank if it was not. The internals of the method were pretty simple….much more so than I first thought. I actually poked around in the “Start Application” WDA to figure out how it was reading/detecting attachments. I figured that somehow it knows for my process what the previous users have attached so certainly that was a good place to start. It was fairly easy to find and I  “borrowed” similar logic. The method became:

(* This is where I make life miserable for the “cut-and-paste coders” hahahahahaha)

The last part was over on the form side. I used a hidden field to bind my FLAG_SIGNON_ATTACH field to and then checked its value in the  “form ready” event script. Based on the value (rawValue = “X”?), I would either show (set presence to “visible”) a hidden success(attached) or fail (not found) message.

I had this “operation” set up to be called when the initiator did a “check and send” if the sign-on amount was greater than zero (i.e. had a value) via a “rule”. Then the “flag” was set and would show them the message. That gave them a chance to go back and attach the letter if they needed to.  After that, I set up my configuration to pass (transfer of fields) the “flag” value to the next form scenario. Because it was set correctly from the initiator, the form handled everything for me (ie. no need for another check or initialization to be configured in the backend).

I learned some interesting things with this one and added another “trick” to my HCM P&F toolbox. With  a little thought, you can probably come up with some more ideas of how to do some similar things….and yes, I later got to do some much more “interesting” than this, but this lesson sure helped out! Hope you like this one . As always…till next time….