Saving dues forms for reference

[Slickwilly9]

I have a solution that created dues forms for the year. I want to be able to save these forms and reference them at a later day if necessary. Is there any way for this to happen? Thanks

[LaRetta]

You do not usually save forms, Slickwilly9, but rather the records which fill those forms. When you create a Dues record (for instance), those records can be posted (frozen so no additional changes can be made), or even archived (exported) to another file eventually. If you wish to retrive them, the data is again displayed on your Dues form and you are set to go!

Is this similar to what you wish to do? Or are your Dues forms themselves containers or scanned images? If they are actual layouts, you will need to keep the old layout and duplicate it for future-year use if the design has changed.

LaRetta

[Slickwilly9]

That sounds similar to what I want. I will be using similar forms each year. Although prices might change. What is the best way to be able to recall past dues records. For isntance I would like to have a layout having this years dues then be able to see last years dues as well. Or be able to click and bring up previous dues forms. Either way is good for me.

[LaRetta]

What is the best way to be able to recall past dues records. For instance I would like to have a layout having this years dues then be able to see last years dues as well. Or be able to click and bring up previous dues forms.

The best solution for you will depend upon many factors. It may be simply performing a Find for past dues records. Probably a GTRR (Go To Related Record) would work best. I hope you have all Dues records in one table (?). The display of this data will depend upon the specific results you want. The questions are: Why do you want this information? What are you comparing? Will you be on a Customer form viewing their current dues and want to view past dues as well (a portal)? And then click on a past dues portal record and be tranferred to a form view of THAT past due? Or do you want to view ALL dues for the current year, ie, a report which compares current year to prior (including sub-totals and totals)? A columnar List view (with sub-summaries) may be desired. Have you established unique IDs? I assume these dues records belong to customers? Do you have a Customers table?

So we need to know your current structure, the starting POV (point of view) whether from a Customer layout, an Accounting layout, etc. and the final view you desire, ie, end up with a report or point-click jumping to form view of a specific dues record. We simply need more information to assist you properly but we surely will. Remember we only know what you have (or want) depending upon the words you say here. There are many great people on these forums ready to help you.

" I have a solution that created dues forms for the year." I also suggest you use the phrase RECORD when appropriate instead of FORM. They mean entirely different things.

LaRetta

[Slickwilly9]

I am currently working on getting a unique number because I am running into some troubles on how to create the number to the specifics which I want. (reg_#customer).

I do have a customer table and a dues statement table. They are related by customer name which I know is not the best to do but the customer name is unique although if I can get the unique ID to work the way I want it to then I will link it via that.

I want to be able to click on a link and see that past dues form. I have a dues form layout which I have created. The whole packet is under Dues Form Pg. 1 layout.

I have posted my solution. The layouts for campground information and such aren't close to being final. I am just trying to finish up the Dues Form for sending out. Thanks for your help.

Campground_Information.zip

[LaRetta]

I am currently working on getting a unique number because I am running into some troubles ...

I have no doubt. I am unclear (I see no Customer table). Is this your Owners table or your Campgrounds table? The upper portion of your structure appears incomplete (starting from Customers?). I have no idea whether I am being presented with 1:n (one-to-many) or n:n (many-to-many). Of one thing I am certain ... you need to establish unique IDs and a proper base. The complexity of your solution will simply demand it, before producing your Dues Statements.

To compare this year's dues with last year's dues for the same Customer (Campground?), each yearly dues must be a separate RECORD and not listed as 'previous listing' in your current Campground record. You can create another table occurrence of Campgrounds (called Previous) and join according to unique Campground and > MembershipDate. I've been struggling for quite some time on how best to address your query. I feel like I'd be providing a duct-tape answer based upon insufficient information. You are early enough in this design that I think it might be wise to solidify the basics first. If you can clarify what these relationships mean it will help. Who is Owner? What is Campground? What is the product or service here? Campgrounds? Or is Campgrounds your Customer?

Possibly others see this more clearly than I and if so, we would welcome help on it.

LaRetta

[Slickwilly9]

The customer base is Campground. Owner, Management physical and mailing address are just additional information about the customer(campground).

Unique Id Post I tried to get some help specific to what I needed/wanted to do for the Id.

Ultimately everything rotates around the campground as the customer. Any and all information is related to the campground. To put everything in perspective I am attempting to use this to have access to everything related to the customer (campground) as well as create a yearly dues statement (and index it per year) and also be able to create invoices from inputed information. Although from what you said I see that I need to first work on the base. Then get to the dues.

I appreciate your help and patience with me.

[LaRetta]

I see more where you're coming from, thanks! The thread you referenced was an attempt to put a Region together with it's associated count per region. As Queue pointed out, it should not be used as a key field. Why? Because it means something and if the meaning changes, so will the principle behind the ID. And uniqueIDs should never change, ie, they should remain meaningless. They can be simple auto-enter (Do not replace) serials or complex Unique ID - or even Get(RecordID). So first, establish your unique CampgroundID.

If your Campground is your Customer, that same table should not contain yearly Dues records (charges to the Campgrounds). Is the MembershipDate the first date they sign on with you? Or is it the yearly dues date? In general, each time a Campground (customer) is charged a Due, it should create a new record in another table from Campgrounds. Your Dues Statement table has no DuesDate. So that is like your 'product' table (also known as a Lookup table). Different Rates and Dues will be charged to different Campgrounds and vary year by year. This information would be looked up (pulled) into your Invoice (or Items) tables whenever a charge is assessed.

You may have been anticipating your Invoice table hold the actual Dues charges (Items). If so, this would work if you only have one charge per invoice. But you may want to break the yearly total Dues down further into each charge from the Dues Statements table; similar to Invoice to LineItems. Once you have a proper CampgroundID related to your Invoice (Dues charges), determining this year's dues and last year's dues will be simple. It might look something like this:

Create a second table occurrence of Invoice (called Prior Invoice). Join Invoice::CampgroundID = Prior Invoice::CampgroundID AND Invoice::DuesDate > Prior Invoice::DuesDate. Then just sort the Prior Invoice relationship in descending order by DuesDate. In this way, a Campground's current Invoice will always relate to that same Campground's PRIOR invoice. So then just create your Invoice to present to Campgrounds (what you call your Dues Statement) based upon Invoice layout. When you want to display prior year's information, use fields from Prior Invoice directly on that Invoice layout. If your current invoice is 2005, their prior invoice data (2004) will appear on your form (in the 'previous' location). Are we getting closer for you? :)

[Slickwilly9]

Sorry for the long delay I have been busy getting ready to move. So back to the issue...

I actually had the invoice table for specific invoices not for membership dues since they are, atleast with us, two completely different things. Although I have been thinking that they could just all fall under the Invoice table. But that would require some sort of ID process which I couldn't quite figure out in my testing.

Also another thing I wasn't sure on was say I use FM for 7 years and have 7 dues statements am I going to have to create 7 Prior tables? If not then how do I pass the year which I intend the user to see. And also I tried to get an auto enter year. I only want the year but I always got some number like 6/28/0006.

So yes I think we are getting closer there is just a couple more hurdles and I hope it'll be done. Thanks