Greenshades Common Errors

• Option One: Customization

  Bullhorn has built a customization to make that field read only and it is connected to the Placement TimesheetCycleID field. When the TimesheetCycleID field is updated, the GS Pay Schedule field will update with the matching text. Product is working on a templatized solution for this but Peoplelink has this applied so a SWE can use that version but it is mapping dependent so you’ll need to verify the mapping of TimesheetCycleIDs matches your payGroup list.

• Option Two: Adjusting one of the values.

  The end user will need to align the two values by adjusting either but both changes have different impacts and steps.

  • Adjusting the GS Pay Schedule to match the TimesheetCycleID value will change the Pay Schedule in GS to match the new value.

    • If the time in BTE was added in the correct branch based on WorkWeekStart date (set by the TimesheetCycleID in the ATS), adjusting the TimesheetCycleID will allow the time to flow over to GS correctly.

    • If the time in BTE was entered on the wrong branch (based on when the TimesheetCycleID was adjusted, BTE may have two branches with the same placement information), the time should be deleted from the wrong branch in BTE and re-entered on the correct branch. The time should then flow to GS correctly.

  • Adjusting the TimesheetCycleID to match the GS Pay Schedule.

    • The time entered in BTE will need to be deleted and new time will need to be entered on the correct branch, based on the adjusted TimesheetCycleID. That time will then flow over correctly to GS.

• Option One

  If the candidate already exists in GS, Bullhorn Support can add the existing GS ID to the candidate record or an SA can do this via Data Loader of the API.

• Option Two

  1. Open the candidate record.

  2. Verify that the Greenshades ID field is empty.

  3. Update the candidate’s Greenshades Export Status to “Ready to Export”.

  4. The integration sync should run, reload the candidate and confirm the Greenshades ID is now populated.

  5. Export the payable charges again.

If the candidate does not exist in GS, an end user can either update the Placement Status from Approved to Submitted and then back to Approved, or change the Placement Greenshades Sync Status to Ready to Export.

The error should tell the end user which field is missing information. That field will need to be updated before the payable charge can be re-exported.

That charge should not be included in a Greenshades batch, but should be sent to via the Accounts Payable process.

• Migrated Record: The SSN was missing during the initial GS ID seeding process. Look up the necessary GS ID within GS and contact BH Support to add the ID to the candidate record in Bullhorn (or add the missing value via Data Loader or the API).

• New Record: Either update the Placement Status from Approved to Submitted and then back to Approved, or change the Placement Greenshades Sync Status to Ready to Export. This will cause the placement information to resync with Greenshades, including the new DD account information.

An end user can either update the Placement Status from Approved to Submitted and then back to Approved, or change the Placement Greenshades Sync Status to Ready to Export. This will cause the placement information to resync with Greenshades

An end user needs to update the transaction to use the correct settings based on the earn code type.

Log into Greenshades and see if the GS ID on the candidate can be found. The ID may be connected to a deleted GS record. If the ID is not found or the record is marked as deleted, please contact BH support to have the GS ID removed from the candidate record in BH.

Resend via BH export process.

Have the employee re-enter their full direct deposit information via their onboarding platform. Once complete, that information will automatically sync to Greenshades, assuming the employee is still on an approved placement. If their placement is no longer approved (ended or completed), no data will sync and the customer team will need to reapprove the placement before the new direct deposit information will update.

Verify that the correct GS ID is on the BH candidate record. It is possible that the corresponding GS record was soft deleted, as part of a clean up process which requires either the GS record to be undeleted or and GS ID in BH to be updated to an existing GS record. If the client has multiple workspaces, the GS ID might not exist in that specific workspace which would require a new candidate CO be created with the

First, verify that the location does not exist. Most likely, the location does exist, but due to the way that a location is created when multiple new placements sync, this can be a false negative error. If the location does not exist, try and resync the placement.

Check the following data points:

• Candidate

  • Greenshades ID

• Placement

  • Placement ID

  • Greenshades Pay Schedule

  • Work Location

• Payable Charge

  • Period End Date

  • Pay Rate

  • Earn Code

1. Check the placement record’s edit history to see if any recent changes were made to the record.

   • Candidate

     • Greenshades ID

   • Placement

     • Placement ID

     • Greenshades Pay Schedule

     • Work Location

   • Payable Charge

     • Period End Date

     • Pay Rate

     • Earn Code

2. If no changes were made to the placement, confirm in Greenshades if the previous transaction was omitted from a pay run.

Fill in the Greenshades Workspace ID/Legal Business Entity on the placement record. Then attempt to export the payable charge again.

Fill in the Workers Comp Code field on the placement record. Then attempt to export the payable charge again.

Double check the earn codes used. If you can not find the misused earn code, contact Bullhorn Support.

Double check the earn codes used. If you can not find the misused earn code, contact Bullhorn Support.

Work locations should be created when an assignment is successfully synced to GS, assuming the following:

• Location does not currently exist (based on BH location code - Client ID + LocationID)

• Location contains all necessary information.

  • Title

  • All parts of the address

• If the work location has all those fields but it’s not created, reach out to GS support.

Position Code equals Workers Compensation Code. Verify the Workers Compensation Code used on the placement also exists in Greenshades.

Verify the check date is correct. If necessary, reach out to Greenshades Support to have the necessary pay period opened.

• If the Greenshades ID on the candidate record is correct: The Greenshades employee needs to be re-activated.

• If the Greenshades ID on the candidate record is incorrect:Find the correct Greenshades employee record and have support update the GS ID on the candidate record in BH.

  • If the employee does not exist in Greenshades, support will need to remove the existing Greenshades ID on the candidate record in BH

  • On the current approved placement in Bullhorn, an end user can either update the Placement Status from Approved to Submitted and then back to Approved, or change the Placement Greenshades Sync Status to Ready to Export.

Verify if that selected Earn Code does exist in Greenshades.

• If it does not but should exist, reach out to Greenshades Support or your internal Greenshades contact to have that information updated.

• If all the Earn Codes do exist, reach out to Greenshades Support for additional assistance.

Verify that the Time and Expense Branch exists in Greenshades. If not, reach out to Peoplelink management to verify the Branch was setup correctly in both Bullhorn and Greenshades.

• Option One

  1. Find the employee in GS from the Employee List.

  2. Navigate to their Pay Statements.

  3. Locate the correct closed historical pay run.

  4. Copy the Pay Run ID.

  5. Go to Past Pay Runs and search for the correct pay run.

  6. Open the run and select Adjust on the right hand side.

  7. Select Overpayment from the Reason List on the left side. This will create an adjustment pay run instead of a special pay run.

  8. Search for the correct employee ID and select the check box on the left side.

  9. Once you have all the employees you need to adjust whose original transactions were in this pay run, click Submit

  10. On the Hours and Earnings tab, you will need to review every field to make sure those values match exactly what is in Bullhorn at this moment.

      • If any field has been updated in BH, this will cause the integration to not find the original transaction row.

      • For any items that do not match: The end user will need to decide which of the two applications is correct and make the appropriate adjustments.

  11. Once the existing transaction and the failed transaction have matching information, find the failed payable charge in Bullhorn on the payable charge screen.

  12. Select the check box on the left side of that payable charge.

  13. Once selected, a new action menu will appear and within there, select Mark as Ready.

  14. The screen will refresh and the status of the payable charge will update to “Ready to Export”

  15. Select the check box again, and under the same menu, select Payroll Export.

  If the issue has been resolved, the payable charge should export successfully within a few minutes.If the payable charge fails again, check the issue log for the reason and proceed with the proposed solution. If the error is the same, contact GS Support for assistance.

• Option Two

  1. Review the payable charge details to see which transactions failed.

  2. Manually enter all failed transactions into Greenshades as an adjustment.

  3. Once that is complete and processed, create a Bullhorn support ticket, including the payable charge ID, to ask for the payable charge export status to be updated to “Exported”.

These transactions will need to be manually added into Greenshades. Once that is complete and processed, a Bullhorn support ticket will need to be created, including the payable charge ID, to ask for the payable charge export status to be updated to “Exported”.

Reach out to Greenshades support with the GoLocationIDs and have them verify that those locations have been soft deleted. They will need to re-enable those locations.