This persists between logout/login. Could be related to issue 296, though sequence of steps to create may be totally different given the lapse in time (created it this time while attempting to test/close 266). (Screenshot from Joan's session.)

Please implement this design for when there are no results for a search

• The “Sorry, your search…” text should be 18 px Scala Sans Offc #000

Saved Item Part# Hover showing incorrect title & info and no price history if 1 quote

sp, 7/10, here is the revised design spec for the item details. This supersedes bug 263 so I am closing it:

It reflects the following:

• Addition of item owner (top left)
• Addition of product category - please see Judy RE what to pull this from.
• Reordering of quantity/count/zip.
• Correct quantity (amount being ordered, by pricing UOM)
• Correct count (packaging UOM)

1) The part# hover in saved items is showing the incorrect title and data on the top line (see MOD1268).  It says 'Quantity: 175/Thou' but it should really say 'Count 175/RL'.  The title of Quantity implies that it's the quantity that you are ordering (in thousands if a BAG).  The 175 in the case of MOD1268 is the count per roll, not the quantity ordered.  I'm not sure what should really be here, but either way title/data is mixed info.  Check w/Steve to see what this should be.

Sp, 7/9 - please see issue 263.   7/9-Judy-ok to proceed with change to hover per Steve's spec on left

2) Saved Items - I only see the $ for price history for MOD items that have more than a single quote.  So there is no way to see the price of the single quote (doesn't show in the hover).  Shouldn't there always be a $ for price history, regardless of how many quotes are attached to the MOD item???

Sp, 7/9 - this is what the specs say:

Clicking on History icon. The history icon appears only when a MOD item has been priced more than once(live or expired, (Design 4e)). Clicking on it will show you the shadowbox listing; clicking any one of the links will populate the widget and shows the results repriced if need be.

In hindsight - with the design specs brought to life on staging - there are a few things we might want to tweak, including this. By coincidence, I just emailed Steve about whether we should also include the item owner in the hover - the usefulness of this becomes apparent when logged in as a Butler user and filtering on my location or organization; many contacts saving many items, an owner could come in handy. (Without that it was challenging to test issue 285. )

Judy 7/9 - Show price history even if single quote on MOD Item (remove logic that is keeping a single quote from displaying $ price history icon.

3) Add category description to hover so user knows what this is (bag, sheeting, tubing, furniture bag, perf sheets, etc). Awaiting answer from Owen as to whether we show the category description or something else.  Category desc may not be enough (ie, in Poly Bags menu, description just says Layflat or Gusseted – don't know that it's a bag).  Possibly use generic name??

Judy 7/10 - The Category Desc will come from field 1 of the CATALOG.CD.USR record.  These will be reformatted so that they look correct (ie, Bags - Layflat will be changed to Layflat Bags). - Judy will take care of this.  The back end will be changed to pass this info along to the UI as CATEGORY.DESC= from RPC$WEBPRODUCTITEM_GETBYPARTNBR (stock) and RPC$MODPRODUCTITEM_GETBYID (MOD). This will require a change to PRODUCTITEM.READ (is already included in both RPC's) to extract the CATEGORY.DESC from CATALOG.CD.USR<1> - Joe will take care of back end work.

Sal #1-3

Joe #3

Godzilla names/tags column

sp, 7/9 - 11:30 - we are taking a closer look at the spec; some tweaks/clarifications may be necessary.

Mailers & Accessories: Missing UNIT column and Pricing Uom on price.  Also see NOT READ for item 4830 instead of Materials/Additives.

Sal 7/8/14 12:42 -Created two test plans: GFDVMN and GFDVQS that represent the manual and quicksearch scenarios for Tubing Dispenser. The GetFieldDefaultValues RPC is returning MATERIAL="NOT READ" in the case of GFDVQS, should be returning blank instead.I believe this needs to be fixed in the DB side.

sp, 7/8 - please also see issue 288 and 287

1. Select Mailers/Accessories then Tubing Dispensers.  Click FIND.  The results are missing data under the UNIT column (s/b Cases) and the Pricing Uom ($17.59/ s/b $17.59/CS)  (See screen snapshot below)
2. If I choose the first item 4830 and put it through the quick search at the top of the widget page,  I see NOT READ instead of detail headings/labels (see snapshot #2)  Fixed 7/8 (Judy) - FCT.MATERIAL.DEFAULT.VALUE was setting NOT READ instead of null.

I saw this when looking at closed bug 236. 

Sal/Judy

Tubing dispensers, sorting

7/8 (Judy) - I just happen to be working in this area on item descriptions.  We've decided for tubing dispensers to pull desc from the item master (which is what you see here).  Since we dont' allow entry of a Width dimension for this gruop (it only  has 4 stock results), we aren't worried about sorting.  Also, with just a Width dimension, the desc looked funny so we decided to go with the item master desc.  I am closing this issue.  If you disagree, please let me know.

sp, 7/8/14 - I agree with what you have for the description. Is what you are saying that the widths I see here aren't sortable b/c they are not truly a dimension, but really part of a text string? I guess seeing a dead width button above a bunch of widths kind of throws me off or makes me say "huh?" - on the other hand, when there are fewer than N results (I really don't know what N should be - 4? 6? 8?), sorting doesn't seem to make much sense either. Not sure sorting on price here adds much value. It's just kind of quirky the way it is.

Should be able to sort on width, no?

On staging, freight for stock is "Free at $500" regardless of quantity; original specs called for this to be dynamic:

Freight: "Free at $500” if total price at given qty < $500; “Free” if total price at given qty > $500. (Yes, even though these freight terms are based on the cumulative total of stock items in the cart.)

Unable to delete saved item.

sp, 7/8, 9:32 am - update - seems to be hit or miss. I was able to delete two items (first one I didn't get which MOD#; second one was MOD1399). However, 3 other deletion attempts failed.

Sal 7/8/14 18:05 - This bug was resolved while I was looking at bug 285. Please test.

Sal 7/9/14 10:21 - 285 is fixed, this could probably be closed.

sp, 7/9/14 - closing

Encountered this while attempting to test and close issue 286 - need to delete a saved item in order to test whether Godzilla is excluding them. When I click the 'x' - I get a fleeting red error message saying that I cannot delete the item.

Checkout button does not look like designed version. Looks smaller and the wrong color.

"Checkout" text should be 18px Scala Sans Bold #bc5f08.

Positioning of large pop-ups

sp, 7/9/14 - retested, not happening, closing

Please position large pop-ups so that entire pop-up is visible (at least within typical desktop viewports). Current positioning cuts off bottom portion

Staging position (Sony Vaio laptop browser window maximized).

Desired position

Search w/stock item by # and by returning from widget not generating results

sp, 7/9 - based on a quick retest, this is still happening. Tested with other item numbers - happens with some (409, 410, 411, etc.), not others (eg 372, 373, 6500) - could be a certain subset of a layflat product group?

Search for item 408, which also happens to be a saved item, sets widget parameters but returns no result; same thing happens when returning 408 from saved items list or when manually entering 4 x 24 x 2 clear layflat.

What Joan sees:

What Sally sees - same as Joan + Godzilla.

$ values are 0 in cart tab and cart totals, with items in cart

sp, 7/9/14 - retested, doesn't see to be happening any more.

This is happening to Sally and Joan with stock and MOD. And I can save, share, etc. and it doesn't change this condition.

Just after adding item to cart

and within the cart itself

It carries through to checkout

Staging Server Version

Designed Version

Shipping Packaging > View Alternatives > Select a later date for these items

Via dropdown should have disabled text "Best Way" displayed in field.

Staging Server version

Staging Server version

The way the design should look.

Logged in as Sally (2916, 17279) ... If I enter a term that I know is part of one or more of my saved carts' names, and click Find, I get a result saying that I don't have ANY saved carts.

This doesn't happen if my search term is an EXACT match to the cart name. The search should be able to handle terms that match partially. And if for some reason it cannot - the resulting message should be different, but I hope we don't have to go there.

Issues with returning saved items to widget.

Joe 7/9/14: Closing since it's related to other open issues and for new saved items it seems to be fine but problem exists for older Save items. If this issue reappears after the other bugs are fixed a new bug should be created.

1-Returned MOD 1405 to widget. Looked at Godzilla result. Noticed duplicate data (see issue 280 and 271). Noticed that one of the sets of duplicate data were exact matches (MOD1405), but in "Exact Match?" column, answer is "No" (but different differences are shown, even though they are both 1405).

2-Then noticed something odd about the materials for the item shown in the results - why is it showing Metallocene 0%; so did some further digging - looked at item details in saved items...

Then looked at it in widget again; expanded the materials menu... shouldn't materials & additives be standard?

May also be related to issues in 226 ?????

Price breaks, sharing item

Price breaks, sharing cart

Sharing item

When share item popup first opens, default is sharing internally and showing price breaks (this IS happening for stock and MOD - good).. As soon as I choose to share w/customer, price breaks should disappear, and appear only after I select "show price breaks" in the markup drawer. This is NOT happening; price breaks are showing after I choose to share with customer and close drawer, even if I don't click "show price breaks."

Sharing cart

When share cart popup first opens, default is sharing internally and showing price breaks - this is NOT happening for MOD item in cart; price breaks not showing in default internal sharing  view. Price breaks ARE showing for stock item in cart initially for sharing internally (good), but also showing when I switch to sharing externally (not good).

Price breaks are misaligned by one line - first break lines up w/subhead; last quantity missing price break.

Getting validation error when I should not?

6/27 (Judy) - we were working on default logic at the time you were testing this, so therefore you didn't get the appropriate defaults for boxes that were disabled.  This should now be working.

sp, 6/27 -  happening w/suffocation plate (SP0001), not others. Try with 10x15x1mil layflat.

I selected a stock plate, and fields on right side (other than ink color) were grayed back, yet get validation error saying I need to fill out mandatory fields - when I click "ok" - fields are still not editable.

"Close" link in expanded description not working

Sal 7/9/14 6:33 - Fixed, please test.

sp, 7/10 - reopen - the link for opening the description is not working, so I cannot test.

Site freezes when I click Godzilla link

6/24/14 -  - I should have logged the time and more detail. If you look at my other issues/updates today, I subsequently was able to click link w/out freezing. So, here's my second chance: It just happened again at about 4:54 pm w/MOD1388 - Sally Draper.

Sal 7/9/14 18:35 - Fixed, please test.

sp, 7/10 - closing

Sharing carts

sp, 6/27 - just realized this is very similar to issue 277.

Click button to share unnamed cart - prompts me to name cart first (good); I name it “Sally's brand new cart” and click the ok or save button, see cart empty in background, while share pop-up opens pretty fast on top of that background. Subject line is customer number (2916) – not the name that I just gave to the cart. And the pop-up is devoid of any product info. Sending/sharing (empty) cart is instantaneous.

Go to Saved Carts to see what's in there – see “2916”  in list (0 items) AND “Sally’s Brand New Cart” (1 item) in the list filtered to “Me”; sharing envelope icon is next to 2916. Able to activate Sally’s Brand New Cart; click share cart button – now I get the proper share interface. Click Send, get a fleeting partial red error message. Nothing happens – popup remains open and do I not get email (have been addressing these to msyelf).

I then went to see what would happen if I started over w/empty cart, added MOD to it, and then just save it v. attempt to share before saving. Saving/naming worked just fine. When I go to saved carts list, I see the cart just saved, plus “Sally’s brand new cart” – and now the empty cart 2916 is gone from the list.

Remove new message for distributors until we launch.

HIde the top banner FOR NOW, but we will ALWAYS supress it for CE.

Cart - Expanded View. Please fix the following:

1. Extend shadow to end of each blue box.
2. Center the labels and content. Seems to be falling very close to gray divider lines.
3. the content seem to be extending beyond the tab border.

This test customer (Butler) has P1 pricing, so price breaks link should be suppressed (as it is in search results)

Active cart tab not displaying values when cart has item(s) in it

sp, 7/10 - pls see issue 352.

Widget not resetting when category changed.

Sal 6/19/14 10:36 - Fixed both issues, will be up in the server by 11:30 am. This was a showstopper for Sue's testing so I jumped in to fixed it.

Please test after next deployment.

sp, 6/24/14 - This is not fully  resolved. A full reset seems to work, but not change of category. A change of category seems to work at first - dimensions, etc. reset to defaults. However, when you click Find, you can only return the original MOD that was returned.

Sal 7/10/14 - Fixed, please test.

When I pull a MOD into the widget and then change the level 2 category, dimensions etc. are not resetting to defaults.

It does seem to reset if I start from scratch, but note, as soon as I pick a category, dimension fields pre-fill again with the last retrieved saved MOD's dimensions.

Note - even if I  reset, and pick a category down in the list – and the dimensions manage to reset, if I click find the only result I am able to get is the saved MOD -

Reclosable/zip top: 15x15x3mil Full Gauge

Save the MOD Result.  Only 1 quote is created

Original results, pricing and freight

After toggling freight on second result, price on 2d result remains same; price on top result changes.

The behavior is very inconsistent; it is hard to determine a pattern. When I first noticed it, I didn't have screen captures, so then I attempted to retrace my steps - I couldn't recreate it after a few tries, until this try when  was ready and got the screen captures above while noting my steps. The sequence was toggle freight on first result, toggle it back; toggle on 2d result - issue of price change on wrong result occurs. But when I attempt tor repeat that and variations of it with fresh searches, it doesn't happen. This definitely happened twice though! (Actually, if you consider I first saw it on CE site, it happened 3X.)

Update - hah - it just happened again; this time sequence was run search. Go directly to freight in second result and toggle to not included. Price on first result changed. Note, if I run another search right after that (with a slight variation on L/D/W - that sequence does not repeat the error on first try). Like I said, it is inconsistent.

Validation error message - wrong message or, wrong action taken on answering "yes"?

6/26/14 - Currently we are returning multiple errors from the DB on validation.  Base the dialog box format (buttons) on the first error condition.

( The wording and contradictory choices are confusing; but I am disregarding since we are about to deliver some global recommendations about these errors.)

Answering "Yes" to this message did not do what I expected - original gauge was 2 mil;  I would have thought answering yes would keep my mil at 2 and change gauge to full - instead it wiped out gauge (and changed gauge to full).

Configurator on live production site will not let me select 2 mil at all, and won't let me select full gauge till I fill in a valid gauge value; forces gauge to be between 4-6 mil. So, I am thinking the message should stop with the first bullet, and an "OK" button, and the focus put on an empty gauge field. The second bullet RE mil spec < 4.4 being full gauge is not true (or not true for this combo).

Note - I am not getting this validation error on the CE site at all - am able to run search (and get no-result result); I've told Janice.

e

Tubing dispenser data

7/8/14 (Judy) - The results description has been fixed.  Now says 12" Tubing Dispenser in both the results area and the header of the Availability Popup.  Leaving this open for Sal to fix the 1/ and $25.42/ problem in the header.

Sal 7/8/14 17:37 - The Unit of Measure is all set in the results item in the Unit column and in the Unit Price.

I discussed the issue about the Availability header with Judy, we feel that for Tubing Dispenser we should not be showing packout info in the header, we feel it should read:
Item 4830, 12" Tubing Dispenser, $25.42/Each. We need to discuss this with Steve and Sue.

See images below

Godzilla is showing deleted saved items

Joe 7/8/14: Updated RPC$MODITEM_CLOSEMATCH routine

Saved Items not handling 'deletion' properly and not seeing the list that I select.

Sal 6/23/14 15:33 - Fixed, please test after next deployment.

Judy 7/8:

#2 still isn't working.  When I look at 'me', I am seeing MOD1405 which belongs to Sally Draper, MOD1525 which belongs to Joe, etc.  I am not able to delete (doesn't show me an 'x') because it doesn't belong to me, so it knows that it doesn't belong to me.  So these shouldn't be showing in the 'me' list.

#1 is fixed.

Sal 7/9/14 8:55 - Joe is revising the RPC to see why #2 is happening. Testplan: SALSIGBF1

 Sal 7/9/14 8:55 - Part 2 Fixed, please test.

Judy 7/9 10:50am - Part1 & Part2 are tested.  Closing.

1. If I 'x' to delete a saved item out of my list, I see message that the item was deleted (and deletion date is written correctly to the record), but it never drops off my saved items list (even if I get off of saved items tab then back in).  It looks like the CONTACTITEM_GETBYFILTER isn't selecting deleted saved items ... possibly need to call the GETBYFILTER again after deletion to refresh?
2. When I choose 'Me', I am seeing everyone's saved items.  See what is being passed for params to the backend GBF.  Have Joe check to make sure that the GBF is handling the selection properly.  I believe John has changed to always pass CONTACT.NBR (this is person who is logged in), then will only pass OWNER.ID (if an individual contact is selected, including 'Me') OR CUST.NBR OR SLSORG.NBR.

Price showing as N/A/Th for Marketplace (ziptop) MOD Results

6/16 1:15pm (Judy) - still seeing N/A

6/18 (Judy) - now seeing a price of 105.39 for ZT 15x15x3 FG. Can't verify the price is correct because old dev site not available.  I am closing this bug.

6/18 (Judy) - price is incorrect for ZT 15x15x3 Full Gauge when checked against old site:

• New site shows unit price of 105.39 (qty 12.22) vs 139.65 (qty 12.22m) on old site.  the new site has 12.22M x 105.39 = 1072.57 (which is incorrect).  With this extension the price s/b 87.77.
• When item is saved and quote is created, the price went down to 87.77 (see quote 83712).
• New site quote only has Material of 1072.566 in the pricing detail vs old site which has:
  • Non Matl= 207.286
  • Material = 1220.955
  • Shipping = 88.30
  • Zipper    = 190.021
  • Total      = 1706.562 / 12.22 = 139.65
• NOTE: the old site is coming up with count/case of 500 vs new site which is 1000 (I am going to fix this).  Not sure if this has anything to do with some of pricing issue???
   

I have tried Zip Tops and Zip Tops w/Hang Holes.  MOD Results are generated but no unit price.  A test plan (see JUDY.MPGBF) does show a Total Amt so it may be something to do with the UI side.  I am also seeing a couple of unassigned variables in WEB.MODITEM.GETPRICE (lines 101 and 103).  It looks like you are returning info that has nothing to do with marketplace (in this case sheeting type).  Right now, the only marketplace items are ZIPTOP BAGS.

In a short while the debugging tool that is writing a testplan everytime you go through the widget (with key of MODITEMSEARCH_yourcontactnumber) may help you to determine if data from the UI is missing.

Re-open

Adding MODs to cart is also putting them into saved items list.

6/26/14 - wait until bug 271 and 238 are fixed and revisit.

1. I ran a search to produced a fresh MOD; I added the exact match and the YMAC cradlepack version to an empty cart. In addition to the items being added to the cart, they were added to my saved items list behind the scenes. This should not happen.
2. Let's say that the first time you did this, you didn't know this happened, and from the cart you decided to save each MOD and gave it a product use tag - using the cart version of the saved items pop-up which is still screwed up (see issue 238). You then go to saved items, and pull it into the widget to look at the Godzilla results.You see some of the same things happening as happened in issue 271 -
   1. Duplicate data
      
      
      
      
   2.  clicking item location link brings you to saved items, but nothing shows in list

...so but maybe point #1 has something to do with these issues ?

In order to recreate an issue that one of the testers of the CE site reported to me (Jay), I added a stock item to a cart and attempted to share it, and encountered issues that were different from Jay's -

Steps:

Find stock item in widget and add 100 cases to cart (success).

Go to cart, attempt to share - get prompted to save/name cart first.

Click save cart.

No sharing ensues. Cart empties; 2916 now appears in cart name field.

In spite of this, cart "boof boof boof" is now in the Saved Carts list. I am able to reactivate it; clicking the share button now opens the Share pop-up.

Update

A little later on, I put a fresh MOD into the cart. I went to the cart and saved it straight away. Then I clicked the share button - I was prompted first to save the cart; should  not have gotten that prompt since cart already saved.

I decided to humor this message anyway, so named the cart Buffy-II - same sequence of events, cart cleared out, cart name replaced w/customer number, no share pop-up, cart ends up in saved carts list behind scenes, able to reactivate, share button now launches share popup.

Misc issues adding MOD to cart, zip conflict popup, etc.

Sal 6/12/14 7:10 - Wayne was modifying the ymac routine, we got successful results yesterday, so we should no longer see a ymac identical to the exact match.
** Cart issues still need to be resolved though.**

Sal 6/17/14 12:35 - Fixed part of bug that states that Mod in YMAC area is identical to Mod exact match. New behavior will be up in the site after next deployment.

While testing issue 267, stumbled upon the following issues:

Round 1

I searched for a MOD w/zip 01760 - not realizing zip different from active cart. Got zip code conflict prompt. Chose to delete current cart. No success message. No change to original active cart tab value (~$44 for a stock item?). So it was as though the cart was not deleted after all.

Clicked add on YMAC result; got success msg; cart tab value changed to value of MOD result.

Went back to trying to add the exact match to cart - got success msg; noticed cart tab $ value chgd but count did not - it was then that I realized that the exact and YMAC were identical (one MOD number).

Checked cart, and indeed the quantity = min quantity doubled.

Then I thought I would try to start over to see if these issues were repeatable; I clicked delete cart button - and with popup open, I changed my mind, decided no, I should save the cart instead, so I clicked cancel and typed a name into the cart name field; noticed the zip code field was now blank - do not know if it happened after cancelling out of delete popup or after typing the name in the field.

I decided to see what would happen if I clicked save w/zip field blank; got success message. New saved cart saved to list. Am able to activate the cart with blank zip code field

Round 2

I cleared the active cart. I went to the widget and searched for a fresh MOD with a fresh zip code. I added it to the cart; the right things happened. Then I changed the zip in the widget and re-ran the search. I selected the cradlepacked YMAC MOD to add to cart. I got the zip code conflict message.I chose 'start a new cart and delete current cart'

I did not get a success message. Cart tab stayed same, but appears empty.

Log out/login clears cart tab back to $0.

For "we can make that/here are stock alternatives" result set...

Please make the results heading on staging fully conform to spec - note, I am not clear on whether certain aspects of spec should be different if "broad" results are below N (sorting, pagination, etc.) - see two different screenshots below for fewer/more results; I might defer to John on that - please let me know if I should get Steve involved.  I am also not sure if the 'fewer results scenario' is artificial at this stage - could be getting too few results due to pending work by Marketing on YMAC rules.

Regardless, in BOTH situations, the heading should be "You might also consider the following stock alternatives:" in black scala font - any doubt as to size, etc. please consult Steve.

Spec

Staging with fewer matches

Staging, with more matches

Susan

Getting error for account number less than 10 digits; most FedEx/UPS accts less than 10 digits (8-9?)

Get spinner 4-ever. Two MODs in cart, logged in as Sally.

NOTE: Logged in as Joan or Sally w/1 stock in cart, was able to proceed from 1 to 2. Logged in as Sally w/1 MOD in cart, can also proceed from 1 to 2.

Various Saved Item/Godzilla issues

sp, 6/24/14 - In addition to issues originally noted in cell to right, just noticed the following additional deviation from specifications - "Results" (scala) missing. Here is spec.

1. Pulling Sally's MOD 1377 back thru widget (to test 229) - Count should be Count/Roll; Price should just be Price, not Price/Unit. Note - this is not happening if I just run a regular search.

2. Godzilla

1. 1. I think I am getting duplicate data. Clicking both "Saved Items" brings me to Saved Items list pre-filtered to 1377. More importantly, there is no product showing in the results table itself (3d screenshot).
   2. Missing data in Name/Tags column.
   3. Since all 3 rows rows are really pointing to 1377 - none of these fields (except perhaps zip, though that's a whole other issue) should be highlighted as differences
   4. "Count/Roll:" should be bold/gray and not highlighted (1000 should be highlighted, IF it was a difference, but I don't think it is).
   5. Quantity "Thou." should not be highlighted, just the value 1.11 (if it were a difference, but I don't think it is).

Cannot add MODs to cart

sp, update 6/10/14

Ok, so now it is happening on http://10.15.3.2/ (the  CE training site). To the best of my ability to recollect - here are the steps to reproduce:

• I logged in from Avante as Sally Draper (2916/64946).
• I searched for 8.5 x 9.5 3 mil layflat. I got a result, and I clicked add to cart.
• I got zip code conflict pop-up - Good.
• I x'd out of it - or clicked OK - not sure. The reason I did this is that I was trying to troubleshoot what one of Tina’s testers experienced yesterday – based on her notes, I couldn’t tell if she was trying to add to cart or save or both. So with “Add” successful (to that point), I moved on to trying to Save.
• I clicked "save" - I got the save item pop-up - Good. I didn't make any selections, I clicked OK.
• I re-attempted the Add button.  Brief spin, then nothing.
• I clicked Add for the YMAC. Same thing.

sp, 6/16 - I tested this Friday and today. This is resolved - but see issue 280 - don't know if it's related or not. Closing.

Wait, I take that back. When I return a MOD to widget, I am able to add it to the cart, but I get a spinner - I told Sal about this via email on Fri, and forgot about that.

(Logged in as Sally Draper) Clicking add does nothing - get spinner briefly. Sal saw error in Firebug.

Another episode of ...

Sally is tries to steal Joan's Ontario business.

6/26/14 - Sal and Wayne, please work on this together.  Sal please create a test plan with a Canadian zip.

sp, 7/10 -closing

Joan ran a run of the mill search and got this result. Joan being Joan she tried to add it to the cart anyway. When she clicked Add nothing happened. (Ran firebug and didn't see any thing that looked like an error or failure - not that I really know how to read that stuff.) She also tried adding the YMAC result. Same deal.

Sally on the other hand...

Ran the same search with a different zip code. Got the same result.

HOWEVER... When Sally tried adding item with N/A price to the cart, she got a success message, she was prompted to save or delete her current cart; she opted for deletion. She got a success message - Sally noticed that the cart tab had a $ value in it (it turns out it was the dollar value of the cart BEFORE attempted to add anything); when she went to the cart to see what was in it, this is what she saw:

Sally thought this was really messed up so she tried logging out and logging back in. Before she did that she ran this search on Laddawn's live production site and it worked. She cleared away the existing cart. She re-ran the search on staging. She got the same result; this time she tried adding the N/A result - nothing happened. She tried adding the YMAC result - that worked. Why couldn't Joan add the YMAC?

Update, sp, 6/5, 2:17 pm: Joan and Sally exist in parallel universes

Joan cannot access the Saved Items tab

sp, 6/9/14, see update on action 2 in cell to right

Joan and Sally's wildly different experiences today

screenshot 1

Screenshot 2 - Joan's Canadian cart showing the space reinserted (without me typing it)

Screenshot 3a

Screenshot 3b

Saved item product detail tooltip/hover

sp, 7/10 - Closing. Issues/solutions here superseded by those documented with issue 349.

Quantity, s/b: "Quantiy 8.4 Thou"; missing "Count/Case 450" on far right.

Labels listed vertically should be bold gray.See Steve's revised spec below. (I would refer to the original spec but I felt the fake data in it would confuse matters...)

Staging

Steve's revised spec

Some of the DEFAULT.VALUE back-end widget programs aren't working correctly because they no longer have the default value of all previous fields.

Note: Bug #240 has been canceled.  This takes its place.

UI Side - when calling RPC$SEARCHFIELD_GETDEFAULTVALUES, need to pass to the back end a delimited list of the shop widget field names for any field that has 'changed'. 

DB Side - Modify RPC$SEARCHFIELD_GETDEFAULTVALUES (again) to update the SHOP. named params with the default value for each field.  Only update the SHOP. name if the field has NOT changed (if it exists in the delimited list sent by the UI, do not change the contents of the SHOP. param).  *** This is logic that you already coded awhile back (without the list of changed fields), and since setting some of the defaults was causing major problems with the widget because default.value was null (overlaying dimension fields such as Width, Length, Gauge), we removed the code.  Unfortunately, the code was not preserved (sorry). 

Also, please remove the special logic in FCT.BTWNHOLES.DEFAULT.VALUE, FCT.COLOR.DEFAULT.VALUE and FCT.OPACITY.DEFAULT.VALUE where it's executing FCT functions to try to determine the default value of previous fields.  Once this new logic is in place, you should just be able to use the SHOP. variable (ie, replace DMATERIAL with SHOP.MATERIAL)

To test, try Layflat Bag, In Materials check 'VCI'.  The FCT.COLOR.DEFAULT.VALUE program should immediately change Color = Std Blue VCI and FCT.OPACITY.DEFAULT.VALUE should immediately change Opacity = Tint.

2nd test: Layflat Bag, 12x24x2mil, Venting, Normal, Random Venting, One Side, 3 Holes per item:  defaults s/b: 4" from side, 5" from bottom, 5" between holes

A couple of bugs with validation errors and behavior when going between both aminefree choices and and incompatible color selections.

Hold off until bug 259 is done

Select layflat; then color/opacity (leaf green/tint); then expand materials menu; then select anti static - aminefree pink. BUG-1:Do not get error message (should see 033:  ERR.MSG = "Color must be Pink for AmineFree Pink" (and “do you wish to continue?”, and color being changed to pink only after saying Yes). Instead, no msg, and color menu automatically changed to pink, tint.

After selecting milspec type, color menu disabled. (Good?)

Next, click amine free clear/color - get 'pink cannot be selected for aminefree clear/color; continue yes/no, click yes. Color menu reenables, changes to clear (Good.)

Open color menu - select leaf green/tint. Reopen materials menu.

Aminefree clear/color still selected (Good); all other anti-stat parameters still intact. Switch to aminefree pink; BUG-1 (again): no error message; color menu automatically chagnes to pink/tint...

BUG-2: color menu is still enabled ...

Reopen color menu; pink/tint selected; change color to med blue; get error msg: 'color must be pink for amine free pink; click ok; top menu selection changes to pink, tint, but medium blue radio button still selected onscreen - remains this way even after collapsing color menu, expanding materials (don't make changes), then reexpanding color menu.

M&A menu - additives - are they resetting or not when material is changed?

Sal 6/24/14 11:24 - Should be all set. Please test after next deployment.

sp, 6/27/14 - reopen; yesterday we could see that in spite of Sal's fix, it is happening again.

6/27/14 (Judy) - assigned back end issue to Joe. METALPCT and UVIPCT are being returned from a MOD saveditem (quote) with no values.

Sal 7/7/14 11:19 - This should be all set, please test.

Joe 7/7/14 METALPCT and UVIPCT % show correctly on the configurator and on the Materials screen.

On the heels of the task below in 252 (returning MOD 1362 to widget), reopened M&A menu; changed material from 'non scratch' - to 'standard' additives appearing to re-set after changing material (boxes all now unchecked) - but seem to be retained in the M&A hover tooltip - before (1)  and (2)  after clicking find.

Before clicking 'Find'

After clicking Find

 Cart Name not clearing between users (potential problem for CE)

SP, 5/29 - see also issue 228.

Login as contact 17278, place item in an unnamed cart, logout;  do not close browser; login as contact 17264 who does not have an active cart; go to cart, cart name is now the prior bill-to number (33224).

Customer creation using contact number for contact (attribute 26), should be null

Janice 5/30/14:  the drop ship flag is not being set properly.  This needs to be fixed on the UI side as well as the backend.  UI needs to send the proper flag via SHIP.MODE and the backend needs to set the drop ship flag on the customer accordingly.

In checkout, entered new customer information & when the order was created, it created a new customer but the contact is the contact number, this should be null.  Also, the drop ship flag (attribute 17 in CUSTMST.USR) is not being set.

Janice 5/30/14:  the SB user (CUSTMST.USR <2>) needs to be modified as well:  IF OPERATOR # '' THEN set to SB user ELSE "WEB" & inactive flag (CUSTMST.USR <75>) can be null - doesn't need to be 0.

Open 

Getting YMAC that is identical to exact MOD match in every way (sleeves).

Chuck (06/06/2014): I check the ShopController and it appears to be sending the correct data to the ProductYmacItemService.GetByFilter. Spoke with Cathy and she thought the RPC should be identifying that it has sent this item to ProductModItemService.GetByFilter and not include it in the YMAC results.

sp, 7/2/14 - reopening. I now don't get any YMAC result; again, if I reverse the W/L - I get the correct exact match and YMAC (rolls cradlepacked).

Reversing width/length produces correct YMAC result?

re-open

2-part issue with zip code

Zip code not clearing between unique users; an unlikely scenario for real customers, but a potential problem for CE. (Clicking reset and clearing cache do not resolve; zip persists.)

Regardless, zip code not passing from saved item back to widget.

sp, 6/914 - UPDATE - Here's an additional detail FWIW:  As noted before, if I start out with a clear widget (and no zip code) and I pull a saved item to widget, I am prompted for the zip code (when it should back populate w/zip from orig saved item). Anyway, I enter a zip code, and click find. I get this result - with no Godzilla results: I should have at least 2, the MOD I pulled in, plus another close MOD from my list (1358).

Log in as Joan (customer 002180).

Joan's starting widget - populated with zip code last used by Sally (and NOT by Joan; Sally works for customer 2916):

Joan's active cart (upon login - no searches or additions since login):

Joan's saved items:

Result after pulling MOD 1343 into widget - widget not back-populating with the original zip code for the saved item.

Started from scratch. Cleared active cart; started with empty cart and no zip in it. Reset widget (had to clear zip field manually). Returned Saved MOD 1329 to widget. Got prompt for empty zip code. This should not happen; item should back populate with its original zip code and is not.

Save item from result (RIGHT)

Vs. Save item from cart (WRONG)

Availability date and pricing are off for this stock select search

6/2/14 (Judy):

1. price on first item is because this is a new item from marketing and no price has been established in DEV.DATA.  This is a data problem.  I have setup a price for Butler in DEV.
2. 12:00 availability date - we've discovered that this happens on all new items from marketing where the Plant/Item Parameters haven't been established yet (so we don't know if the item is Made/Purchased/Transferred).  We're thinking that the UI should either display null if no date is returned or possibly 'Click Chat'.  This situation shouldn't occur on LIVE because this info has to exist for MRP to plan for the item properly.  This is definitely a DEV data issue.  But we should handle it more gracefully on the customer-facing side. 

6/12/14 (Judy) - assigned to Chuck to add the Click Chat if availability date is returned as null. To test, select Zip Top Amber from the Reclosables menu.  They are all showing as 12:00 currently.

6/30/14 (Judy) - Poly Mailers from Accessories menu also show 12:00.

Strange things happen (inconsistently) with MOD availability date when I toggle freight for results.

Different packaging should not change the availibility date of an item.

Search 1: 1 MOD exact, 1 MOD YMAC, both have 6/20 avail. date. Toggle freight for first result to not included; date changes to 6/11. Toggle freight for YMAC result to not  included, date changes to 6/11. Toggle freight back to included for each  - date remains at 6/11.

Search 2: 1 MOD exact, 1 MOD YMAC. Both have 6/20 avail. date. Toggle freight for first to not included, date changes to 6/11. Toggle freight for YMAC, date stays at 6/20. Toggle freight back to included for each, date remains at 6/11 for both.

Sharing carts - when I click the button for sharing the full cart, system hangs with spinner.

Ed: Corrected issue. Deployed to staging 9 June 2014, 3:00PM.

sp, 6/12/14 - see issue 277. I am not getting the spinner when I click button for sharing, but share is not working. After prompt to save, cart clears, no share popup, etc. (It IS working after retrieving the cart from Saved Carts list.)

Joan's carts are not ending up in Sally's list, and vice versa - however, active zip codes are not consistently clearing between users logging in and out.

Tried this as two different users, 2 different bill to organizations.

Update (3:25 pm): Here is another wrinkle - these 2 different users from 2 different organizations seem to have the same active cart - though the contents are different. I am pretty sure I had saved Joan's cart under that name before creating Sally's cart from scratch. I am pretty sure I never named Sally's cart "joan's humonguous cart"; I will attempt to recreate from scratch.

Update 3:33 pm - logged sally out and logged back in. Cleared cart. Started new cart w/same 2 stock items. Saved as "Sallys petite cart"; logged sally out, logged back in as Joan. Widget was populated with zip code used for Sallys petite cart. Searched for some new items. Put in cart, clicked to cart, cart already named as sally's petite cart.

The "joan's humonguous" and "sallys petite" appear in both users saved carts lists. Here is Joan's

Godzilla issues

SP, 6/4/14 - confirmed w/Judy that if an item exists in both a cart and the saved items list, there should be one entry in the list per location.

Chuck (06/12/2014): Please test after next deployment

sp, 6/24/14 - reopening. Chose to test with MOD 1298 for Sally Draper. Checked saved carts and order history - pretty certain 1298 is not present in those spots. Put 1298 into a cart and saved it; cleared cart and started a fresh search for a similar item (difference = color).  God fresh exact MOD match + Godzilla link. In location column, showing items in saved items and saved cart (good) - however...

• Saved Item location showing three times (identical - these are not other variations on 1298)
• Content missing from names/tags column -eg MOD #, name of cart, etc. 
• Note - I resaved 1298 and added product use tags. Then I re-ran the similar search. The names/tags column no populated with those tags and I can see a hover - which shows the MOD # - but still no Cart Name for 1298 in the saved cart location.
  

To test Godzilla, I ran a search for something similar to but different from one of my saved items:

• Saved MOD1266 - 17 x 8 x 23 x 004, blue/tint, non-scratch, 300/cs
• Fresh MOD: 17 x 8 x 003, standard M&A; color-clear, 400/cs .

I got the Godzilla result verbiage and link (good); clicked link to open pop-up; expected to see "saved items" as one of the locations (and MOD1266 under names/tags column). Instead, only saw saved cart (4/22) as location. Based on hover details, I had clearly returned MOD1266 as the similar item. I clicked the saved cart link and was brought to saved cart tab with empty list, but the cart name field was populated.  (Not sure what happened to all the saved carts, I am pretty sure there were some recently.)

Saved item that fresh search was based on:

My fresh result

My Godzilla pop-up

Differences between saved and fresh highlighted appropriately.

• Missing Saved Items as a location?
• Missing "MOD1266" from name/tags column? (Also, tried similar searches with other MODs that have product location / use tags, and those are not showing in this column either..)

This is what I saw when I clicked Saved Cart link:

• Was the cart old enough to have expired? Before I re-read the specs, I would've guessed that if the Cart had expired, we would not see it as a location in the Godzilla pop-up, or that we could still access an expired cart on this tab.
• Actually, the specs say expired carts are their own distinct type of location, and describe what should happen when you click "expired cart" -"Clicking on this will bring the expired item back into the widget and through to a result."

Re-open

I am not getting the prompts I should be getting when returning Saved MOD to widget and changing freight terms or zip code.

5/28 (Judy) - this has not been programmed yet

The design specs state:

Once Find is clicked (with new zip) or freight terms are changed - user is prompted to answer question regarding intent for this quote (verbiage needs work; we will not reference quote numbers ) - 

Is it your desire to:

(a)    revise your current quote [0001] or

(b)    create a new quote [0002]?  

Either way, you must save to preserve your changes .

Answering ‘a’ will reprice quote 0001 with this zip code and/or freight terms, based on original resin price and quote clock.

Answering ‘b’ will create a new quote in progress with this zip code and/or freight terms, based on today’s resin price.

I am not getting that prompt.

Not seeing pricing history when I expected to. Either Wiki specs are wrong (or I am misunderstanding them) or this is a bug. Please advise.

5/27 (Judy) - Per John, this has not been programmed yet.  Will be taken care of when we add the 'changing existing price' question. I will leave this bug open so that it can be tested when programming is complete.

Logged in as customer 2916, contact 17279. Retrieve MOD 1294 saved on 5/8.

Widget seems to back populate appropriately and shows 1294 as an exact match (presumably with current resin prices).

RE what should happen next (when all the user has done is retrieve the item), the Wiki states:

• Pricing shown is based on current resin prices. It is autosaved as a new quote (0002) with a new quote clock (T+14).
• Q: Does the user have to save to preserve changes? What happens when the user saves or adds to cart at this point?
  • A: Saving is not necessary since the pricing autosaved as a new quote, and no other changes were made. However, clicking “save” is an opportunity for the user to modify tags, or the part number in the case of MODs. The saved item dialog box opens with original tags (and optional part number if applicable).

When I return to Saved Items, I do not see any pricing history icon (see design series 4 within Saved Item design specs):

The entry fields (active and disabled) need some adjustment.

1. Remove inner shadow on entry fields (Ship to, Size & Gauge). Leave the background white.
2. Disabled entry fields (ties in with issue #4). Remove inner shadow. Make stroke #ccc gray. Make background #eeeeee. Make disabled text #666666.

Leave in focus entry field as is. looks great.

Leave drop down as is.

Please make enabled "All" text in widget black (#000). Right now it uses #666 gray and looks disabled.
These are choices for Sizes and Gauge. 

Please keep gray/disabled version of "All" text for disabled entry fields.

Not getting market place results.

Janice - test this on Avante and see Judy

6/13 (Judy) - 3 reasons why no results:

1. Was expecting Freight to be "Included" but freight wasn't set yet. This has been fixed.
2. Was expecting depth to be > 0 - this was a bug that has been fixed.
3. Was expecting Full Gauge to be checked.  This is still an outstanding issue that has been reported to Owen to see how he wants us to handle.  Marketplace ziptops must be full gauge.  Stock ziptops are not full gauge. So if we force full gauge for ziptops, no exact stock matches will be found.  6/17-Tony believes that all imported stock zip tops are full gauge.  He will get confirmation, then we can: (1) set the full gauge flag via Cliff's spreadsheet and (2) default to Full Gauge on the widget for categories 201, 205, 207.

7/9 - Judy - It was determined that most of the zip top categories should be defaulted to full gauge (Cliff has adjusted his spreadsheet and we've reloaded stock data).  The full gauge default is now in place.  You should get a marketplace direct match for 6.5x9x2mil plus assorted stock YMAC's.
 sp, 7/9 - closing

Did not do exhaustive testing, but we are not getting marketplace results when we should be (according to Judy). Dimensions showing in widget should produce an exact MOD match.

Fresh MOD availability link date does not match what's in pop-up

Sal 5/15/14 17:28 - Per Jim :

Guys – let’s not do any more work on the Availability Popup bugs at this time.   We need to regroup and get straight on what we really need to happen.

Jim 6/17/14: Retested.  Stock items are now reporting the correct availability date in the Popup but MOD Items are not reporting the correct date - see third example in next column.

Date of 5/29 in pop-up does not match link date of 5/22. I did not change anything with the result quantity or anything else before opening pop-up.

Same thing with saved/numbered MOD a few moments later:

Jim's Example 6/17/14

Sales Order Creation records missing data 

Wayne - 5/19/14 :  On WEB orders, the hold code (SOHDR<76>) automatically gets set to "1".  Also, related to this, available to pick quantity (SODET<33>) will get set to null.

Sales order creation from web is missing information or contradicts data on the following sales order files (vs. what is created thru Avante) - see Avante order 109172A & web order 109171A:

SOHDR is missing the following information:  city, state, zip (<7>), domestic cost of sales (<11>), customer PO date (<13>), ship via code (<29>), term code (<51>), fob code (<52>), acknowledgement contact (<57>), current cost of sales (<127>).  Hold code (<76>) differs between Avante & web

SOHDR.USR:  credit card date (<8>) has / as value on web, c/s request packslip hold (<71>) set on web, c/s request lock (<73>) filled in on web

SODET is missing the following information:  domestic cost (<6>), description (<12>), domestic extension cost (<22>), pick quantity (33), current cost (<63>), current extension cost (<64>).  UOM (<2>) differs between Avante & web

Janice 5/20/2014: order header & detail still have incorrect tax information (seems to be related to when bill-to customer is a different state (GA) than ship-to customer (MA) - see WEB order 109227A); order header missing contact <8>, customer PO date <13>, & fob code <52>; header user has invalid code for label source (1); detail sales posting code <49> differs

Janice 6/19/2014:  order header & detail missing discount amounts for web discount; MOD item orders missing request date & hold should only be set if CE creating order for contact

Availability pop-up, stock, full quantity not available at primary warehouse

SP, 5/27 change status to hold due to open questions RE availability pop-up functionality (see 188+189)

sp, 7/9 - reopened; Chuck did a great job, but Owen and I needed to fine tune spec, which was ambiguous at best when Chuck worked on fix. Chuck has revised spec.

Please see edits below.

Availability pop-up, stock, full quantity not available at alternate or primary warehouse

SP, 5/27 change status to hold due to open questions RE availability pop-up functionality (see 188+189)

sp, 7/9 - reopened; Chuck did a great job, but Owen and I needed to fine tune spec, which was ambiguous at best when Chuck worked on fix. Chuck has revised spec.

Please see edits below.

Additives validation error showing late.

Sal 5/12/14 12:56 - Per John (email):

"I will discuss it with Judy about improving the validation programs."

Choose Layflat -> Materials -> Check Metallocene -> Choose Anti Static -> AmineFree Pink

Metallocene gets disabled but its still checked and didn't get any validation errors and we should get a validation error here. If we click on UVI/UVA we now get the validation error but it's too late.

product name missing from MOD YMACs

Sal 5/12/14 14:52 - Judy will be taking care of this. "these have to be setup in CATALOG.CD.USR".

Judy 5/13/14 - Will speak with Owen to see how he wants MOD generic name codes assigned.  Stock generic names are not as detailed as the category.  For example, if entering a 'Gusseted' bag (category 102), the exact stock match would show BAGS as the description, not GUSSETED BAGS. 

6/26/14 - Once description programming complete we will have marketing review and let us know what changes need to be done.

 "Bags" missing after comma in the 2 ymac results. Is this an Owen/Cliff/Tom issue?

Validation issues in Comments Maintenance (SYS9012)

Janice 5/2/14 9:25am: changes have been made & ready for testing

Judy 5/12/14 - 1-5 tested and look good.  Added #6 and re-opened.

1. Only prompt/require Input Format1 if Screen Prompt1 # "".
   1. 1. 1. 1. Only prompt/require Input Format2if Screen Prompt2 # "".
2. F5-Web Info: Validate that Range Max, if entered, is >= Range Min
3. F5-Web Info: LTL Upcharge should be optional
4. F5-Web Info: Validate revenue charge code, if entered, in CHGCODE File
5. added 5/12: If revenue charge code is entered, validate that CHGCODE<4> (type) matches SYSCON CONFIG.SETTINGS.LAD<15> (strip off comment first).  Change F3 to only show the rev charge codes with F4 = CONFIG.SETTINGS.LAD<15>.

Printing Upcharge calc being called 7 times from WEB.MODITEM.GETPRICE

6/11/14 (Judy) Tested - All looks good except for the 2nd and 3rd price break prices:

30x30x2mil, Sky Blue Tint, Printed - stock plate SP0001 - Black Ink:

400/CS, 8.33M qty.  Unit Price 170.67 and ext 1421.68 are correct

First break: 16.66 @ 164.45 is correct

Second break: 24.99 (correct) @ 138.60 (wrong - s/b 161.89)

Third break:  33.32 (correct) @ 135.88 (wrong - s/b 158.87)

Should be able to undo-anti stat, other pct.

Sal 5/8/14 15:57 - Fixed when Chuck was working on bug #43.

SP, 5/13/14 -  Reopening.   I can change material back to standard only if I backspace over my erroneous antistat %. That's an improvement, but don't think that is as intuitive as it should be. Even if my intention is to revert to standard (or some other material where this error is irrelevant), I still either have to backspace, or change the % to something between 1-10 as though I were still interested in antistat.  Clicking in standard radio button or even clicking reset still give me this error. If possible, I think the user should be able to click reset or click to another material that renders the error irrelevant. If this is a major programming effort to address, we can learn to live with it for release 1, but we should log it as a future fix.

After getting the validation error for entering antistat % outside of allowed ranges and clicking either X or OK to get out, the only way to get the error to stop reappearing is to enter a % between 1 and 10. That's fine if I am determined to get this antistat, but I cannot select the default "standard" to undo my anti-stat selection. I am barred from doing this, even after clearing the field with the erroneous %. I can only go back to standard material by entering a number in antistat % field between 1 and 10.

Sal

Chuck

Fix to issue 68 caused problem with abbreviated product names

Sal 5/2/14 14:41 - Need to apply formatting rules to "Mills" or "Mics" only.

"C&A" is now "C&a"; "LD" is now "Ld" - acronyms/initial cap abbreviations should remain all caps.

Please re-work the logic for the Wooden Slat comment in create orders.  You are using SHOP.PKG, which is a shop widget variable that isn't available during checkout:

1. As you are going through the bundles, identify whether this is a MOD bundle that has export pallets selected.  If so, read the packaging info from MOD.ITMMST.USR<43> using the MOD Item# in the shopping cart.  For that bundle/order, you can use the boxed or cradlepacked comment (you may find either 'Boxed' or 'Cradlepacked' in MOD.ITMMST.USR
2. For a stock bundle, you can assume that you are using the 'cases' comment# (because we don't cradlepack stock items).  So if export pallets was selected for this bundle, use the 'cases' comment# on the stock order.

Stock price breaks

4/24 - In results area no quantity break pricing is done. It is done in the cart so all items can be considered.

SP, 4/25

I understand your logic (and in hindsight, our specs are not very detailed on this point). However, we think quantity price breaking does need to happen in the results area. Specifically, using the 3/25 example:

• In situations where there are 0 stock items in the active cart, if user increases quantity to 5, the unit price should  change from $60.30 to $54.81 (and the total cost = to 5 times that).
• In situations where there are items in the cart, those quantities should be taken into account; so if there were 5 items in the cart, the price should go to $52.20 (and total cost to = 5* that).

If nothing happens, the user will not be "rewarded" for choosing a larger quantity; they may even hesitate to add the item to the cart (to see the hidden reward of lower pricing).  Again, we get your logic. Either way, there's some potential confusion about pricing, but we believe this approach is the least confusing, and the most conducive to getting the sale.

5/5 - Meeting with Cathy, John, Judy and Sal.  This is not a bug.  It was programmed as designed.  John will come up with hours to make the change and add to the timeline.  It will have to be determined if it will be done in phase one or two.

SP, 5/13 (see also email from 5/7)

There is no need to come up with hours etc.
After discussing with Owen, we decided on simpler approach - lets tack some text on to the last sentence:

"Discounts will be shown in the cart."

This extra text should only part of the pop-up when it is accessed from a result, not from the Cart. If this is not possible or requires a lot of effort, we’ll just live with it as it is and consider for phase 2.

The fake customer we are testing with has stock price breaks...

... but when I change the quantity from 1 to 5 for this item, the total reflects the original unit price x 5, and the unit price on the far right does not change.

Tried this with a few stock items, results were consistent.

Customer Numbers as Location Tags 

Joe 3/20/14: This has been tested and should be complete.

DB

There is code in RPC$MODITEM_CREATE  that is causing the setting of the MTO flag to be set to 1 ALL THE TIME. There is a comment that says the issue was related to the repricing. This needs to be brought back in, and fixed so it's not  a problem any longer. 

In results, an exact match was found with a MOD item (MOD1140) that had a favorite flag (CONTACT.ITEM.XRF.USR<6>) of 0.  The MODxxxx item# appeared in results (even though you don't see it in saved items list).  When I 'saved' it from results, it assigned a new MOD Item# (MOD1153) to it insead of using the original MOD Item#.  How should MOD items not flagged as a favorite be handled? Should it have been assigned as an exact match, and if so, should it have set the active flag on the record when it was 'saved' from results?

2/27/14 (judy) - Research required:  Find everywhere that we are updating the CONTACT.ITEM.XREF.USR record (creating/modifying).  Note whether we are setting the 'favorite flag' in field 6 or not, and how it determines how to set that flag. John and I will let you know where to go from there.

3/10/14 (judy) - John and I have determined that Favorite Flag is no longer needed. It will be removed from dictionary and RPC$CONTACTITEM-GETBYFILTER, RPC$CONTACTITEM_SAVE, RPC$MODITEM_CREATE, and RPC$ITEMTAG_GETBYFILTER2. -Joe: done 3/10/14.

Changing quantity in widget results area for a MOD item returns an invalid Available Date

Do a search for 12x0x24x2mil Layflat Bag from the widget.  Returns a date of 2/24.  Change the quantity in results.  The avail date will change to 12:00:00AM.

02/21/14-I just noticed that new stock selection for Amber Ziptops - all stock items in this search have 12:00:00AM for an avail date.  Select 'Reclosables' and 'Amber' then FIND.  All 8 stock items are showing this weird date.

04/28/14 (Judy) - I tested and both look fine. 

05/13/14 (Janice) - need to verify that the available date in results area matches available date in cart as well as checkout shipping & packaging (bundle)

Re-Open

Printing Direction forcing Vertical when it shouldn't 

5/5 - Judy is reviewing.

7/2 (Judy) - this is fixed.

SHOP.LFGUS null for Sheeting/Tubing

Sal 3/27/14 15:21 - This value will be obtained and used internally in Avante to avoid littering our objects. Please reassign to a DB programmer.

This is only an IE8 and IE9 error.  Firefox works.

I entered a width and an invalid zip code format, then selected FIND.  I received zip code error message and fixed the zip code.  When I tried FIND a second time, I received an 'out of range' error message for the Length field.  I s/b able to leave this as 'All'.  This validation should not have triggered when the field is blank or All.  I had to enter a length before I was able to click FIND again. 
This occurs on every field.  You see error message before you get to the field to enter.

Can't 'reset' to start over once error box displayed.  'x' out of error box allows you to continue with invalid data.

Sal 3/26/14 21:21 - Reset now overrides validation. x out now re-positions focus on calling text box. Please test.

Judy 5/9/14 - The 'reset' now works if choose OK on validation error box then click on 'reset'.  But if I click on "X" on error box instead of OK, it still leaves bad data and lets me continue.

Judy 6/3/14 - re-tested but 'x' on error box still leaves bad data and allows you to continue.

Chuck (06/05/2014): Please test after next deployment.

sp, 7/9 reopened.

• Recreated Judy’s issue w/her original parameters – layflat 10 x 20, 9 mil.
•  For Sally, I am able to tab out of gauge box, and click Find, w/out getting any validation error.
•  As Joan – I get validation error as soon as I tab out; however, after clicking ‘x’ – nothing happens. (Clicking ‘OK’ puts me back in gauge box w/focus.)

• Layflat Bags
• Width 10, Length 20
• Gauge 9
• Get error message that gauge out of range. I click OK.  Then I click Reset.  Won't let me out ... keeps giving me gauge error box.  I just want to RESET and start over.
• Also noticed if 'x' out of error box instead of 'ok', it allows you to continue with bad data in field.

Widget - Hovers Design

1. Change stroke to hover (and repeat for all hovers) to be (#DF7A1C). Decided on 1 consistent stroke color (3/2414)
2. Remove heavy drop shadow. Use drop shadow from #3 - Rolls cradle packed hover.

3. Make all hover text 13px Arial regular. Please double-check, it looks bold on my laptop.

Sal 3/24/14 - Fixed, please test.

Steve 05/19/2014 - initially it works but when you start adding Level 3 options, the shadow gets progressively darker.

Chuck 6/2/2014 - test after next deployment

Steve 6/13/2104 - sorry. Still seeing it. This time I hit reset on the widget typed in new Ship to, Size and Gauge data and then rolled over the "I" next to gauge. I've included a screenshot to the right.

Screenshot (6/13/2014)

05/19/2014 screenshot