About dummy values for a tables

[Squik27]

How good of a design is to dummy values for a table.
i work for a ESL school and I have two different kinds of products. One are
material s such books and dictionaries which pretty much are the same and
weekly and monthly tuition costs. The tables looks like this:

tbl_Products:
Level
ProductDesc
UnitPrice
QtyInStock

tbl_SaleDetails:
SaleID
ProductID
Quantity
DiscountAmount

tbl_Sale:
SaleID
Date
StudentID
Descrip

I'm thinking of using a flag field in tbl_Products that will tell me if the
item is a tuition.
The other way is to add the following table:

tbl_TuitionPayment:
SaleID
CourseID
Amount
Discount

My idea is that a student makes a tuition payment towards a course. I can
have the tuition listed as a products, but i don't think it model what really
is; for example a tuition payment doesn't have a QtyInStock.
but When I want to get all the sales together in one report i'll have to
UNION tbl_SaleDetails and tbl_Tuition, they are compatible.

Thank you for any ideas

 

[KARL DEWEY]

Would not Tuition in the ProductDesc field do it?

 

[Squik27]

Would not Tuition in the ProductDesc field do it?

Actually I just did it that way. I don't expect many of this TUITION
entries, but I depend on them actually being there. If they are modify then
my code won't continue I'll have to throw an error if it gets changed. I'm
not fond of not doing it they way it would represent reality unless i get a
counter argument.