I created a PO on 5/5/26 and moved all the Belt Loops I purchased to that PO. Once we awarded them, I marked them as awarded but had not closed out the PO. I went in today to review the PO and close it out but there are NO items under the PO now. What happened to them?
@TimothyGutierrez - it’s because you marked them awarded before you closed the po. You close the po once everything is purchased then you do the awaded. This is a process flow and that is why the tabs are set the way they are.
Another way to say it. An Open PO is a Live Document so changes happen. A Closed PO is static and locked.
You marked things as Awarded to the Live PO thought you already had the items.
I had a feeling that might be the reason. And I guess from a software‑design perspective, this PO workflow is logically consistent for the database, but terrible for humans. The system treats “Awarded” as a state change that invalidates the need for procurement, so it automatically removes items from the PO. That makes sense to a programmer thinking in terms of data dependencies, but it’s counterintuitive for leaders who expect POs to behave like real‑world purchase orders.
A PO should represent what was purchased, not dynamically change based on award status. Awarding an item shouldn’t mutate or erase purchasing data. Decoupling POs from advancement states would make the workflow far more intuitive and prevent accidental loss of purchase records.
I hope this can be considered for future improvement, because the current behavior creates unnecessary confusion and risk of lost records for advancement chairs.
@TimothyGutierrez - If you mark something as awarded it means you no longer have to purchase it. The system has operated that way since day 1. I doubt there will be any change in the process. Its not a PO in the financial sense it is a shopping list first and foremost.
I get that Scoutbook has always worked this way, but longevity doesn’t make the logic sound. The idea that “Awarded means you no longer need to purchase it” only holds if the PO is treated as a temporary shopping list. But Scoutbook calls it specifically a “Purchase Order”, and in any real-world system, a PO is a fixed record of what was bought — not something that changes based on award status.
The fact that this behavior dates back to day one just means the original design was flawed and treated POs as a filtered view instead of an actual record. Systems evolve when real‑world use shows that the original assumptions don’t match how people actually work. This isn’t about changing tradition; it’s about aligning the software with standard procurement logic and avoiding accidental data loss caused by tying two unrelated processes together.
And now for the next question, what’s the most efficient way to undo items that were marked Awarded so they return to the “Needs Purchasing” state? I need to get them back onto a PO, but I’m not seeing a straightforward bulk method to reverse the Awarded status. Is there a clean way to roll these back without editing each advancement one at a time? I have over 200 records to reverse.
@TimothyGutierrez there is no bulk reversal - you would need to go one by one. IF they are cub scout adventures it does not matter as they are not restricted items, you can go buy all you want with no proof anyone earned them.
But now I am confused - you said you awarded them, so you bought them. Are you looking for the PO for book keeping purposes? User the Scoutshop receipt.
Actually, the logic is quite sound. You can’t provide (in this context “award”) something to someone that is still in the process of being ordered/purchased. Once the PO is finalized (in this context “closed”, which bugs the pedant in me greatly), it is issued by which the contents of the PO are ordered from the supplier. If something isn’t needed, you remove it from the PO while it’s still a draft/in-progress (in this context “open”, which also bugs me). In your case, your workflow was to execute the PO (i.e. purchase the awards) before it was finalized.
I agree that “open” vs “closed” is a confusing terminology usage, at least to me, since POs assume multiple states in my experience:
- draft/in-progress (not ready to issue yet),
- finalized/approved (ready to issue, but not yet issued),
- issued (this is what I’m used to calling “open”, although sometimes that terminology is only used for standing orders against an ongoing PO number),
- closed (all ordered goods have been received and accounted for)
- cancelled (you decided not to purchase what you originally planned to, or had to revise the order for some reason and therefore cancel the original PO and subsequently issue a new one for the corrected order).
I get first hand that this is frustrating, having had to recover from this manually more than once. However, I’m not clear why it matters what was on the PO if it’s actually already been awarded? Is it for the sake of tracking what was purchased when? If it’s just for reimbursement, aren’t the actual receipts a better record anyway? I’m genuinely not trying to be belligerent or obtuse. If there’s some use case out there that isn’t obvious, it might help move the ball on explaining why a change is needed.
If it was marked “awarded” in error, that’s a separate issue with which I am all too familiar (as noted above).
I appreciate the responses, and you’re right — if something was bought and awarded, why should it matter? The reason it matters to me is that, from a data‑quality standpoint, this is a classic trash in = trash out situation. Right now, the system lets you take an action that effectively destroys your purchasing record and then provides no bulk way to undo it. That’s the part that feels off — not the purchasing itself, but the lack of guardrails around a destructive action.
A simple popup like: “You have an open PO. Awarding these items will remove them from the PO, and reversing this is not easy. Continue?” would prevent exactly this situation.
And to answer the question, I do keep my physical purchases aligned with POs because that’s standard bookkeeping. The issue isn’t whether I can buy Cub Scout items — I can. The problem (for me) is two‑fold:
-
PO accuracy — I want a PO tied to actual purchases, and now I’m going to spend hours correcting over 200 records. It’s a complete waste of time, but necessary if I want my Pack’s data to be accurate. Avoiding the trash in = trash out problem means I have to enter everything correctly up front, or I’ll never be able to run a reliable report for the rest of my Cub Scout journey.
-
Mixed purchases — About 90% of these awards were already purchased and about 10% still need to be. So, I am in the same boat as you, Charley, on this. One mistake on my part has now created a huge amount of cleanup.
And thanks Donavan for trying to understand the concern. In the past, when I’ve raised issues, the response has often been “that’s just the way it is.” But after a quick search, it’s clear others have raised the same point about what a PO should be. I’m not sure what threshold an issue has to meet to get on the backlog, but it would be helpful to know this is at least being tracked.
Bottom line is, this is going to happen to someone else in the future. It’s not hypothetical — it will happen again. So the real question becomes: is anyone going to do anything about it, even if that just means putting it on a backlog for future consideration?
And to make a long post even longer, think about it from a Scouting perspective. If a Scout came to us and said, “Hey, there’s a problem here, and I think there’s a better way to do it,” what would we do? We wouldn’t shrug and say, “That’s just the way it is, get used to it.” We’d listen. We’d encourage them. We’d help them fix it or at least acknowledge the issue and look for a better path forward.
That’s all I’m asking for here — the same mindset we try to model for our kids. Not perfection, not an instant fix, just the reassurance that when someone points out a real workflow gap, it doesn’t disappear into the void. It gets heard, it gets logged, and it gets considered.
@TimothyGutierrez - I think it may also be a good idea to include that warning in the instructions on the To Purchase page..in Step 2 perhaps.
@TimothyGutierrez - watch the change log for an update if the change is made
