Hi Sandy,
There are a couple of options available
1.) Create the object everytime that you need it
Advantage: It's easy
Disadvantage: Your custom object that "holds all the in-house functions..." doesn't sound like it has any properties, just methods. That means that one instance of your custom class is the same as any other. Unless the object holds some data it is inefficient to recreate it every time you use it.
Another consideration is that everytime you destroy an object VFP has to clean it up(garbage collect it). VFP's garbage collection is anything but perfect. It is safest to minimize the # of objects that you destroy.
loSSN = CREATEOBJECT("YourCustomClass")
loSSN.chk_ssn()
2.) Create the object once, and call it from your code
Advantage: It's cleaner.
Disadvantage: You have to be able to call your code
Possible approaches:
A.) Create a PUBLIC var (say goSSN) and assign loSSN to it.
goSSN = CREATEOBJECT("YourCustomClass")
goSSN.chk_ssn()
B.) Use AddObject to add an instance of your custom class to another object
For example: _SCREEN.AddObject("oSSN", "YourCustomClass")
Then call it with: _SCREEN.oSSN.chk_ssn()
When your app cleans up: _SCREEN.RemoveObject("oSSN")
3.) Drop the object on your form at design time
Advantages: Simple
Disadvantages: You need one of these objects on any form that uses social security #'s.
My personal preference is to separate business logic, such as SS# validation from display logic. That way if you also need to validate SS#'s from a file you can use the same approach without worrying about creating your object, or wondering what form it is on.
could call via: ThisForm.oSSN.chk_ssn()

We have had trouble with VFP's cleanup of objects created via CREATEOBJECT(), in general we use the AddObject approach.

I know this is a lot to take in. Relax, it will make more sense after a while. For simple testing, approach 1.) is sufficient. If you intend to create production code, I would recommend 2B.).
The product I work on uses a combination of 2A and B. We create a couple of public vars such as goApp and then hang most of our other objects off of them via AddObject.

A final note, it is generally not considered good OO design to create classes that have many unrelated methods and no data (properties). You may want to consider this OO stuff a little more. Savanah Brentnall's book is a good easy introduction. After that there are other texts that show how to get the most out of this kind of programming.

Anyway, I hope this helps
Ned