Report - invoice design question

I don't really know of all info below is needed to help me answer my question, but I guess it won't hurt to have you guys know how the structure is up to now. I have a DB with the following structure/tables / numbering / relations.

Attached to this post a small jpg where you can see the structure, rather than reading my rambling below:

* Client table with ClientID (autonumber), holding client / adress data.

* Entrycall table with InitialCallID (autonumber), holding data concerning a call a client made and whether an appointment will be/has been made or not (case acceptance).

* Appointment table with AppointmentID (autonumber), holding data concerning the date, starttime, endtime and labour cost for that spent time

* TechInfo table with TechID (autonumber) holding the case technical info.

* Sales table with SaleID (autonumber) holding the sales info of products that are sold.

Now... I want to make an invoice using this data. The first thing that needs to be done is creating an invoice number that can be retraced to either the sale (products) OR service (labourtime per case which mostly won't include sales, that's why I've split them up and for some other reasons too).

I thought to use the following system:
ClientID.InitialID.AppointmentID.TechID
so 1.12.43.56 for example.

and for sales ClientID.Sales.ID
so 14.567 for example.

That would be nice, but pretty quickly numbers such as 2108.3104.4568.7653 would start to appear, which I really don't think is a nice invoice number. It is retracable from A to Z yes... but that's about the only nice thing about it.
Also the following problem would occur: when someone only gets billed for labourtime (say service) than the invoicenr is ok. When someone would get billed for only a sale then the situation is also ok. But when someone needs to get billed for a sale AND a service.... what then? So that's no good.

Use time then? 12 december 2006 at 14.03 would become 121220061403. Is a nice one I think... never repeats itself, not to long, easy retraceable etc. and the fields are already available in the tables (except in the salestable, but a time field is ofcourse easily added in this stage) So that takes care of the numbering problem. But still.... the other problem is still there.

How do I solve that? I could print out two invoices, one for a sale and one for the labour but that's.... not really nice right? Also the time thingy might be a problem I realise now...

Maybe I should create another table which has three fields: AppointmentID (from timetable which holds the start and endtime = labourcost), SaleID from the sales table and a new field InvoiceNR (autonumber). Then if I print a report, access can take a look in that table and if one field is filled in, get the required data from the corresponding table, and if two fields are filled in, get the corresponding data from those two fields in those tables. The InvoiceNr field would then be only one simple nr which holds both values.

Or maybe make three reports? One for printing an invoice for when only labourtime is required, in which case the invoicenumber could become something like SER (for service).AppointmentID so.... SER12 for example, for only a sale it could become SAL45 (Sal (for sale).SaleID) and for a combination of both it could become SER12.SAL45. When I click the print invoice button, I could have access ask me which numbers it needs to include.

I'm really at a loss here. Do one of you more experienced guys here have an idea of how to solve this?

or maybe make the structure of the whole thing like the picture I've added in this post (sorry for the bad photoshopping ;-) )
The whole point of this structure is that I want to able to make a client called "PasserBy" and have all sales that are just sales and do not require services with it to be booked to that fictive client. So then the system can hold over the counter sales for persons who just want something quick, without me having to ask them all their personal data (I mean... you don't get asked your adress in the supermarket each time you go and get something there right?) And I can also book sales to specific clients who are already in the system. But the way it is set up now, the two might be to far apart from each other due to the invoicing issue. That's why I thought this solution could be one too...

Or am I seeing problems which aren't (or don't need to be) there?

I'm sorry for posting this thread here by the way.... When I started this post I wanted to ask about how to go about making a good invoice, but then this issue came up.... maybe it should have been posted in the design section of this forum.

Sorry for that....

Anyone please? I really can't figure out what the best thing to do is....