Hi,

It is important to clarify that the behavior differs depending on whether the order pull failed or the agreement generation failed.
Below are the steps to identify each scenario.

1. How to identify if the Order Import/Pull failed

Option A — ECC Dashboard

1. Open the ECC Dashboard
2. Search for the order number
3. Go to the Exceptions tab and verify if any exception is displayed

Option B — Database Queries

Run the following query and look for error indicators in the columns
INTERNAL_DOCUMENT_STATUS, IGT_ERROR_DESC, IGT_ERROR_TITLE:

select *
from igt_document_requests
where igt_document_id = 'order_number'
order by creation_date desc;

Then validate the exceptions table (should match what you see in ECC):

select *
from pa_igt_exceptions
where document_number = 'order_number'
order by creation_date desc;

If you find an exception here, the order pull/import failed.

2. How to identify if the Order Pull was successful but Agreement Generation failed

First, verify the order record:

select *
from pa_igt_order
where order_number = 'order_number';

• If the row exists → Order pull was successful
• Check column LINK_AGREEMENT_ID
  • If NULL, it means that the agreement was not generated

Confirm the agreement does not exist:

select *
from pa_agreement_versions
where agreement_id in (
select link_agreement_id
from pa_igt_order
where order_number = 'order_number'
);

3. Root Causes When Agreement Generation Fails Due to ALC Issues

If you confirm that the order exists but the agreement was not generated due to ALC validation, there are two possible causes:

A. Custom Extension Logic Issue

If you are using your extension:

pa_client_extn_igt_cust.Return_Customer_Num

Validate that the logic returns a correct and valid customer number.

B. Seeded Behavior — 1:1 ALC to Customer Requirement

If seeded logic is used, EBS requires a strict 1:1 relationship between ALC and customer_number.

The application validates using the following SQL:

SELECT 'T'
FROM DUAL
WHERE EXISTS (
SELECT 1
FROM pa_customer_lov_v
WHERE customer_number = '<Customer_num>'
)
AND EXISTS (
SELECT 1
FROM hz_cust_accounts_all
WHERE account_number = '<Customer_num>'
AND customer_class_code = 'FEDERAL'
);

If the query returns no rows, there are two possible issues:

1. Mismatch between ALC and customer account
   → The ALC is not linked to the expected customer number
2. Customer class code is not FEDERAL
   → Agreement creation requires the class code to be FEDERAL

4. How to Troubleshoot

To identify the exact root cause:

1. Execute each subquery independently
2. Temporarily comment out the customer_class_code filter to see if this is the source of the failure
3. Based on findings:
   • If customer_class_code is incorrect, update it to FEDERAL
   • If the ALC–customer mapping is incorrect, register the correct account with the appropriate customer

5. If the Issue Is Resolved (Queries Now Return Rows), You May Need to Create the Agreement Manually

If you identify the root cause, fix it, and now the validation queries return rows, but the agreement still does not exist, you may need to manually create it.

How to Create the Agreement

1. Go to the ECC Dashboard
2. Search for the order and select the checkbox next to it
3. Click the three-dot options menu (upper-right corner)
4. Select Create Agreement
5. Wait for the confirmation message

After Creating the Agreement

A. Try Opening the Update Agreement Page

• If the page is accessible → Agreement creation succeeded

B. If the page is not available

Run the ECC Data Load program to refresh the dashboard.

C. If the agreement still does not appear

Run the verification query again:

select *
from pa_agreement_versions
where agreement_id in (
select link_agreement_id
from pa_igt_order
where order_number = 'order_number'
);

• If no rows returned, then the system was unable to generate the agreement
• This may indicate an internal issue → you may need to raise an SR with Oracle Development for further investigation