Last Commit
MAJOR CHANGE NOTES : FOR 1st Beat Run

D S - Changes

================================

DDD —— Problem with flags in =>  OUEditView

DDD —— Don’t just show - save the trialDate and delivery Date from default order in orderUpdate

DDD —— Problem with Store Customer Delivery Date Null Value - its printing null .. handle it to blank space

DDD —— Delete Search Text when Search Type is Changed

DDD —— Check take all saves should be save eventually - to handle offline

DDD —— Check that all queries should be cacheThenNetwork

DDD —— MAJOR BUG IN ADD PRODUCT : OuEditView

DDD —— ADDED client Pics to Karigar and check status

DDD —— MAJOR BUG IN CHECK STATUS DELIVERY

DDD —— Take one touch date pop to all windows applicable

remove refreshes where not needed

correct the newOrder flow.

DDD —— remove blue color & ADD from delivery.m’s give blankifnull

currently multiple results are just to serve the help … type until one result in the search to reach perfect product results

NOW ON WILL HAVE ALL THE INDICATORS AND OPTIMIZATIONS

================================

1. Order Creation - Store

a.)  Order number duplicacy - How can it be prevented or what are the options if we allow it?

- LATER - IN THE NEXT VERSION >> WE WOULD FIND A SOLUTION TO THIS

b.)  Q – What if a wrong order no has been given to a order. Can it be rectified at any stage?

- ORDER SHOULD NOT BE TAKEN FOR GRANTED - if you edit order No later .. everything changes … In Case that is required .. we can try to provide that to the OrderUpdate-Tailor

c.)  Autofill/Search while entering details for an existing customer. Provision to click new pics

and remove old ones in this case.

- How do we autofill - Autofilling means .. the data of that customer should be present before hand on the device … or should be downloaded while entering the fields .. that can happen .. but that would also put delays in making of new order as downloading might take time. - Are we going that way rite now ? … Suggestion - Such Enhancements should be dealt with once the app passes the first round of use by the actual users WE DO NOT WANT TO EXCEED THE DATA LOAD LIMIT AT THIS POINT FOR 1ST BEAT RUN

d.)  Provision to remove products if entered wrong before saving the order.

DDD-**** WORK

———————————————————————————————————————

2. Order Completion & Sending – Tailoring

Add product details –
a.) Trial & Delivery date is not coming which were selected in step 1.

DDD********* WORK

b.) In pics - add counter (How many pics present). (This is required throughout the system)

DDD********

c.) One factory date be given to the order which can be changed individually for each product if required.

DDD*********

d.) Provision of delete product like add product. (But ask twice before deleting)

DDD*********

e.) Some sort of identifier that changes made are being saved and that active internet connection is there (Throughout the system)

5********* WORK - NEXT VERSION

Order Sending –
a.) Any visual identifier to make out that the products are sent, (in addition to status change.)

ALREADY THERE ********* WORK

 c.) Deselect products before sending.

 6********* WORK - NOT UNTIL NEXT VERSION

———————————————————————————————————————

3. Order Receive – Factory (Change to Factory Station) & Karigars (Change to Factory Staff)

a.)  Problem while ticking Mark Received. At times the status is not changing even if we refresh it multiple times or go out and come back again.

DDD*********

b.)  Mark received should be a two step process to prevent human error. (Receiving and sending anywhere in the system should be a two step process as errors can lead to complicated situations.)

DDD *********

———————————————————————————————————————

4. Factory Link / Amend & Update – Tailoring

a.) Products are missing until they have not been mark received at factory.

THAT IS INTENTIONAL >. IF YOU WANT TO SEE ALL THE PROUCTS >> SEE AT ORDER UPDATE

8 ********* WORK

———————————————————————————————————————

6. Reporting – Tailoring (rename as product receive)

Show products received – All products DONE ENTIRE
- Products to be received

???

- Already Received - TAILOR CAN ALWAYS GO BACK TO OU AND SEE ALL THE PRODUCTS

???

* Reporting needs to we reworked and will be discussed later

???

———————————————————————————————————————

8. Customer Dealing – Store

- Address to be shown here as well

 DDD********* WORK

- Trial date is coming wrong

 DDD********* WORK

- Trial date is not needed for finished product (Leave blank)

9 ********* WORK _ DOES NOT JUSTIFY (PRODUCTS DONT SHOW HERE ONCE MARKED FINISHED)

If Finish!New Del date , Remarks --> Change Purpose – Lifecycle repeated. Tailoring is responsible to send product to factory with a new challah

DDD--10??? Done

If 2nd Trial!New Trial Date , Delivery Date, Remarks --> Change Purpose – Lifecycle repeated. Tailoring is again responsible for sending products to factory with a new challah.

DDD--10??? Done

*Products with second lifecycle should show on top so a person knows about it and can work on them. So that person knows he has to again send these products.

DDD--10??? Done

———————————————————————————————————————

10. Check Status – Store

a.)  Problems here with Trial & Delivery date. Coming wrong

11.MAAJJOOR BUGG ********* WORK

b.)  Search is showing wrong results at times.

 11.********* WORK

———————————————————————————————————————

 Input Method Changes

a.)  Let the calendar disappear once date is selected.

 DDD ********* WORK >>> "TAKE TO OTHER VIEWS” — Changed in OUEditView.m

b.)  Keyboard disappears after searching once.

 DDD********* WORK >>> "TAKE TO OTHER VIEWS” — Changed in TailoringOU.m

c.)  In order no search input method be numeric and vice versa <??WHAT VICE VERSA??>. This was there initially but has

changed now.

 DDD ********* WORK >>> "TAKE TO OTHER VIEWS” — Changed in TailoringOU.m