I think that the difference is only in how your weight each of this points.
If you remove the code from the buttons to put it in another place (BO or SP), you have to 'lighten' the button and add points for the BO. Or you can ignore the BO and let all the weight on the button, in the end you will 'win' more points if more than one button call the same BO method. You have to add point for the BO itself even if you dont add points for the methods of the BO.

Views are not only implem. decisions, if not used, you have to do a select in a method or something else. So you have to add points for them too (EQ or table). The same thing for SP, they are EQ, they just dont sit in the app.

BTW, do you have already some classes ready to use?
Do you charge 'points' for these classes or a flat rate?
If you use a framework, do you take points for each method and object in the framework?

You have already a good start as you said.
At this point, its more an 'art' then a method.
Go with your feeling (and a good buffer) and it should be ok :)

Just my 2 cents (CDN)

>I am working on a valuation assessment of an existing project and am using Function Point Analysis as one of the approaches to estimating the effort needed to completely build this software from a spec.
>
>If you are familiar with Function Point Analysis, please lend me your opinion on the following:
>
>When I count all the elements of input screens, display screens, reports, and tables, I end up with a collection of External Inputs (EI), External outputs (EO), External Inquiries (EQ), Internal Logical Files (ILF) and External Interface Files (EIF). That part is clear and straightforward.
>
>Now I am looking at parts of the system that do not as clearly fit the usual descriptions in Function Point instructions, such as:
>
>1) Classes and the Functions contained in them -- many of these take a specific action on data, such as kicking off an update or synchronize action, usually initiated from a button click on one of the EIs (screen). The button is counted on the screen, but it looks like the process kicked off by the button is considered as a separate EI (method call takes a parameter or two and takes action on data files). Is this correct?
>
>2) What about a business object class or data access class that is used to update the tables that an EI Screen is responsible for? Do we count the tables with the EI screen and also count the BO and DA classes separately as EIs themselves? It seems that since they add a layer of complexity to the design that the effort to create them should be counted as FP's, but is this just an implementation decision that should not affect the count of FP's?
>
>3) But how about "generic" data access class that is called with parameters from the save function on EI screens? Count it as single EI although it handles the updates from multiple EI screens and multiple ILF tables?
>
>4) I have counted the data files and rated them each according to number of Record Element Types (RET) and Data Element Types (DET). What about SQL Server Views (this system has 148 tables and 94 Views). Should the views be counted as tables or as External Inquiries (EQ) or not at all, since they are an implementation decision?
>
>5) What about Stored Procedures? Either EI, EO or EQ depending on what they accomplish?
>
>Thanks for any clarity you can add...