Project

General

Profile

Actions

Bug #82

closed

Batch - Order Number Range Check Problem

Added by Chooi-Mey almost 14 years ago. Updated almost 14 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Category:
offline batches
Target version:
Start date:
02/14/2011
Due date:
% Done:

100%

Estimated time:
Spent time:
Resolution:
Fixed

Description

Order Number is parseInt/long and check/compare from the list of number range, to determine belongs to which mall.

In this migration, order number will be alphanumeric, that it will hit error or fail to be checked from this kind of checking, example:

            long iOrder = Long.parseLong(orderNum);
            if (iOrder >= 400000000 && iOrder <= 419999999)//HK Mall
                keepOriginalPurcQU = true;
            else if (iOrder >= 440000000 && iOrder <= 459999999)//Aus Mall & Ind Mall 
                keepOriginalPurcQU = true;

To make it consistent for future alphanumeric order number case, can consider remain this logic checking by using customize comparator for the string value. For reference: http://code.hammerpig.com/sort-strings-numbers-java.html. Or have better resolution, if any.

Search thru all related project to find any impacted program via this:
1) Search file with text "400000000", scan trhu the search result to find files with such logic checking.


Related issues 1 (0 open1 closed)

Related to Bug #83: Online Mall - Order Number Range Check ProblemClosedchin-yeh02/14/2011

Actions
Actions #1

Updated by chin-yeh almost 14 years ago

  • Assignee changed from chin-yeh to Chee-Hoong

please find out those affected files first and list it here.

Actions #2

Updated by Chooi-Mey almost 14 years ago

Resolution for this issue: perform digit validation checking on order number, before proceed next step of parseInt/parseLong. Do not need to perform string compare type of checking.

Reason: Current number range checking only applicable on existing mall which will remain with order number in full digit. For new mall, mall determination will be based on prefix/suffix, instead of number range.

Actions #3

Updated by Chooi-Mey almost 14 years ago

  • Assignee changed from Chee-Hoong to chin-yeh
Actions #4

Updated by chin-yeh almost 14 years ago

  • Status changed from New to In Progress
Actions #5

Updated by chin-yeh almost 14 years ago

  • Status changed from In Progress to Feedback
  • % Done changed from 0 to 100
  • Resolution set to Fixed
list of affected files:
  • my.com.powersys.util.TranxStat
  • src-classes/dayEndProcess
  • src-ecos/UpdateOrderFulfillmentForEcos
Actions #6

Updated by Chooi-Mey almost 14 years ago

Few more files with this issue:
1) src\my\com\powersys\util\TranxProcess.java (line 151)
2) \src-classes\DailyTranx.java (line 2017)
3) src-classes\OfflineTHTransaction.java (line 1036)
4) src-classes\OfflineTransaction.java (line 1566, 2165)
5) \src-classes\UnapplyOfflineReturns.java (line 884)
6) src-classes\UnapplyReturns.java (line 647, 648)
7) src-ecos\EIClassification.java (line 973)
8) \src-ecos\EIOtherAcct.java (756, 839)

Actions #7

Updated by Chooi-Mey almost 14 years ago

  • Status changed from Feedback to Closed

Move the list under Bug #86. This bug is closed.

Actions

Also available in: Atom PDF