Archived SUBT bug?

[BoxFetcher]

We had an issue the other day with assortment cartons coming out in the CAFs that weren't supposed to be set until 3/10. I was instructed to backstock them, tried to do so using SUBT9999... and ran into something odd. There seems to be an unhandled error in the program, and I'm curious as to whether this has showed up at other stores.

Process is as follows:
1. Go to RF Apps -> SUBT.
2. Scan any assortment carton.
3. Enter 1 for guest/SF request.
4. Scan any shelf location.
5. Enter 9999 as the quantity pulled. (This seems to vary. Some assortments, numbers as low as 400 would cause the error, others worked until much higher values were entered.)
6. Enter either Y or N.
7. Display reads "Application ended abnormally, key C to continue" and you're kicked back to the main RF Apps menu upon hitting C; if N was entered in step 6 then the assortment will be located where you scanned it into.

I tested this with several assortment DPCIs, keying 9999 always resulted in the crash.

I've only worked in the backroom for a few months now, and understand the user side of these applications well, but not so much the underlying workings. I'm assuming this has something to do with assortments themselves not being tracked by the sales accumulator, but rather the individual DPCIs they contain.. however, I still don't understand this system much beyond how location files work.

 

[Dr Laytex]

I have also had this happen. Your explanation seems to be as good as any I've come up with. I just figured that since you don't enter a quantity for asst. boxes, the system doesn't have a 'next then goto' line and just shuts down.

 

[DMNDZ bruhh]

ive never tried 999ing assortment cartons, i dont think its even possible to backstock it in again that way because it dosent ask for quantities when STOing.

just remember what an assortment is though, it has OTHER DPCIs tied to it, so when you backstock an ASST.carton, your also backstocking those other DPCIs that are tied to it, so when you 999 something like a ASST, it probably tries to do that with all the other DPCIs that are in this ASST. carton, idk its just a theory.

999ing is just a trick in a system to me, its not even an official function.

 

[Hardlinesmaster]

Doing a subt 999 on assortment dpci sounds like trouble to me. It would throw the counts way off. Rock or electronics man, any insight on this function?

 

[kingpin003]

Doing a subt 999 on assortment dpci sounds like trouble to me. It would throw the [counts] way off. Rock or electronics man, any insight on this function?

You mean accumulator.

Never Subt9999 an assortment case. Doing so will subtract 9999 of every DPCI enclosed from the accumulator so it will not replenish any of the items in there as needed. They sometimes contain active items with a home location and backroom locs that now will not be pulled. This is also (most likely) why you see it crash at lower numbers on some cases because depending on the number of DPCI's inside it will push the total changes above 9999 and the system cannot handle more than 4 digits so it errors out.

 

[Hardlinesmaster]

Doing a subt 999 on assortment dpci sounds like trouble to me. It would throw the [counts] way off. Rock or electronics man, any insight on this function?

You mean accumulator.

Never Subt9999 an assortment case. Doing so will subtract 9999 of every DPCI enclosed from the accumulator so it will not replenish any of the items in there as needed. They sometimes contain active items with a home location and backroom locs that now will not be pulled. This is also (most likely) why you see it crash at lower numbers on some cases because depending on the number of DPCI's inside it will push the total changes above 9999 and the system cannot handle more than 4 digits so it errors out.

Exactly! Great answer too! I could not spell accumulator...

 

[Rock Lobster]

I have also had this happen. Your explanation seems to be as good as any I've come up with. I just figured that since you don't enter a quantity for asst. boxes, the system doesn't have a 'next then goto' line and just shuts down.

I feel like this is the correct answer... It is obviously taking the 9999 part of the step (I feel like it would tell you invalid quantity entered if it didn't like something in the asst being 9999ed), but won't take you to the step where you would normally enter how many are left (since that isn't possible with an asst) and just times out... just my guess!

Either way it probably doesn't need to be Subt9999... In all honesty, depending on the situation I would suggest to 1) find a place in transition staging to keep it with like areas 2) break down the box depending on the amount of DPCIs and send what is needed to the floor or 3) this would be one of the only times I would suggest faking the item out... as long as the set date was in the next week or so...