When running a program it sometimes selects one joint angle then occasionally it flipped to another make the joint hit the part

There are two solutions and you are close to being able to use either. Add an intermediate point that makes the arm rotate in the direction you want and then that won’t happen. That’s pretty common when you have roughly 180 degrees of rotation on a joint during the move. The robot can rotate it either way and get to the final solution in roughly the same time. So by adding an intermediate point it stops this behavior. 

Thanks forgetting back to me so quick
In a perfect world I'd like the robot to go from a position above the part vertical to a position  where the wrist is horizontal without any intermediate moves their positions are loaded from variables I'd like to keep the code as clean as possible

I just learned that robot is using qnear value when using MoveJ functions. Qnear value can be seen in a script file which is created by the robot. When running a program, robot tries to go to target position in a way that all the joint values are as close qnear value as possible. This caused me a problem when I implemented a robot where palletizing action is done with dual gripper. Universal Robots Palletizing wizard uses ReferencePoint to calculate every pallet positions and it is calculated by the factors you give during the wizard. In some specific points the robot started to rotate 360 degrees when driving to calculated target position. At the beginning it looked like an occasional behavior but after studying more there was a pattern where robot flipped the joints. An intermediate point wouldn't work for this since the problem were in target position which robot tries to achieve.

I programmed one work around where I forced Rotation vector values into ReferencePoint before driving to the point and stopped using MoveJ. It worked no problem. Then our awesome UR tech support guy came up with more simpler solution which adds just one line to the program. @UK_dove If you feel this might the problem in your case too, you should definitely take a contact to your distributor or UR tech support if you are a distributor or hit me up.

By the way, during this research I learned that UR does not take active TCP in count when teaching palletizing wizard. This is something to think about.

Removing the Jmove helped fix a similar problem I had somewhere else in the program but I need to change my set up so I can see if that fixes the more complex strategy
Thanks for everybody's rapid reply