How to Enable Origin Signature Not Required (OSNR) for Purolator Shipments in InfoShip/PMC

Overview

This article explains how to enable Origin Signature Not Required (OSNR) for Purolator shipments processed through InfoShip/PMC using the ConnectShip Purolator carrier integration.

OSNR allows Purolator shipments to be processed with signature release enabled. This functionality is controlled through the SIGREL_FLAG field at the shipment level in the shipping XML.

When enabling this option, any conflicting Proof of Delivery Signature settings must also be reviewed. Otherwise, the shipment may fail with the following error:

Ship Error: Package #1: SignatureRelease is invalid with Require Proof of Delivery Signature

Requirements

1. InfoShip/PMC configured with the ConnectShip Purolator carrier integration.
2. A valid Purolator shipping service, such as CONNECTSHIP_PUROLATOR.PUROLATOR.NDA.
3. Access to the shipment XML or integration mapping responsible for generating shipment requests.
4. Access to the Integration Manager (IM) code or applicable shipment processing logic to identify and modify conflicting signature requirements.
5. Access to the TEST environment to validate changes before implementation in Production.

Procedure

1. Enable the Signature Release Flag

   1. To request OSNR for Purolator shipments, add the following field at the shipment level within the <DSP_SHIP_REQUEST> XML: 
       

      <SIGREL_FLAG>1</SIGREL_FLAG>

   2. Example:
      
      <DSP_SHIP_REQUEST>    <SHIPPER>FRI_CAN</SHIPPER>    <SERVICE>CONNECTSHIP_PUROLATOR.PUROLATOR.NDA</SERVICE>    <SIGREL_FLAG>1</SIGREL_FLAG>    <PACKAGES>        <PACKAGE>            <PROOF_FLAG>0</PROOF_FLAG>            <PROOF_SIGNATURE_FLAG>0</PROOF_SIGNATURE_FLAG>        </PACKAGE>    </PACKAGES> </DSP_SHIP_REQUEST>

Note: The SIGREL_FLAG must be specified at the shipment level, not within the individual package elements.

2. Verify Proof of Delivery Settings

Signature Release cannot be used in conjunction with a requirement for Proof of Delivery Signature.

Review the following package-level fields:

<PROOF_FLAG>0</PROOF_FLAG>
<PROOF_SIGNATURE_FLAG>0</PROOF_SIGNATURE_FLAG>

These fields should not request proof or signature services that conflict with Signature Release.

3. Review Integration Manager (IM) Code

If the XML already contains the correct flag values but the shipment continues to fail, review the Integration Manager (IM) code.

In the reported scenario, the shipping request contained:

<SIGREL_FLAG>1</SIGREL_FLAG>
<PROOF_FLAG>0</PROOF_FLAG>
<PROOF_SIGNATURE_FLAG>0</PROOF_SIGNATURE_FLAG>

However, the shipment returned:

<DSP_SHIP_RESPONSE>
    <ERROR_CODE>-1</ERROR_CODE>
    <ERROR_MESSAGE>
        Ship Error: Package #1: SignatureRelease is invalid
        with Require Proof of Delivery Signature
    </ERROR_MESSAGE>
</DSP_SHIP_RESPONSE>

Root Cause: The issue was identified within the IM code, which was applying or retaining a conflicting Proof of Delivery Signature requirement during shipment processing.

To resolve the issue:

1. Review the applicable IM code and shipment mapping.
2. Identify where Proof of Delivery or signature requirements are being populated.
3. Ensure the IM logic does not apply a conflicting signature requirement when SIGREL_FLAG is enabled.
4. Update the integration logic as appropriate.
5. Retest the shipment.

Important: Even when the inbound XML explicitly contains PROOF_FLAG=0 and PROOF_SIGNATURE_FLAG=0, additional processing within the integration may affect the final shipment options passed to ConnectShip.

4. Validate the Shipment in TEST

After updating the XML and resolving any conflicting IM logic:

1. Submit a Purolator shipment using the applicable ConnectShip service.
2. Confirm that SIGREL_FLAG is set to 1.
3. Verify that no conflicting Proof of Delivery Signature requirement is being applied.
4. Confirm that the shipment processes without the SignatureRelease validation error.
5. Generate and inspect the Purolator label to verify the expected OSNR indication.

Note: The reported investigation identified the conflicting IM code. Successful label generation displaying OSNR was not documented in the discussion and should be confirmed through testing.

Assistance

If any further assistance is needed, please contact our Support team.

Related Articles