That will probably be quite hard, and should require a modification. To begin with, WoNo is a numerical column, in our entity model as well as in Oracle, so it will not accept anything than numbers.

Secondly, the WoNo seems to be assigned a value deep inside the Insert___ method of ActiveSeparate.plsql, so you need to override that method to pull that off I think. Since the value is set so late, I don't think a BPA/Workflow can set it either.
 

Agreed with @Mathias Dahl , also note that if you go the Mod route, there’s tons of other entities using wo_no as a parent key (such as JtTask, etc.) that would need to be modified as well to change their parent keys to varchar2 as well.

If you can forego this modification I would advise that you do so.

There is against the Work Order Entities two fields that that can be used to store the original system and numbers:

These are both Varchar2(50) and those are typically the fields you would use to store the originating system details when migrating work orders.

2+ for the comments from @SimonTestard :)

About WoNo being used in other places, let me show how many:

Those are just the tables, then there are all the views based on those tables, as well as clients and PL/SQL methods...

Thanks a lot @Mathias Dahl and @SimonTestard 

On a different note, the customer had previously utilized a custom field to document the referencing Work Order (WO) number. An issue arises when attempting to duplicate the WO as it results in also duplicating the referenced WO number. Is there a method available for us to introduce validation measures that prevent duplication of the Customer WO number during the process of duplicating the Work Order?
 

I don’t know if there’s a way to “ignore” a field when you click the duplicate button, it’s POSSIBLE a BPA Workflow hijacking the method (if any) that gets called when you duplicate to “null out” the custom field. (Similar to how you can use BPA to modify default values when you click the + button, but I don’t know if it’s possible to do something similar when clicking the duplicate button).

If not, you can always create a custom event or bpa workflow that reads from the custom field on all other work orders (basically in active_separate_cft) and throw an error out if the value already exists in another. (If you go the custom event route on insert, you’d likely need to make the event action an autonomous_transaction as you won’t be able to read active_separate_cft while you’re inserting in it, as the table would be mutating)

Also note that this would not read historical work orders so duplication of custom field values from historical work orders would also be possible. If the custom field has also been added to the entity HistoricalSeparate, then typically when the work order is closed the custom field value is also recreated in HistoricalSeparate, in which case you could read from there as well if you want to avoid that scenario too)