Error updating row with trigger not-null constraint

I'm using a trigger to update a tabble named tb_sign_employees with the following structure:

sign_id					INT NOT NULL,
employee_id				INT NOT NULL,
sign_term_in				CHARACTER(3) NOT NULL,
sign_data_in				TIMESTAMP NOT NULL,
sign_term_out				CHARACTER(3),
sign_data_out				TIMESTAMP,
	sign_time_minutes			INT,

The primary key is sign_id.
I need to use a trigger tg_sign_inserted()so when I insert the employee_id and the sign_term_in it automaticaly inserts a new sign_id which is one plus the greatest sign_id and the sign_data_in which is the current timestamp, leaving the rest as null. Then whith the same function if I insert an employee_id and the sign_term_out it should update the sign_term_out with the one i entered, the sign_data_out with the current timestamp and the sign_time_minutes as the sign_data_out minus the sign_data_in in minutes.
Also you can't insert if you already had done it before but not updated the values, if you check in but don't check out is imposible to check in again. And if you have already checked out it's not possible to check out, you can't use sign_tern_in and sign_term_out while inserting.
I have tried with:

CREATE OR REPLACE FUNCTION erp.fn_check_sign_inserted_values(new_sign erp.tb_sign_employees)
RETURNS BOOLEAN AS $$
BEGIN
    IF new_sign.sign_term_in IS NULL AND new_sign.sign_term_out IS NULL THEN
        RAISE EXCEPTION 'Cal informar de sign_term_in o sign_term_out';
    END IF;

    IF new_sign.sign_term_in IS NOT NULL AND new_sign.sign_term_out IS NOT NULL THEN
        RAISE EXCEPTION 'Cal informar de sign_term_in o sign_term_out, no els dos';
    END IF;

    IF new_sign.sign_term_in IS NOT NULL THEN
        IF new_sign.employee_id IS NULL THEN
            RAISE EXCEPTION 'Cal informar del id del empleat';
        END IF;

        IF EXISTS (
            SELECT 1
            FROM erp.tb_sign_employees
            WHERE employee_id = new_sign.employee_id
            AND sign_term_out IS NULL
        ) THEN
            RAISE EXCEPTION E'Ja hi ha un registre d''entrada sense sortida';
        END IF;
    END IF;

    IF new_sign.sign_term_out IS NOT NULL THEN
        IF new_sign.employee_id IS NULL THEN
            RAISE EXCEPTION 'Cal informar del id del empleat';
        END IF;

        IF NOT EXISTS (
            SELECT 1
            FROM erp.tb_sign_employees
            WHERE employee_id = new_sign.employee_id
            AND sign_term_out IS NULL
        ) THEN
            RAISE EXCEPTION E'Ja hi ha un registre d''entrada sense sortida';
        END IF;
    END IF;

    RETURN TRUE;
END;
$$ LANGUAGE plpgsql;
CREATE OR REPLACE FUNCTION erp.tg_sign_inserted()
RETURNS TRIGGER AS $$
BEGIN
    IF NOT erp.fn_check_sign_inserted_values(NEW) THEN
        RETURN NULL;
    END IF;

    IF NEW.sign_term_in IS NOT NULL THEN
        INSERT INTO erp.tb_sign_employees (sign_id, employee_id, sign_term_in, sign_data_in)
        SELECT COALESCE(MAX(sign_id), 0) + 1, NEW.employee_id, NEW.sign_term_in, current_timestamp
        FROM erp.tb_sign_employees;
    ELSIF NEW.sign_term_out IS NOT NULL THEN
        UPDATE erp.tb_sign_employees
        SET sign_term_out = NEW.sign_term_out,
            sign_data_out = current_timestamp,
            sign_time_minutes = extract(epoch from current_timestamp - sign_data_in) / 60
        WHERE employee_id = NEW.employee_id
        AND sign_term_out IS NULL
        AND sign_term_in IS NOT NULL; -- Agregamos esta condición para actualizar solo las filas con sign_term_in ya definido.
    END IF;

    RETURN NEW;
END;
$$ LANGUAGE plpgsql;

CREATE TRIGGER tg_insert_sign_employee
BEFORE INSERT ON erp.tb_sign_employees
FOR EACH ROW
EXECUTE FUNCTION erp.tg_sign_inserted()

And when I use:

INSERT INTO erp.tb_sign_employees(employee_id, sign_term_in)
VALUES(1, 'Terminal1')

It works just file but if then i use:

INSERT INTO erp.tb_sign_employees(employee_id, sign_term_out)
VALUES(1, 'Terminal1')

Instead of filling the row generated by the prior command it tries to create a new row that would look like this:
(null, 1, null, null, EP, null, null)
Resulting in a violation of the not-null constraint in the column sign_id. The fact that it doesn't update the column is an error but not the only one since the column that is trying to create contains null instead of inserting the current timestamp in sing_data_out.
I can't see the error.
To give you an example of how it should behave imagine that the greatest sign_id is one.
Then using the day 2023-03-06 at 9 o'clock:

INSERT INTO erp.tb_sign_employees(employee_id, sign_term_in)
VALUES(1, 'Terminal1')

Should create the following line:

2, 1, Terminal1, 2023-03-06 09:14:00, null, null, null

And if I executed the following the same day at 12 o'clock:

INSERT INTO erp.tb_sign_employees(employee_id, sign_term_out)
VALUES(1, 'Terminal2')

2, 1, Terminal1, 2023-03-06 09:00:00, Terminal2, 2023-03-06 12:00:00, 180

Where 180 is the difference in minutes between 12 and 9 o'clock.
Thanks in advance.

Your trigger has a couple major problems. As written above it will not insert the initial row as claimed. Your trigger fires on an insert to table erp.tb_sign_employees. Then within the trigger it attempts to do the same:

IF NEW.sign_term_in IS NOT NULL THEN
        INSERT INTO erp.tb_sign_employees (sign_id, employee_id, sign_term_in, sign_data_in)
        SELECT COALESCE(MAX(sign_id), 0) + 1, NEW.employee_id, NEW.sign_term_in, current_timestamp
        FROM erp.tb_sign_employees;

As a result the trigger fires again and since the column NEW.sign_term_in is still null the trigger fires yet again and again. It creates an infinite loop which eventually results in the exception:

> SQL Error [54001]: ERROR: stack depth limit exceeded ...;

You should not issue a DML statement in a trigger that is the same as the statement that fires the trigger in the first place. In this case it is not necessary. You can make a direct assignment or select into to the column so:

select coalesce(max(sign_id), 0) + 1
  into new.sign_id
  from tb_sign_employees;

Now we arrive at the second issue. The above is extremely poor practice as MAX+1 assignment in a multiple user environment is a virtual guarantee to get a duplicate. It will occur when two users attempt to insert a row and the second user executes before the first user commits because each will get the same MAX value. <br/>
<br/>
Now to the issue that actually initiated your question. You state fact that it doesn't update the column is an error .... That is wrong, it does the update correctly. The problem is you effectively changed an insert into an update. However, Postgres does not recognize that change so when you when afterward return new it continues processing the insert. Since the column sign_in has not been assigned a value and is not auto generated it is NULL and therefore you get the null value exception and the insert is aborted. Unfortunately, the update is also aborted (rolled back) so it appears to have not been done. The correct way to handle this is to just issue an update instead of the second insert. However there is an unconventional work around. After the update do not issue return new instead issue

return null;

Returning null terminates further processing on the insert, but will leave the updated row. (Row counts, if taken will be off, a terminated insert does not count as processed row.) Taking all this into account your trigger function becomes:

create or replace function tg_sign_inserted()
  returns trigger 
 language plpgsql
as $$ 
begin

    if not fn_check_sign_inserted_values(new) then
        return null;
    end if;

    if new.sign_term_in is not null then
        select coalesce(max(sign_id), 0) + 1
          into new.sign_id
          from tb_sign_employees ;
        return new;
    
    elsif new.sign_term_out is not null then

        update tb_sign_employees
        set sign_term_out = new.sign_term_out,
            sign_data_out = current_timestamp,
            sign_time_minutes = extract(epoch from current_timestamp - sign_data_in) / 60
        where employee_id = new.employee_id
        and sign_term_out is null
        and sign_term_in is not null; -- agregamos esta condición para actualizar solo las filas con sign_term_in ya definido.
        
        return null; -- tell Postgres to stop Processing the Insert
    end if;

end;
$$;

See demo here. NOTE: For demo I have hard coded the timestamps you mentioned and corrected for the following. <br/>
Finally, your initial insert would fail even without the mentioned issues for 2 additional reasons, perhaps just typos. 1. The columns sign_term_in and sign_term_out are defined as CHARACTER(3), but you want to insert the values Terminal1 and Terminal2. Those values will cause an exception as they will not fit in the allotted field limit. 2. The column sign_data_in is defined as not null, but no default given and not referenced on insert. Therefore it would raise a null value exception. <br/>
<br/>
You state your orders are to not modify the structure. Well to insert the values indicated you must modify the structure. When you discuss that with those giving your orders know let them how bad the MAX+1 is for assigning the sign_id and get it changed as well. Change both and you most likely can eliminate the trigger all together.