In my other recent blog ( https://blogs.sap.com/2020/01/21/ess-2020-w-4-filing-status-fix/ ), I addressed a gap in how the ESS W4 Webdynpro application provides the drop-down list values for the "filing status" (martial status) given the changes that have come about for the 2020 form due to IRS changes.
This blog addresses a similar/related issue that you will likely happen upon as well.
Now, not to rehash what I said before in the other blog, but it is fairly well-known that SAP's rollout of their "standard" ESS W4 application to address the new 2020 updates has been far from stellar. As I said before, this is not wholly their fault as the IRS was "dragging their feet" on finalizing the "official" form requirements, layout, etc., so SAP was having to develop towards a moving and not well defined target. I guarantee you that as "bad" as it seems it went for SAP, it is far worse for several of their competitors who had nothing to offer up of mention (I believe we call that "getting caught with their pants down" haha). Anyways, I HIGHLY recommend following these two blogs as they have been updated almost daily with information. The comments section on both are the best as an exchange of information between customers has been just as valuable as the blog content itself:
https://blogs.sap.com/2019/12/07/w-4-form-for-year-2020/
https://blogs.sap.com/2019/12/16/w-4-employees-withholding-certificate-and-federal-income-tax-withho...
Now, where was I........ah yes....the "filing status" value issue....here we go.....
When creating a "new" infotype 2010 for FEDeral filing, the system basically takes the employee's previous record, creates a "copy" of it and assigns it a new begin date (BEGDA) which can be based on a number of things (it can be today's date, next payroll control record date or really anything you like as it can call the BAdI HRXSS_PER_BEGDA to determine the value). The problem is that if the employee's previous record used the "old" values (ex. '01' for single or '02' for married) these will be copied and appear on the screen. However, we do not want to allow (or even show) these because they are not valid for 2020 anymore (again, this is shown and explained in my previous blog https://blogs.sap.com/2020/01/21/ess-2020-w-4-filing-status-fix/ ). To the employee/user if we made the enhancement mentioned in the other blog to remove the "old" values in the drop-down list, it appears as:
Because the value '01' is no longer a value in the drop-down to match it too, it simply just displays the value. Not only is this confusing to the user ("What is 01 ?!??!?") but it is also an invalid value.
In the W4 application (HRESS_C_W4), the component controller has a method SET_TXSTA_PROPERTIES which we can "piggy back" on in order to make our change. This makes sense for us since the field is TXSTA (so we are not just throwing code in anywhere haha). To correct this, it really depends on your own need. You have two options:
In either case, here is what the code will look like:
The "enhancement" portion is noted in the comments. It is pretty straightforward. All we are doing is checking the begin date (BEGDA) on the infotype 0210 record and if it is greater than 12/31/2019, we then check if the filing status is 1 or 2 and add 2 to it in order to correctly map it to the "new" values for 2020 and onward. Of course, the employee/user is free to then change this if needed.
With the change n place and active, the employee/user will not see an "invalid" value listed for their record when it is created/copied for 2020 and onward.
BEFORE
As always, hope this helps!
This blog addresses a similar/related issue that you will likely happen upon as well.
Now, not to rehash what I said before in the other blog, but it is fairly well-known that SAP's rollout of their "standard" ESS W4 application to address the new 2020 updates has been far from stellar. As I said before, this is not wholly their fault as the IRS was "dragging their feet" on finalizing the "official" form requirements, layout, etc., so SAP was having to develop towards a moving and not well defined target. I guarantee you that as "bad" as it seems it went for SAP, it is far worse for several of their competitors who had nothing to offer up of mention (I believe we call that "getting caught with their pants down" haha). Anyways, I HIGHLY recommend following these two blogs as they have been updated almost daily with information. The comments section on both are the best as an exchange of information between customers has been just as valuable as the blog content itself:
https://blogs.sap.com/2019/12/07/w-4-form-for-year-2020/
https://blogs.sap.com/2019/12/16/w-4-employees-withholding-certificate-and-federal-income-tax-withho...
Now, where was I........ah yes....the "filing status" value issue....here we go.....
Issue
When creating a "new" infotype 2010 for FEDeral filing, the system basically takes the employee's previous record, creates a "copy" of it and assigns it a new begin date (BEGDA) which can be based on a number of things (it can be today's date, next payroll control record date or really anything you like as it can call the BAdI HRXSS_PER_BEGDA to determine the value). The problem is that if the employee's previous record used the "old" values (ex. '01' for single or '02' for married) these will be copied and appear on the screen. However, we do not want to allow (or even show) these because they are not valid for 2020 anymore (again, this is shown and explained in my previous blog https://blogs.sap.com/2020/01/21/ess-2020-w-4-filing-status-fix/ ). To the employee/user if we made the enhancement mentioned in the other blog to remove the "old" values in the drop-down list, it appears as:
Because the value '01' is no longer a value in the drop-down to match it too, it simply just displays the value. Not only is this confusing to the user ("What is 01 ?!??!?") but it is also an invalid value.
Solution
In the W4 application (HRESS_C_W4), the component controller has a method SET_TXSTA_PROPERTIES which we can "piggy back" on in order to make our change. This makes sense for us since the field is TXSTA (so we are not just throwing code in anywhere haha). To correct this, it really depends on your own need. You have two options:
- Create an overwrite enhancement for the component controller method (for the same reasons as mentioned in the other blog, ie. easy to back out if/when SAP fixes this)
- If using a custom "Z" version of the application, simply modify the component controller directly. (In our case, we were making several layout changes to the application's view and other changes as well, so we had created a "Z" version already. It uses the same assistance class that we made our "enhancement" in as detailed in the other blog, so this is a good example of weighting out when and where you make an enhancement vs. a custom version).
In either case, here is what the code will look like:
METHOD set_txsta_properties .
DATA lv_struct_name TYPE pad_sname.
DATA lv_taurt TYPE wd_this->element_it0210-taurt.
DATA ls_metadata TYPE hrpad_field_metadata.
DATA lo_nd_it0210 TYPE REF TO if_wd_context_node.
DATA lo_el_it0210 TYPE REF TO if_wd_context_element.
DATA: lv_begda TYPE begda,
lv_txsta TYPE txsta_d.
* This method verifies if properties for TXSTA field have been configured in T588MFPROP
* and overrides attributes hardcoded in the UI class
lo_nd_it0210 = wd_context->get_child_node( name = wd_this->wdctx_it0210 ).
lo_el_it0210 = lo_nd_it0210->get_element( ).
lo_el_it0210->get_attribute(
EXPORTING
name = `TAURT`
IMPORTING
value = lv_taurt ).
* Start Enhancement
* Need to map older filing statuses to newer 2020 statuses
lo_el_it0210->get_attribute( EXPORTING name = `BEGDA` IMPORTING value = lv_begda ).
IF lv_taurt = 'FED' AND lv_begda > '20191231'.
lo_el_it0210->get_attribute(
EXPORTING
name = `TXSTA`
IMPORTING
value = lv_txsta ).
* set single attribute
IF lv_txsta = '01' OR lv_txsta = '02'.
lv_txsta = lv_txsta + 2.
lo_el_it0210->set_attribute( name = `TXSTA` value = lv_txsta ).
ENDIF.
ENDIF.
* End Enhancement
* Get structure name and subtype(Tax Authority)
lv_struct_name = wd_assist->mo_feeder_model->mv_struct_name.
* Check if configuration exists in T588MFPROP
CALL METHOD cl_hr_t588mfprop=>read_metadata
EXPORTING infty = '0210'
itvers = '10'
subty = lv_taurt
sname = lv_struct_name
fname = 'TXSTA'
IMPORTING metadata = ls_metadata.
IF ls_metadata IS INITIAL.
RETURN.
ENDIF.
lo_el_it0210->set_attribute_property(
attribute_name = 'TXSTA'
property = '3' "Read Only
value = ls_metadata-readonly ).
ENDMETHOD.
The "enhancement" portion is noted in the comments. It is pretty straightforward. All we are doing is checking the begin date (BEGDA) on the infotype 0210 record and if it is greater than 12/31/2019, we then check if the filing status is 1 or 2 and add 2 to it in order to correctly map it to the "new" values for 2020 and onward. Of course, the employee/user is free to then change this if needed.
Result
With the change n place and active, the employee/user will not see an "invalid" value listed for their record when it is created/copied for 2020 and onward.
BEFORE
AFTER
As always, hope this helps!
- SAP Managed Tags:
1 Comment
