In both examples the object of the exercise was to have a cube dropped with physics and still have it ending up exactly on target.
This was achieved by baking the physics actions and manually adjusting (biasing) those resultant sequences to get the cubes to where they're supposed to be.
To do this, the graph editor was used to drag the X/Y axis' keyframes as a whole up and down in the Editor's Y axis. (one axis at a time and with only the appropriate keyframes selected)
Select the keyframes and press keys G Y to ensure no inadvertant drift to the left or right.
For those without Graph editor experience...
Set up a test file and give a cube horizontal momentum then switch it's physics to Dynamic to drop it to a ground plane that has passive physics.
Use the Graph editor's keyframe handles to adjust the cube's X/Y axis Bezier curves into a straight line (end of the slope) at the drop frame. (where you switch from Animated to Dynamic physics)
This will ensure the cube has inertia at the switchover and will slide across the plane when it lands.
Once it's landing, bouncing, & sliding as desired, bake the entire sequence from frame 1 to where it comes to rest. (in the bake panel, tick all boxes and enter the frame range required)
This will snapshot every frame in the selected range and store the action as keyframes, but with a catch!
Baking will remove constraints that might exist on the object but not do the same with the physics.
Consequently - Don't play the animation just yet !
Instead, manually switch off the physics, and also get rid of the two redundant physics strips left behind in the Dopesheet.
With them gone it's safe to play the baked frames and carry out the Graph editor biasing.