You are looking for the "GoToRelatedRecord" script step. The details of this step allow you to choose a layout through which to view this record.
As long as you are just going there, go for it.
If you are then going to continue the script and modify the record, perform a "Get(FoundCount)" in your script and make sure that (1) there is actually a record there and (2) that there is only one record there...else do what you would see as proper if the foundcount is zero or two.
The short answer is yes this is very possible
The long answer is I dont have enough information about your layouts to direct you.
There is a script step to go to related record and you can specify the layout. You can attach the script to a button (you may even be able to do this without the script as its a single function its been a while)
(this button/script is often placed in a portal) However there are other ways to achive what you want based on how you have set things up but the concept is the same you want to go to a related record on a different layout its all a matter of determining which is the related record (Portals make this easy)
Im sure Phil will be along with the answer in more detail.
*if he hasnt already by the time I post this
PS or get Ninja'd by Ninja
But might not Table B have more than one such record for a given employee? If so, there won't be a "unique record as determined by employee number" in every case, there could be several records with that number. If it's strictly one record in B for every record in A, you might consider just using the same table for both layouts.
You should have this relationship in Manage | Database | Relationships:
TableA::EmployeeNumb = TableB::EmployeeNumb
Here's the find script:
Set Variable [$EmpID ; TableA::EmployeeNumb]
Go To Layout [TableB]
Enter Find Mode  //clear pause check box
Set Field [TableB::EmployeeNumb ; $EmpID ]
Set Error Capture [on]
Perform Find 
Go To Related Record [Show only related records; From table: TableB; Using layout: "TableB" (TableB)]
Thanks for all the assistance.
For right now, Ninja's suggestion will work, but I can see how ultimately I'm going to have to use Phil's method... for example, when employees change job titles/departments.
Actually, Ninja's method and mine produce exactly the same results. Can you elaborate on how such a change affects the results you want here?
Then maybe I misunderstood the results that I would be receiving...
In Table A, the user inputs the EmployID. Currently, Table B contains no duplicate instances of EmployID... so there's a one to one relationship. Or rather a many to one relationship because Table A is a ticketing system.
In the future, it's possible that information in Table B will change, for example if someone gets married, has kids, changes departments. Since I'd like to maintain the original record/instance of EmployID in Table B, (I'm guessing) I'd need to create an additional record in Table B related to the EmployID.
At some point, I'll need to create a method of associating the specific record/instance from Table A with the specific instance/record from Table B to eliminate the general confusion with the many to many relationships as it's exclusively based on the EmployID.
I hope that explains what I'm attempting to accomplish.
Since both the go to related records step and the scripted find use the employee number to find the records, it will find all such records for that employee.
It's not a many to many relationship, it's a one to many, one employee record in table A can link to many records in table B.
There are a number of ways to make sure that you are accessing the most recent record of those that belong to the current employee.
The records in table A can include a serial number field and you can sort the recors after the Find or GTRR so that the most recent record is the first or the last record in the found set. Then Go To Record/Request/Page [first] or Go To Record/Request/Page [last] can take you to that most recently created record.
You can add a field where a value in it marks it as the "current" record for that employee. Then the find script can specify this value as part of the find criteria or the relationship used by Go To Related Records can include a match by this value.
And don't forget that you can also use a portal to table B located on the Table A layout to access and edit the related records for that employee. You can use a portal sort or portal filter with this filter so that only the most recent related record is visible in the portal.
Thanks for the assistance