############################################################################## # # Copyright (c) 2008,2009 Nexedi SA and Contributors. All Rights Reserved. # # WARNING: This program as such is intended to be used by professional # programmers who take the whole responsibility of assessing all potential # consequences resulting from its eventual inadequacies and bugs # End users who are looking for a ready-to-use solution with commercial # guarantees and support are strongly adviced to contract a Free Software # Service Company # # This program is Free Software; you can redistribute it and/or # modify it under the terms of the GNU General Public License # as published by the Free Software Foundation; either version 2 # of the License, or (at your option) any later version. # # This program is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of # MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the # GNU General Public License for more details. # # You should have received a copy of the GNU General Public License # along with this program; if not, write to the Free Software # Foundation, Inc., 51 Franklin Street - Fifth Floor, Boston, MA 02110-1301, USA. # ############################################################################## r""" Quantity Sign Movement Group is used to separate movements based on the signs of the quantities. This is probably used only in erp5_immobilisation. But this implementation has a serious problem that the quantity sign is not set in a movement, if the movement is created manually, because only this movement group set that property with a builder. So a builder always creates new movements, even if simulation movements match existing movements. This is not easy to fix, because nobody available knows how this is supposed to work precisely. In addition, it is questionable even that this movement group makes sense. From accounting point of view, if the same account is used, there is no problem in merging debits and credits. So somebody must consult the spec of immobilisation accounting, and the implementation of erp5_immobilisation seriously, to understand why and whether this is really required. """ from Products.ERP5.Document.MovementGroup import MovementGroup class QuantitySignMovementGroup(MovementGroup): """ The purpose of MovementGroup is to define how movements are grouped, and how values are updated from simulation movements. """ meta_type = 'ERP5 Movement Group' portal_type = 'Quantity Sign Movement Group' def _getPropertyDict(self, movement, **kw): property_dict = {} quantity = movement.getQuantity() property_dict['quantity_sign'] = cmp(quantity, 0) return property_dict def _separate(self, movement_list): tmp_list = [[], [], []] # -1:minus, 0:zero, 1:plus for movement in movement_list: tmp_list[cmp(movement.getQuantity(), 0)].append(movement) if len(tmp_list[1]): if len(tmp_list[-1]): return[ [tmp_list[1]+tmp_list[0], {'quantity_sign':1}], [tmp_list[-1], {'quantity_sign':-1}], ] else: return[ [tmp_list[1]+tmp_list[0], {'quantity_sign':1}], ] elif len(tmp_list[-1]): return[ [tmp_list[-1]+tmp_list[0], {'quantity_sign':-1}], ] else: return [ [tmp_list[0], {'quantity_sign':0}], ] def test(self, object, property_dict, **kw): if object.getQuantitySign() == property_dict['quantity_sign']: return True, property_dict else: return False, property_dict