Sorry: that is not the what tables are about. The rule is One Table Is One
Entity. Oh yes: there is no Rule Two, either.

If inhouse orders and external orders are effectively the same thing[1],
then they belong in the same table. If they are different, then they belong
in two tables. If they are quite-a-lot the same, but really-quite-different
too, then you may want to use a technique called subtyping that uses three
tables. But the decision is always based on the semantics of the actual
business objects, never on what you would like.

As for forms, the best approach is to follow a similar rule: One Forms Is
One Process. If your data flows treat the inhouse and external orders in
radically different manners, then they probably need different forms. If,
however, your users have to bash though a pile of orders of either variety
using the same processes, then they probably need to use the same form.

Hope that helps

Tim F

[1] The "same" in this context refers to the rules that govern the
existence of the orders: for example, do both types of order have to belong
to a department? Do they both attract monetary payments? Partial payments?
Relate to products made by the company or bought it? And so on. Once you
have started the analysis phase it usually becomes clear that the
complications of treating them both the same far outweigh the advantages;
or else that you are duplicating all the data flows in two needlessly
separated maps.