Project:
View Revisions: Issue #34329 | [ All Revisions ] [ Back to Issue ] | ||
Summary | 0034329: Support manually decrease of next assigned ad_sequence and replication to store servers | ||
Revision | 2016-11-18 09:00 by mtaal | ||
Description | Context from the related issue: - the ad_sequence table is now replicated bi-directional from central to store and vice versa - when store is not connected to central it is possible that the same ad_sequence has different next assigned numbers in store versus central - this happens when the ad_sequence is shared/used by different stores - this is not a problem as long as document numbers of documents have a store-specific prefix - still 'holes' will exist between document numbers of one store, but afaik this is okay - when a store connects again to central it was possible that the replication would lower the next assigned number in either direction - to prevent this the replication logic ignores updates which would lower the document number. This was implemented in the related issue. - this replication logic and prevent-decrease-next-assigned-number logic is all done in the store server module, so the standard retail-erp is not changed However: - there are functional cases where people want to reset the next assigned number manually on purpose - this would now not be replicated to the stores (as the replication logic ignores these decrease-next-assigned-number updates) To solve this, this issue proposes: - add a flag in ad_sequence: Update assigned number in stores - show the flag in the window/tab, editable - add an event handler which prevents lowering the next assigned number if this flag is not checked - when this flag is set then the decrease of next assigned number is replicated from central to store - the stores when receiving the update will set the flag back to unchecked - this flag/logic will be implemented in the store server module, no change in core/central |
||
Revision | 2016-10-28 09:31 by mtaal | ||
Description | Context from the related issue: - the ad_sequence table is now replicated bi-directional from central to store and vice versa - when store is not connected to central it is possible that the same ad_sequence has different next assigned numbers in store versus central - this happens when the ad_sequence is shared/used by different stores - this is not a problem as long as document numbers of documents have a store-specific prefix - still 'holes' will exist between document numbers of one store, but afaik this is okay - when a store connects again to central it was possible that the replication would lower the next assigned number in either direction - to prevent this the replication logic ignores updates which would lower the document number. This was implemented in the related issue. - this replication logic and prevent-decrease-next-assigned-number logic is all done in the store server module, so the standard retail-erp is not changed However: - there are functional cases where people want to reset the next assigned number manually on purpose - this would now not be replicated to the stores (as the replication logic ignores these decrease-next-assigned-number updates) To solve this, this issue proposes: - add a flag in ad_sequence: Update assigned number in stores - show the flag in the window/tab, editable - add an event handler which prevents lowering the next assigned number if this flag is not checked - when this flag is set then the decrease of next assigned number is replicated from central to store - the stores when receiving the update will set the flag back to unchecked - this flag/logic will be implemented in the store server module, no change in core/central |
Copyright © 2000 - 2009 MantisBT Group |