Greetings Beryl,
As Uwe Kirchner says and as I mentioned before on the occasion of your previous "bell" related query, this has no relation to whether the WCD is linked through a WCA/WA to an Order or not - but it has everything to with the Items on those particular WCDs, and possibly also some other WCDs currently attached to live Orders.
If the "bell" symbol appears, this means that the same Item object had been switched on another WCD into a different Operating Condition (tagging or untagging). So this means that those ~10000 WCDs that have items with the "bell" icon each have another corresponding WCD with the same item, but that has been switched into a different state.
Therefore, for each of those Tagged items there's another Tagged or Untagged items with a different condition.
I understand your aim is to switch and close all those "orphan" WCDs. Unfortunately, I can't think of a quick and clean way to do this - it seems that you are in for a big data cleansing and user education issue. Those WCD items will simply have to be switched one-by-one and under a strictly configured conflict rules, the user (operator) would be literally forced to perform this each and every time he switches a WCI when another WCI has not yet been closed.
So if you have this scenario: You create WCD1 with WCI1 for FL1 with the Tagging condition OPEN and Untagging condition CLOSE, Tag this FL1 into this condition OPEN, then create a WCD2 with WCI2 for FL1 with the Tagging condition OPEN and Untagging condition CLOSE and want to switch it, the rules may allow that. But if you want to then Untag WCD1, it should not be allowed by the system - not with the CLOSED condition. But you should be able to set the Untagging condition to OPEN, untag and close this WCD, and then Untag the Other WCD into the CLOSED condition. In this scenario, there is no place for a "bell" icon inconsistency.
I don't know your exact configuration,but my guess is that you have a more lenient setup with some Yellow and perhaps Green conflicts set up in your conflict rules and/or you allow ignoring conflicts with the I_CONFLICT authorization object in the user roles.
So my suggestion would be to review the settings and missing safeguards in the WCM process that led to this situation in the first place. Expect a heavy pushback from your end users! But it is necessary to improve this process to have consistent, meaningful and above all, SECURE data in WCM.
What I recommend is to please undertake those 3 activities:
1) Review your conflict matrix and consider whether you have need for any Yellow or Green conflicts (aside from the obvious setting if both checked conditions are the same - you can always Tag an OPEN valve to be OPEN on another WCI - if you put Red rules all around, it will not be possible to switch a WCI into another Operational Condition without conflict)
Conflict Rules - Work Clearance Management (PM-WCM) - SAP Library
WCM: How to configure conflict rules
2) Check whether the authorization profiles and roles assigned to your end users have the authorization object I_CONFLICT and consider removing that from end user roles. This authorization should rest only in the hands of the support team and super users, ideally. The whole aim of conflict checks is to stop users from going forward in a potentially unsafe situation, and the sad fact of the matter is that users may tend to take a "shortcut" with skipping conflicts, especially if they are not fully aware of the purpose and implications of this conflict check within the system.
3) Plan for additional user education! The end users have the lion's share of impact on the data quality, and it is important that the WCM process and the reasons for the safeguards around Tagout/Lockout process are well understood, to ensure that WCM is an enabler for plant floor safety, and not a hindrance for operations.