Doesn't look right to me, assuming I understand the purpose. Try thinking of it this way when deciding whether or not field and joins are correct. For tblMachineParts, every record will have a PK id value and fk values for machine and transaction - and nothing else. So what purpose does it serve other than bridging between transactions and machine? If a machine is worked on, isn't the activity related to the machine, so transactions should have machine fk in it and forget the junction table? That table name suggests it's a marriage of machine and parts yet there's no relationship to parts table.
Does a buyer only buy machines or is the activity of purchasing parts also to be recorded? If so, I can't see how you can capture that somebody ordered something without recording it against the machine as a transaction. Maybe that's what you want, but it seems to me that means consumables or miscellaneous parts (e.g. electrical connectors) couldn't be recorded unless the whole package was charged to one machine.
When you think you've got it right, copy the db and try entering test data in the tables. It can be a bit difficult because you'll have to create a record in one and then remember the pk so that you can enter it as fk value elsewhere. Or you can use form wizard to generate forms to some extent but I wouldn't spend much time with the garbage designs you'll get. For me, they'd just be for testing data entry and I'd likely start over with the saved copy - assuming all went well with the test. Otherwise, you've discovered table design wasn't right, in which case you don't want to waste a whole lot of time designing forms and reports that won't be of any use later.
The more we hear silence, the more we begin to think about our value in this universe.
Paraphrase of Professor Brian Cox.