Anyone ever written a call to the update_emp_asg_criteria api to make the people_group_id null?
I have knocked up the following which runs but doesn't do anything (and YES it does have a "commit" in it CT)....

declare
CURSOR c1 IS
SELECT *
FROM per_all_assignments_f paaf
WHERE assignment_id = 175
order by assignment_number asc,
effective_start_date asc;

l_datetrack_update_mode VARCHAR2(2000);
l_delete_warning BOOLEAN;
l_ovn NUMBER;
l_special_ceiling_step_id NUMBER;
l_people_group_id NUMBER;
l_soft_coding_keyflex_id NUMBER;
l_group_name VARCHAR2(2000);
l_effective_start_date DATE;
l_effective_end_date DATE;
l_probation_end_date DATE;
l_org_now_no_manager_warning BOOLEAN;
l_other_manager_warning BOOLEAN;
l_spp_delete_warning BOOLEAN;
l_entries_changed_warning VARCHAR2(2000);
l_tax_district_changed_warning BOOLEAN;
l_concatenated_segments VARCHAR2(2000);
l_gsp_post_process_warning VARCHAR2(2000);

BEGIN
for r1 in c1 loop
l_ovn := r1.object_version_number;
l_datetrack_update_mode := 'CORRECTION';
l_people_group_id := null;
l_group_name := null;

dbms_output.put_line('Assignment Number: '||r1.assignment_number);

hr_assignment_api.update_emp_asg_criteria
(p_effective_date => r1.effective_start_date
, p_datetrack_update_mode => l_datetrack_update_mode
, p_assignment_id => r1.assignment_id
, p_validate => FALSE
, p_called_from_mass_update => FALSE
, p_grade_id => r1.grade_id
, p_position_id => r1.position_id
, p_job_id => r1.job_id
, p_payroll_id => r1.payroll_id
, p_location_id => r1.location_id
, p_organization_id => r1.organization_id
, p_pay_basis_id => r1.pay_basis_id
, p_segment1 => null
, p_segment2 => null
, p_segment3 => null
, p_segment4 => null
, p_segment5 => null
, p_segment6 => null
, p_segment7 => null
, p_segment8 => null
, p_segment9 => null
, p_segment10 => null
, p_segment11 => null
, p_segment12 => null
, p_segment13 => null
, p_segment14 => null
, p_segment15 => null
, p_segment16 => null
, p_segment17 => null
, p_segment18 => null
, p_segment19 => null
, p_segment20 => null
, p_segment21 => null
, p_segment22 => null
, p_segment23 => null
, p_segment24 => null
, p_segment25 => null
, p_segment26 => null
, p_segment27 => null
, p_segment28 => null
, p_segment29 => null
, p_segment30 => null
, p_employment_category => r1.employment_category
, p_concat_segments => null
, p_contract_id => r1.contract_id
, p_establishment_id => r1.establishment_id
, p_scl_segment1 => null
, p_grade_ladder_pgm_id => null
, p_supervisor_assignment_id => r1.supervisor_id
, p_object_version_number => l_ovn
, p_special_ceiling_step_id => l_special_ceiling_step_id
, p_people_group_id => l_people_group_id
, p_soft_coding_keyflex_id => l_soft_coding_keyflex_id
, p_group_name => l_group_name
, p_effective_start_date => l_effective_start_date
, p_effective_end_date => l_effective_end_date
, p_org_now_no_manager_warning => l_org_now_no_manager_warning
, p_other_manager_warning => l_other_manager_warning
, p_spp_delete_warning => l_spp_delete_warning
, p_entries_changed_warning => l_entries_changed_warning
, p_tax_district_changed_warning => l_tax_district_changed_warning
, p_concatenated_segments => l_concatenated_segments
, p_gsp_post_process_warning => l_gsp_post_process_warning
);

COMMIT;

end loop;
EXCEPTION
WHEN others then
dbms_output.put_line('ex is: '||SQLERRM);
END;
/

I've progressed it a bit (turned serveroutput on) and now getting....

SQL> @Clear_PG_Id.txt
Assignment Number: 201
Object Version Number: 10
Effective Start Date: 03-MAY-05
ex is: ORA-20001: The HR object is invalid

Cause: The HR object which is
attempted to be locked is inconsistent with the corresponding object in the HR
Schema.

Action: Retry the action with the correct object version
number.

PL/SQL procedure successfully completed.


Off to search metalink.......

Hmm, weird...

The message is suggesting that the API doesn't like the value for p_object_version_number being passed in, yet you seem to be obtaining and setting the correct value prior to the API call.

What version of the app are you on?

I've just tried this on my R12 instance, and it sort of works - there's a first!

I added a put_line in it to show me the before and after values for the ovn, and it was rather intriguing! What I saw was this:

Say there were 4 historical records for a given assignment id. I expected that the ovns would look like this:

.... before....after
r1....2........3
r2....3........4
r3....4........5
r4....5........6

In fact, they ended up looking like this:

.... before....after
r1....2........6
r2....3........7
r3....4........8
r4....5........9

It seems to cache all the values first and then start advancing the ovn from the point of the last record! As I said, weird!

What history records do you have for this assignment id?

I you try and null all the PPG segments, may you not get a row in PPG with all the values set to null?

ie. not sure you can have a null id just a row full of null values