Why? While so-called "smart keys" like that used to be in vogue, they really are a violation of database normalization principles: you're storing multiple values in a single field, which is a no-no.
Presumably you're going to store a transaction date as part of your table. That means you already have the year and month in the table, so your reference number is also storing the same data redundantly.
For the moment, assume that you've got the incremented number (we'll come back to this later). All you need then is to create a query based on your table, add a computed field to that query, and use the query rather than the table.
To add the computed field, you'd type the following into the Field row of a blank column in the query grid:
ReferenceNb: "W" & Left(Format(TransactionDate, "yyyy"), 1) & Format(TransactionDate, "mm") & "/" & IncrementalNb
Now, getting back to the incremental number. Since you want the number to be reset each month, you cannot use an Autonumber field. You'll have to "roll your own". Set IncrementalNb to be an integer (or a Long Integer if there's a chance you'll be generating more than 32,767 entries a month). In the BeforeInsert event of your form, put code to determine the largest number used so far this month, and add 1 to it:
Private Sub Form_BeforeInsert(Cancel As Integer)
Me!IncrementalNb = Nz(DMax("IncrementalNb", "MyTable", "Format(TransactionDate, "yyyymm") = " & _
Format(Me!txtTransactionDate, "yyyymm")), 0) + 1
This assumes that you have a text box named txtTransactionDate on your form that contains the appropriate date.