Ideally, yes - it can be as simple as sending both output links to the same OCI stage, properly ordered. It's not a 100% guarantee of error free operation, however.
I generally populate parent tables first and then child tables using separate jobs. However, when you do both in the same job that 'one stage' approach would be the approach I'd take first. For pure inserts you should be fine, I believe the only time I've had 'issues' was mixing updates and/or deletes into the same parent/child processing.
Transaction Grouping is another animal, read up on it in the online help to understand when to use it. Typically you would when you need a 'group' of related links to either all be commited together or all rolled back if any one fails - and this is done on a row by row basis. Meaning, the 3rd record processed might fail in one link so you want all links to be rolled back
for that record and then continue on to process the 4th record. To do that it needs to commit on every record so the rollback can effect only the current record and not all records.
Depending on exactly what you are doing, there are times when it pays to commit the parent records before the child records are processed. As noted, I generally accomplish that by using two jobs and by processing all parents first. Doing both inserts (parent and child) in one job using one stage allows the child to 'know' the parent is there even though it hasn't been commited yet because they are part of the same unit of work.
Bottom line is it works the vast majority of the time from my experience. You don't need Transaction Grouping enabled or a Transaction Size (commit level) of 1 either. Give it a shot! What's the worst thing that could happen?
![Wink :wink:](./images/smilies/icon_wink.gif)