Cattle, Bison and Buffalo

As described in the Movement section, all movements submitted to the service must clearly specify both the origin and destination locations. A movement is only considered finalized when both the sending and receiving parties acknowledge its occurrence and confirm the accuracy of the reported details.

Once a movement is reported by either the sender or the receiver, the other party will be notified (refer to the Notification section) This recipient of the notification can then review the movement.   The reviewer is not required to manually input any movement details or animal counts.      Upon confirmation, a unique movement ID is generated, agreed upon by both parties, ensuring accurate traceability of the animal movement.

The following sections outline the steps in the review process.  In this example, the two parties involved in a movement will be referred to as the “Movement Reporter” at Location A, and the “Other Party” at Location B.

For illustration, we assume that the Movement Reporter is the sender of animals from Location A, meaning this party reported the movement first. The Other Party is located at Location B, where the animals were received. The reverse scenario is possible, where the receiving party at Location B reports the movement first and becomes the Movement Reporter.  In this case, the Other Party would be at Location A.   The process remains the same for both cases, though this scenario is not shown in the examples.  

Note: Some of the steps and processes vary by species.  The outlined behaviour here applies specifically to cattle, buffalo and bison.

View & Review

Once a movement has been initiated by the Movement Reporter at Location A, a notification will be generated and made visible to all users associated with at Location B.

From this notification, users can retrieve the movement number can review the movement details to verify their accuracy.  

Alternatively, users at Location B can access all movements awaiting review by filtering for those with a status of “For Review”.

API Information

• API Name for Viewing Notifications: XXX
• API Name for Viewing Movements: XXX

Accept

If the user at Location B confirms that movement details are accurate, they must Accept the movement.  Once accepted, the movement will be considered fully complete, with both parties in agreement.

API Information

• API Name for Accepting/confirming a Movement: XXX

Reject

If the user at Location B finds the movement details to be incorrect, they have the option to amend (refer to the Amendments section) or reject the movement. Rejection is typically used when the Movement Reporter at Location A has selected the wrong destination.

Upon rejection the Movement Reporter will receive a notification and can take further action either cancelling the movement or disputing the rejection (refer to the Dispute section).

API Information

• API Name for Rejecting a Movement: XXX

Disagree with Rejection

If the user at Location A receives a notification that Location B has rejected the movement but believes the detail are correct, they have the option to dispute the rejection.   i

When this option is selected, the movement will be placed in a “Dispute” state, and the back-office team will be notified to resolve the issue with both parties as needed.

To view all movements that have been rejected by the other party, filter by a review status of “in review” and movement status of “rejected”.

API Information

• API Name for Disagreeing with a Movement Rejection: XXX

Amend

If the user at Location B finds discrepancies in the movement details but recognizes the movement, they can choose to amend or reject it (refer to the respective sections). Amendments are typically used when the movement is recognized, but there are issues such as the wrong CPH, a missing animal, or an incorrect animal number.

When Location B amends a movement, it does not alter the original information recorded by the Movement Reporter. Instead, a separate version of the movement is created for Location B, resulting in two versions—one from each party's perspective.

Upon amendment, the Movement Reporter will be notified and can either accept or reject the changes (refer to the respective sections).

API Information

• API Name for Amending a Movement as the other party: XXX

Accept Amendments

I f the user at Location A receives a notification that Location B has amended the movement, they can review both their original version, and the amended version provided by the other party.

If the user at Location A identifies an error in their original submission and agrees with the amendments made by Location B, they can update the movement to match the other party's version. This will finalize the movement, with both parties in agreement.

To view all movements amended by the other party, filter by a review status of "In Review" and a movement status of "Reported Warnings."

API Information

• API Name for Accepting an amendment from the other party: XXX

Reject Amendments

If the user at Location A receives a notification that Location B has Amended their movement, they can view the movement and see what they had recorded and the other party’s version of the movement.

If they are however do not agree with what the other party has suggested, they can reject the suggested amendments, and this movement will then be put into a dispute state and the back office will be notified and then resolve the issue with both parties as required.

To view all movements that have been Amended by the other party then review status of “in review” and movement status of “reported warnings”.

API Information

• API Name for Rejecting an amendment from the other party: XXX