Movement: let a type based method decide if this movement is moving item

Reuse code of delivery to ensure we can customize which item should be
in item table

product/ERP5/Document/Movement.py

@@ -220,6 +220,9 @@ class Movement(XMLObject, Amount, CompositionMixin, AmountGeneratorMixin):
   security.declareProtected(Permissions.AccessContentsInformation,
                       'isMovingItem')
   def isMovingItem(self, item):
+    type_based_script = self._getTypeBasedMethod('isMovingItem')
+    if type_based_script:
+      return type_based_script(item)
     return False
 
   security.declareProtected(Permissions.AccessContentsInformation, 'getMovedItemUidList')

[Jérome Perrin]

For future reference, I will write what I remember about this.

All this come from a project where we use the same items for both "normal item tracking" with some packing lists when the item really move and also for "traceability", so w aggregate the item on the tasks reports for work done in relation to the item and also on invoice lines and accounting lines to be able to make financial reporting based on items. Because all this are movements, they were all visible in the tracking of items.

So we realize that not all movements make the item move, in our bit complicated case, but also in a simple case where we have order, simulation movement and packing list movements all aggregating the item, in this case, the item only must move only one time.

In e29e5b35 we made a first iteration: "delivery" movements move the item if they are accountable ( not to move the item twice if it's on an order and a packing list) and "accounting" movements never move item. While reading this again, I feel we made a mistake here because a planned simulation movements does not move item from future tracking point of view until it's built in a packing list. I don't remember why the default Movement.isMovementItem was False and not self.isAccountable().

Later we realized that task reports are accountable, but we did not want them do move item from the source of the task report to its destination, so we did 5c7ef54e and e575d9fc . Not doing adding the same configure-ability on Movement level seems a mistake and I fully agree with that change. But if you did it to have Simulation Movement move item, we should probably treat this in SimulationMovement.py

/cc @gabriel @luke