The basic function is working now, but I cannot seem to get the description correct in the text above the field.  I like the way you have completed the table above.

Also, is it possible to have rejected rows triggered by the actual status.  Right now the user would need to click "add" to make it (the rejected row) appear on the form, but if the rejected item was on the last row, it is likely they would not hit add before proceeding to the next field.  This means no reason would be requested.

By the way, I LOVE that you sent me the actual code.  I am new to coding and basically have no idea what I am doing!  Thanks.

Actually, I just double checked the entire procedure and found a mistake in my entry.  I had assigned a CSS class as you instructed, but I had transposed a couple of letters when I typed it.  The description is now working. 

That's great @████████!  Is it all working for you, or are there some parts you are still having difficulties with?

Excerpt from above:

Also, is it possible to have rejected rows triggered by the actual status.  Right now the user would need to click "add" to make it (the rejected row) appear on the form, but if the rejected item was on the last row, it is likely they would not hit add before proceeding to the next field.  This means no reason would be requested.

This would be on my wish list if it is possible.

What it's doing, is adding rows to the secondary table every time they are added to the first table, but then hiding them by default.  So if the first table has five rows, the second table has five rows too, but some of them may be hidden.  Whenever a row in the first table has its Status field changed to Rejected, the corresponding row in the second table is shown.

So when you change a field to Rejected, the associated rejected field should appear to "pop up".

Are you not seeing it functioning that way?

I feel a problem will arise if the user does not click "Add".  If the user, navigates to the next field available for data entry (Total Coded Dollar Amount) using the mouse or tab, the rejected item table does not show.

Here is a snip of what I am seeing in the preview... I have clicked on the Total Coded Dollar Amount field with my mouse in this example. 

Weird - it should have popped up the rejected field as soon as the Status was changed to Rejected.

In your example, how was the status field changed to Rejected?  Did the user change that to Rejected, or was it populated by a lookup, or some other system process?

The user selects Approved or Rejected from a drop-down field.

Hmmm...  And the rejected field doesn't appear at the time you change the status to rejected, but it does appear after you've changed it to Rejected and then clicked add to add another row.  Is that right?

These are two different events being triggered.

The code that runs when you add the row starts on row 12 in the earlier posting - it looks like this:     $('.coding_chart_table').on('click', '.cf-table-add-row', function () {

The code that runs when you edit anything in the table (i.e. changing the status to rejected) starts on row 6 in the earlier posting - it looks like this:     $('.coding_chart_table').on('change', function () {

It almost sounds like the change code (the part starting on row 6) isn't running for some reason (which is weird, because it did for me).

Let's try this.  Add a line between rows 6 and 7 that says:     alert('testing');

It'll look like this: 

  $('.coding_chart_table').on('change', function () { 
    alert('testing');
    updateRejectedFields()
  }); //end of $('.coding_chart_table').on('change', function () { 

Then every time you change any values in the coding chart table, it should do a little pop-up that says testing.  If that doesn't pop-up, then we know that the change event is not being called on the table for some reason.

I don't think this is it - but it is also possible that this could be due to different functionality in Forms, if you are on an older version that I am (I'm on 10.2).  So it would be good if you could check what version of Forms you are using.

If the 'testing' alert doesn't pop-up, you can also try this:

Change row 6 from this: 

$('.coding_chart_table').on('change', function () {

to this: 

$('.coding_chart_table').on('change', '.codingStatus select', function () { 

which will look specifically for changes to the status dropdown field instead of any changes to the coding chart table.

I've inserted the testing code.  It does appear when I make changes to the chart, but it comes up twice.  I'm not sure why.

In regards to the version, I am using currently using 10.1.  I was just about to upgrade after the conference, but the organization decided to hold off due to a hotfix that was in development.

Some of those events get called twice, I don't know why.  It just means it runs the code an extra time unnecessarily.  But unless your table gets tremendously large, the extra run shouldn't cause problems.

Since the alert pop-up is appearing, that does mean it is being triggered by the event, which it should be doing.  But then I'm uncertain why it is properly running the fields updates when you add a row, but not when you change one...

I can't imagine the 10.1 vs. 10.2 version is the issue.

Let's try this, to see if we can narrow it down.

Remove that code you inserted after row 6:     alert('testing');

We're going to put similar code down below, to see if we can narrow down where in the process it is getting hung up.

The code between rows 34 and 49 look like this: 

  function updateRejectedFields() { 
    $('.codingStatus select').each(function() { 
      var theRowIndex = $(this).closest('tr').index();
      var tableRowIndex = theRowIndex + 1; 
      if ($(this).val() == 'Rejected') { 
        var glValue = $(this).closest('tr').find('.codingGL input').val();
        var amountValue = $(this).closest('tr').find('.codingAmount input').val();
        var newText = 'Rejected Line Item: GL Code: ' + glValue + ', Amount: ' + amountValue + '. Please provide a reason.'; 
        $('.rejected_items_table tbody tr:nth-child(' + tableRowIndex + ')').show(); 
        $('.rejected_items_table tbody tr:nth-child(' + tableRowIndex + ')').find('.rejectedField label').text(newText);
      }
      else { 
        $('.rejected_items_table tbody tr:nth-child(' + tableRowIndex + ')').hide(); 
      } //end of if...else... statement
    }); //end of $('.codingStatus select').each(function() { 
  } //end of function updateRejectedFields() { 

We're going to insert several alert statements (four of them to be exact) throughout that section, to see if we can pinpoint where it's failing.  Replace that entire section of code, with this: 

  function updateRejectedFields() { 
    alert('part 1');
    $('.codingStatus select').each(function() { 
      alert('part 2');
      var theRowIndex = $(this).closest('tr').index();
      var tableRowIndex = theRowIndex + 1; 
      if ($(this).val() == 'Rejected') { 
        alert('part 3');
        var glValue = $(this).closest('tr').find('.codingGL input').val();
        var amountValue = $(this).closest('tr').find('.codingAmount input').val();
        var newText = 'Rejected Line Item: GL Code: ' + glValue + ', Amount: ' + amountValue + '. Please provide a reason.'; 
        $('.rejected_items_table tbody tr:nth-child(' + tableRowIndex + ')').show(); 
        $('.rejected_items_table tbody tr:nth-child(' + tableRowIndex + ')').find('.rejectedField label').text(newText);
      }
      else { 
        alert('part 4');
        $('.rejected_items_table tbody tr:nth-child(' + tableRowIndex + ')').hide(); 
      } //end of if...else... statement
    }); //end of $('.codingStatus select').each(function() { 
  } //end of function updateRejectedFields() { 

When you first preview the form, you should get alerts for part 1, part 2, and part 4.

Then change the status field to Rejected.  You should get six alerts for part 1, part 2, part 3, and then repeat for part 1, part 2, part 3.  After you click Okay on the sixth alert, the rejected field should appear.

Can you give that a try, and let me know if you see all the alerts I indicated?

Done. I received the alerts in the following order...1,2,4 for the first step.  Oddly, the one didn't show up the repeat.

When I change it to rejected, I get 1,2,4,2,3 (1,2,4,2,3).  The brackets indicated the repeat.  There were only five alerts.

Where it did 1,2,4,2,3, that is acting like you have two rows in the Coding Chart table, the first is not set to Rejected, but the second is.  

Was that the case, or was there only one row?

Here's what the five steps are telling us:
1 = process was triggered.
2 = cycle through the first codingStatus field
4 = the first field is not marked as rejected
2 = cycle through the second codingStatus field
3 = the second field is marked as rejected (at this point, the hidden row in the Rejected table should be shown).

No, the first row was being rejected in the above scenario.  I still need to click "Add" before the Rejected Items table appears.  Once I do that, it goes through the messages again.

Weird.  That's not really how it should be reacting.  It should be having the rejected table appear as soon as you change the staus in the first row to rejected.  Would you be willing to share a copy of your BP?

This is the section of the process that deals with the form in question.  It's pretty basic.

How about the form?  Does it only have the structure listed out in the previous posts?  Or does it have a lot of other stuff going on?  Just trying to figure out why the functionality would be different for you than for me...

The process starts with a Invoice Entry form, then it moves to the Invoice Coding form (this is an optional process based on selections in the first form).  The table is seen first on the Invoice Coding form, but it does not include the Status column or the Approved/Rejected column, as above. The coder fills in the information and selects the approver.  The business process routes the information to the appropriate person. If the submission does not require coding, it would go directly to the approver; who would need to fill out the table on the approval form.

The Approval form contains the table, including any previous information that is entered.  The Status column and the Approved/Rejected columns have bee added to the table.  The approver then selects approve/reject for each line item.  The Approved/Rejected by: field is automatically populate by the current user name. 

Once completed, the approver selects Submit to continue the process.

I'm going to go through everything (Again!) to ensure that I have everything just as you stated above.  I copied and pasted the code, so that should be right.  I will double check my field set up.

If we don't come up with anything, I will wait for an update.  I'm scheduled next week, I think.  Maybe that will help.

I'm not seeing anything that would explain why it doesn't seem to be working as soon as the approver changes the status to reject...  I'm kinda stumped.

I appreciate your help.  I will post the answer to the glitch, if/when I figure it out.

I think you have answered my original question, so I will mark this questions as "Answered".   

If you are definitely scheduled for upgrade to 10.2 next week, let me know how it's going after the upgrade.  I still don't think that should be the issue, but who knows?

You were correct.  The update did not solve the issue. I'll figure it out eventually...

Oh no!  That's so weird - I went back to my version of the form I set-up when I originally replied to your post, and it's still working as expected for me.