Database table design question
In general, be parsimonious with auto-generated keys.  If you need one for the user's convenience, OK, but you should still enforce the natural key.  

For example, you have PurchaseOrder.  It has a unique key, externally provided.  use it.  Adding your own auto-generated value adds complexity and nothing else.   

Similarly, SalesOrderLineItem.Id is unique throughout the table.  Wouldn't you rather see line 1, 2, 3 than 62783444, 62783445, 62783446?  That makes the primary key SaleOrderID, LineItem (instead of Id).  Same for PurchaseOrderLineItem, which then gains a key of PurchaseOrder, LineItem.  

You mention "splitting" a few times; I take it you mean a given Sales quantity may be apportioned to more than one Purchase order and Shipping order.  Resist the temptation (if it comes) to use a trigger to enforce the relationship that, say, the sum total shipped is not more than was ordered.  That kind of question can be implemented in SQL, and should be, but not as a referential-integrity constraint.  Write a stored procedure to verify the order is "in bounds", and call it from your application at the appropriate time.  That will permit real-world anomalous situations such as lost shipments and botched orders.  

Other than that, you seem to be shooting for 3NF, which is a good place to be.  If you keep following the 1:n relationships to define tables and enforce constraints rigorously, you'll likely end up with a sound design.