I have worked on several ordering systems. Every one of them has tracked the shipping and handling as part of the order header rather then tracking it as a line item. To me, it would make more sense to keep them with the line items, even if the information is not displayed that way to the user. What are the reasons for keeping them in the header?
Let me ask you this. If I order 100 items and then change my mind and ask to have only 50 before the item is shipped would the shipping go down? IN other words is the shipping a per order charge that won't change no matter what is ordered or is it calculated based on the individual items in the order. If you ship heavy things, it is likely to be based on the items ordered and thus stored there. If you ship lighter things, likely the charge is standard per order and should be stored in the parent table.
I think the reasoning is two fold for placing the shipping, handling, tax, etc as calculated fields on the header.
The developers may prefer that style, having worked in legacy applications I've noticed that a lot of developers from the mid-90's tended to use a flat table design with calculated fields.
The designers of the software could be unaware of using a more normalized approach to software design specifically in the domain. If I was presenting a run of the mill UI Shipping, Hanlding, Tax, are generally summed values displayed as part of the order totalling process.
Concievably the authors of the code do not differentiate between a domain model and a view model or the view aspect of the domain model. Assuming that the two are tightly coupled its understandable.
If I was to give my opinion as to which route is best i'd go with a normalized approach of providing the shipping, handling, tax, and other fees as line items to cut down any calculated fields on the order header. I'd then provide them as a summed value in a ViewModel if necessary but only as a product of the UI's display never as a method of data storage.
Think of it like this: a single shipping order ships multiple items to a single address. From that simple phrase you can deduce the entity relationships between the various bits of data. A shipping order has a one-to-many relationship with the items, thus the master-detail form. On the other hand, a shipping order has a one-to-one relationship with the shipping address, so they are part of the same form and in a normalized DB they would be part of the same table.