Most likely, the problem is that the grant was done via a role. Privileges granted to a user are not available in a definer’s rights stored procedure (the default).
In SQL Developer, it is relatively easy to verify that this is the problem. If you run the command
SET ROLE none
and then run the SELECT statement, I would expect that you would get the same ORA-00942 error.
Assuming that is the case, the solution would generally be to ask that the owners of the tables in the YYY schema to grant access to the tables directly to you rather than granting access via a role. Barring that, you could define your stored procedure as an invoker’s rights stored procedure by adding AUTHID CURRENT_USER to the declaration. That would that the caller of the procedure would need to have access to the underlying objects but it would allow your procedures to make use of privileges granted through a role.
If you want to create an invoker’s rights stored procedure, you will also need to refer to the table name using dynamic SQL in order to defer the privilege check to runtime. So you would have something like
CREATE OR REPLACE PROCEDURE PRC_SOMESP
AUTHID CURRENT_USER
AS
l_cnt pls_integer;
BEGIN
EXECUTE IMMEDIATE 'SELECT COUNT(*) FROM yyy.TableA' INTO l_cnt;
END PRC_SOMESP;
if you wanted an invoker’s rights stored procedure that queried the TableA table in schema XXX.