2017-05-09 Meeting notes

OLMIS-2441 - Getting issue details... STATUS

MJ: I've invited Sam Im (Deactivated) to join and share her thoughts.

SJ: We agree that this ticket is a low priority story and can be done after release 3.1

OLMIS-634 - Getting issue details... STATUS OLMIS-635 - Getting issue details... STATUS

MJ: Nick Reid (Deactivated) mentioned in another story about inserting the quantities prior to add the product to the table. I think as a group we need to discuss this since it would impact quite a few pages. I do see his point that it is the only element added once in the table. Given the timelines I'm thinking to not change things now since it would change most screens but it would be good to hear what others think and the LOE. Also, I don't see what the error message would be for these two stories. Could you please outline the pattern/approach?

Mary Jo Kochendorfer (Deactivated) , there are two questions for you

• Do we need multiple lines textbox or maybe we just use the one-line textbox;
• Whether the source comment title makes sense to users?
  
  SJ:We will only keep the product, lot code and add button on the header and allow user to interact other fields in the table.
  Moreover, we only needs to list out those active products (with stock cards) in the product dropdown list for the issue process

OLMIS-2366 - Getting issue details... STATUS

OLMIS-2360 - Getting issue details... STATUS

• Lot rows were grouped together and the same color

MJ: Nick Reid (Deactivated) was out when we discussed this as a group. I think we should focus on the functionality and it is okay to leave the zebra striped rows for now. Also, Brandon Bowersox-Johnson can explain to Nick Reid (Deactivated) about the "no lot defined" row. Now that Brandon and Nick are in the same office they can catch up on the decision we made while Nick was out.

SJ: We agreed to put it on hold and fine to release 3.1 without the group colour. Moreover, there is a tick OLMIS-2478 to track it.

OLMIS-2362 - Getting issue details... STATUS

• Explanation why we have the 'No lot define' value

MJ: see my comments above. I think Nick Reid (Deactivated) and Brandon Bowersox-Johnson can talk prior to the meeting to sync on this.

SJ: For now, it is still in discussion VR internally. The main concern is about the usability. Nothing needs to be change until we have an agreement.

OLMIS-2211 - Getting issue details... STATUS

(1) I don't understand the "I, srmanager2, confirm this" message at all. From earlier discussions, this was supposed to be a confirmation screen, where an uneditable list would be shown to the user so they could review changes.

In other confirmation views, we also collect the user's signature, which I think we should do here too so we are consistent. Once these adjustments are saved, it looks odd that the Stock Card doesn't have a signature for the adjustments... 

Actually, there are two different user cases for the signature field. One case claims they do not need the signature field because the username can identify who makes the stock event however another case argues one account would be shared by several people so the system should allow users to record signature and identify who makes the stock event. In order to support both cases, we decide to keep the signature field in case the implementer needs this field but we also display the user name on the confirmation modal to avoid unnecessary user input efforts.

But I agree with you guys, we should keep it consistence. Meaning, Physical inventory, Adjustment, Receive/Issue should share the same behavior regarding the signature field.

MJ : I know that each of these workflows look the same but Physical Inventory is different than adjustments. In addition, eventually Receive and Issue will include other facilities and printing out issue vouchers. I'd also like to point out that PI has a draft process because it will take some time. I believe we need to keep the Date, Signature on the confirmation modal still because this process is different and multiple people may be involved AND we want them to know they are accountable. However, Adjustments and Receive/Issue will not have the same modal because the lineitems may be different dates and aren't happening on a routine basis with potentially multiple people. Looking forward I know we need to build out a printing function for Physical Inventory and having the signature field would be needed there. However, I don't see that need for Adjustments. All this is to say, I think it is okay if we have one confirmation process for PI and different ones for the rest.

SJ: We are fine with Mary Jo comment and leave it as it is for now.

(2) Let's reorder the table grid columns — since the date is the order that adjustments are sorted by, lets put that column first — then lets make sure "Stock on Hand" and "Adjusted Quantity" are next to eachother — finally, make "Reason Comments" its own column

I hope this quick sketch is helpful...

We can do this if we all agree to do it this way and do it now.

MJ: I'm not sure I agree with the reorder proposed by Nick. We know that people will most likely order things by product and potentially do multiple entries based on the paper bincard (which would span multiple days. However, it is true that the paper bincards have dates in the first column. Honestly I think we will need to test this with users to really determine what works best. I like having the reason for adjustment after SOH and not the quantity. I do see a value of pulling the comments into a separate column since I do think it looks strange with the two inputs within one cell. It would be good to see how this looks if there are some lineitems without comments and some with. Ideally we will have table sorts eventually which would allow the user to sort how they like. Other than the comments, I'd leave the columns as they are until we have some real user input to warrant a shift since we'd have real feedback.

SJ: We agree to have separate columns to avoid multiple inputs within one cell not to change the order of the columns now.

(3) Please add a quantity field to the top add buttons (so the user can enter the quantity before they press add, rather then pressing add and then finding the item in the list to change it)

It is doable but our concern is adding one more field in the limited header space would squeeze fields especially the 'Add' button.

MJ: I responded to this comment in another ticket as well. For now, let's leave it as it is (without the quantity on the top) and we can update/modify later. Please let me know if others feel strongly opposed to this approach.

SJ: Put it on hold now and we will continue to discuss it.

(4) Is there a reason the add form doesn't reset its self once the user presses add?

There are two reasons: Navigation the added item & impact the front-end SOH calculation order.

SJ: We are fine with the current design.

OLMIS-2373 - Getting issue details... STATUS