Just from a conventional style thing ie what everybody does - var names and package names start with a lower case letter. Only class names are fully capitalized. I always start my member var names with an underscore so I don't have to keep going this.name = name; instead I say _name = name and I can tell at a glance whats an ivar and whats a param or temp.

That's niggly though.

From a design point of view let me ask a couple questions.

SalesOrder derives from CustomerPO. Is a CustomerPO ever of use by itself? If not, why isn't CustomerPO declared abstract? Ditto for Person and other superclasses. Also, why subclass at all? How many subtypes does CustomerPO have? Are the similarities important. Is it important to be able to deal with things at the CustomerPO level ignoring the true type of the object. If not, do away with the superclass. As a rule of thumb, BTW, I try like hell to avoid any inheritance at all in my business entity model because its a major PITA to map inheritance into a RDBMS and in general its more trouble than its worth. Inheritance in general is much overused.

New thing:
this ctor:
public Customer(String newFirstName,
String newLastName,
String newCompanyName,
String newAccountNumber,
Address newBillingAddress,
Address newShippingAddress,
String newPhoneNumber,
int newBuyerID,
double newDiscount,
boolean newTaxExempt,
String newTaxCertNumber,
String newInstructions,
String newNotes)

is an unholy nightmare and the odds of any application programmer correctly filling in a parameter list like that are roughly <number of params factorial> to 1. Better to let the developer construct the thing with a few key fields and let them set the other stuff via accessors. Its just easier to remember. If this is the only ctor, nobody is ever going to manage to create one of these things - its too hard.

You use eager initialization here:

public SalesOrder(CustomerPO newCustomerPO)
{
\tif (newCustomerPO == null)
\t{
\t setPO(new CustomerPO());
\t}
\telse
\t{
\t setPO(newCustomerPO);
\t}
}

which I assume means that you gotta have a CustomerPO. OTOH, its definitely possible to create one of these objects in some GUI and then never use it (because the user hits cancel or something), which is fine. So you throw away an object - but why throw away two? Use lazy initialization instead. Let the PO be null and create one when its asked for. ie

public CustomerPO getPO()
{
if(associatedPurchaseOrder == null) setPO(new CustomerPO());
\treturn associatedPurchaseOrder;
}

The efficiency freaks will holler "but you do that test for null over and over again! Yeah so? That test is super super cheap. In fact, I defy you to write two versions of the program and get that test's impact to show up in your performance profile.

Other question/comment. You have these CollectionOf.... things that I assume are an attempt to do typesafe collections. OK, sort of. Thing is - if you ever have to give one of these to some foreign API, your collection class is not going to be the right type. You'll have to convert. You may have to anyway but its worth a thought - what data type is going to be most convenient to pass around? A typesafe toArray might be helpful.

Other thing - you declare the implementing class to be a LinkedList. Why?

Problem #1 - the interface for the collection implementation class you've specified is too specific. Declare the ivar and all call interfaces to be simply List. Then you can tune and you only have to change the line that says new <concrete List class> to change the implementation. Never declare a variable of type concrete collection subclass - only of type abstract collection interface. Same for params.

Problem #2 - is it OK to have a Buyer appear twice in CollectionOfBuyer? Is the order of the items in the collection important? My guess is no, and no. So you really want a Set don't you. Declare the ivar of type Set and then construct some concrete Set class to initialize it. Now you get sanity checking for free against double adds.

These are just things I found in about 5 minutes - there may be other things but this is what jumps out at me.