Anonymous | Login
Project:
RSS
  
News | My View | View Issues | Roadmap | Summary

View Issue DetailsJump to Notes ] Issue History ] Print ]
ID
0050840
TypeCategorySeverityReproducibilityDate SubmittedLast Update
defect[Retail Modules] Copy Retail Storemajoralways2022-11-10 14:052022-12-06 09:27
ReporterXABIER_AGUADOView Statuspublic 
Assigned Tomarvintm 
PriorityhighResolutionfixedFixed in Version
StatusclosedFix in branchFixed in SCM revision
ProjectionnoneETAnoneTarget Version
OSAnyDatabaseAnyJava version
OS VersionDatabase versionAnt version
Product VersionSCM revision 
Review Assigned Tomarvintm
Regression level
Regression date
Regression introduced in release
Regression introduced by commit
Triggers an Emergency PackNo
Summary

0050840: Copy Retail Store sets Document Sequences´Next Assigned Number to 1Million even if the original store is 10M

DescriptionCopy Retail Store sets Document Sequences´ Next Assigned Number to 1Million even if the original store is 10M
Steps To ReproduceOn Backoffice check the Document Sequences for a Store
Change , for example, its RFC Order value to 10M
Do a CRS using that store as parent
Check the RFC Order Document Sequence for the new Store
Its 1M instead of 10M
Proposed Solutionshould be 10M
TagsFASH
Attached Filespng file icon wwe.png [^] (53,493 bytes) 2022-11-10 14:05

- Relationships Relation Graph ] Dependency Graph ]

-  Notes
(0143844)
marvintm (manager)
2022-11-21 07:29

I'm rejecting this issue as "no change required" because I don't think we have to change the copy store process. However, maybe some additional discussion is needed, and maybe we need to report another issue in the BackOffice depending on the outcome of this discussion.

I believe the copy store module itself is working correctly in this case:

- When cloning an existing sequence, it would not make sense to consider the "Next assigned number" property, as the new sequence is supposed to start from the beginning, not from the point in which the existing sequence currently is.

- The question then, is what should be the beginning point, for each sequence. For this, it seems the sequence mechanism currently has a property called "Starting no", that is used in sequences that are restarted every year. The copy store is not only copying this property, but it is also using it to initialize newly cloned sequences. In general, I think this makes sense, as creating a new sequence is basically equivalent to reseting the current sequence, and as both sequences are supposed to be used for the same concept (but in different stores), it looks like it makes sense to initialize them like this.

- The tricky thing is how to configure this "starting no" column, as it is currently hidden in the backoffice. By default, it always receives the value 1000000. This is why when copy store copies a sequence, it always starts in 1M.

I think internally we should discuss if the "starting no" column should be visible always, as it would then allow users to configure this value, that I believe makes sense to be used by copy store for this.
(0144252)
XABIER_AGUADO (developer)
2022-11-30 13:43

Hi Marvint,

I have reviewed this with my team and we agree that making "starting no" column visible and configurabe would be the best fix for this issue.
(0144443)
hgbot (developer)
2022-12-06 06:36

Merge Request created: https://gitlab.com/openbravo/product/openbravo/-/merge_requests/781 [^]
(0144452)
hgbot (developer)
2022-12-06 09:26

Directly closing issue as related merge request is already approved.

Repository: https://gitlab.com/openbravo/product/openbravo [^]
Changeset: bb9f203d0d6edba551b10516bdd927535822cf8d
Author: Radhakrishnan Seeman <radhakrishnan@qualiantech.com>
Date: 05-12-2022 16:46:30
URL: https://gitlab.com/openbravo/product/openbravo/-/commit/bb9f203d0d6edba551b10516bdd927535822cf8d [^]

Fixed ISSUE-50840: Starting no should be displayed based on auto numbering

---
M src-db/database/sourcedata/AD_FIELD.xml
---
(0144453)
hgbot (developer)
2022-12-06 09:26

Merge request merged: https://gitlab.com/openbravo/product/openbravo/-/merge_requests/781 [^]
(0144454)
marvintm (manager)
2022-12-06 09:27

We have changed the display logic of this field. It is important to mention that you will still need to mark the "Auto Numbering" flag to be able to configure it.

- Issue History
Date Modified Username Field Change
2022-11-10 14:05 XABIER_AGUADO New Issue
2022-11-10 14:05 XABIER_AGUADO Assigned To => Retail
2022-11-10 14:05 XABIER_AGUADO File Added: wwe.png
2022-11-10 14:05 XABIER_AGUADO Triggers an Emergency Pack => No
2022-11-10 14:05 XABIER_AGUADO Tag Attached: FASH
2022-11-11 06:02 radhakrishnan Assigned To Retail => radhakrishnan
2022-11-11 06:02 radhakrishnan Status new => scheduled
2022-11-21 07:29 marvintm Review Assigned To => marvintm
2022-11-21 07:29 marvintm Note Added: 0143844
2022-11-21 07:29 marvintm Status scheduled => closed
2022-11-21 07:29 marvintm Resolution open => no change required
2022-11-30 13:43 XABIER_AGUADO Note Added: 0144252
2022-11-30 13:43 XABIER_AGUADO Status closed => new
2022-12-05 10:50 XABIER_AGUADO Assigned To radhakrishnan => marvintm
2022-12-06 06:36 hgbot Note Added: 0144443
2022-12-06 09:26 hgbot Resolution no change required => fixed
2022-12-06 09:26 hgbot Status new => closed
2022-12-06 09:26 hgbot Fixed in Version => PR23Q1
2022-12-06 09:26 hgbot Note Added: 0144452
2022-12-06 09:26 hgbot Note Added: 0144453
2022-12-06 09:27 marvintm Note Added: 0144454


Copyright © 2000 - 2009 MantisBT Group
Powered by Mantis Bugtracker