VBCS scripted pick confirmation fails in warehouse management

ERP Oracle Fusion Cloud
, , , , , , , ,
1

We’re running into a blocking issue with our VBCS-based pick confirmation automation in warehouse management. The script handles bulk pick confirmations via REST API calls, but we’re getting ORA-20001 errors during LPN status validation.

The VBCS script processes multiple pick tasks in a single batch:

const confirmPayload = {
  lpnNumber: batchData.lpn,
  taskIds: selectedTasks.map(t => t.id)
};
await RestService.post('/wms/picks/confirm', confirmPayload);

Error occurs when the script attempts to validate LPN status before confirmation. This is delaying our outbound shipments significantly. Has anyone implemented VBCS scripting for bulk pick confirmations successfully?

system 2

I’ll address all three focus areas systematically to resolve your bulk pick confirmation issues.

VBCS REST API Scripting Fix: Your current script lacks proper LPN lifecycle validation. Modify your VBCS code to include status and lock validation:

const lpnStatus = await RestService.get(`/wms/lpns/${lpnNumber}/status`);

if (lpnStatus.state !== 'PICKED' || lpnStatus.isLocked) {

  throw new Error(`LPN ${lpnNumber} not ready`);

}

Bulk Pick Confirmation Approach: The ORA-20001 error occurs because you’re not handling the LPN revision control. Each LPN has a version number that must match during updates. Restructure your payload:

const payload = {

  confirmations: batchData.map(item => ({

    lpnNumber: item.lpn,

    revisionId: item.revision,

    taskIds: item.tasks

  }))

};

LPN Status Validation Strategy: Implement a three-step validation process:

  1. Query LPN status and lock state before batch processing
  2. Filter out locked or invalid LPNs from your batch
  3. Use optimistic locking with retry logic for the remaining LPNs

Add retry logic in VBCS:

for (let attempt = 0; attempt < 3; attempt++) {

  try {

    await RestService.post('/wms/picks/confirm', payload);

    break;

  } catch (e) {

    if (e.code === 'ORA-20001' && attempt < 2) {

      await sleep(2000);

    } else throw e;

  }

}

The key is separating your batch into validated LPNs and processing them with proper revision control. This eliminates the ORA-20001 errors while maintaining bulk operation efficiency. Your outbound shipment delays should resolve once the LPN lifecycle validation is properly implemented in the VBCS script.

This draft is based on general Oracle Fusion Cloud knowledge. It has not been verified against your specific version and environment. Practitioners: verify the steps and share your experience below.

3

We faced similar ORA-20001 errors in our VBCS automation. The issue was the LPN status check timing. Are you validating the LPN status before the bulk confirmation call? The status might be transitioning when you query it.

4

Yes, we’re doing a pre-validation check. The script queries LPN status, then proceeds with confirmation. Should we be using a different API endpoint for status validation, or is there a specific LPN state we need to check for?

5

The ORA-20001 typically indicates a business rule violation in the LPN lifecycle. When doing bulk confirmations, you need to ensure all LPNs in the batch are in ‘PICKED’ status and not locked by other transactions. VBCS REST calls don’t automatically handle LPN locking like the standard UI does. You might need to implement explicit lock checking in your script before attempting the bulk operation. Also verify that your REST API payload includes the LPN revision number to prevent stale data issues.

6

Adding to the lock checking point - we implemented a pre-flight validation in our VBCS script that queries the LPN lock status using a separate REST call. This reduced our ORA-20001 errors by about 80%. The remaining 20% were due to timing issues where LPNs got locked between our validation and confirmation calls.

robert_user 7

Tested this on Oracle WMS Cloud 23D with VBCS REST calls — adding the LPN status and lock validation before bulk pick confirmation eliminated our ORA-20001 errors completely.

8

That makes sense. How do you handle the timing gap between validation and confirmation? Do you retry failed confirmations, or is there a way to lock the LPNs during validation?

9

For the timing gap issue, implement optimistic locking with retry logic. We use a two-phase approach in our VBCS automation.