...
Invoices failing sync to KFS due constraint on FP_DV_PAYEE_DTL_T for city/town character limit (45 characters). The error shown for this is a 500 message in the HB invoice history. To fix this, The City/Town field in HuskyBuy needs to be under 45 characters. This field length is fine for the HB > KFS supplier sync but will cause issues for any DVs issued.
View file | ||
---|---|---|
|
2. Invoice failure due to no Remit assigned to the fulfillment center, causing the invoice to fail. If no remit is assigned on the supplier fulfillment center, the supplier profile will assign the -0 remit to the -1,2,3 etc as a primary fallback. In this situation below, Business Services created the remit but failed to assign it to the fulfillment center.
View file | ||
---|---|---|
|
3. Supplier sync failure due to Business Services modifying "Locations" or switching addresses between divisions. The HuskyBuy(HB) SQIN can cause issues if it's used across multiple divisions/fulfillment centers in HB. Switching addresses between fulfillment centers seems to cause issues in the integrations. If the supplier fails to sync due to the below error, creating the addresses from new should fix the issue.
-----Original Message-----
...
View file | ||
---|---|---|
|
4. Generally, seeing "Primary Fallback" on any of the fulfillment centers is bad. This seems to cause issues. Sometimes simply removing the "Primary Fallback" from the supplier in HB can fix supplier integration errors. You can remove primary fallback by editing the assigned address, assign a new address, then save. You can now assign the original address and then saving again. This should remove the fallback label.
5. Occasionally, the ERP sync will get stuck and the integration is "paused". If there is an ERP number, we can fix this using a web service. If there is no ERP number, a ticket will need to be created with Jaggaer to fix the supplier.
6. The ultimate way to resolve integration issues where the KFS vs. HuskyBuy information does not match is to compare records in PUR_VNDR_ADDR_T for the VNDR_ADDR_GNRTD_ID, and see what VNDR_DTL_ASND_ID each address id belongs to. You can also further filter down this information by using a "Y" in DOB_MAINT_CD_ACTV_IND. By performing this exercise, you can confirm what address IDs are active in KFS, and what divisions they belong to. If something does not match up against HuskyBuy, then you can narrow down where the issue is from here. See spreadsheet for example comparison (this is what I did for 3. above).
View file | ||
---|---|---|
|
<<18460-0.xlsx>>