michaelzap Posted September 2, 2001 Posted September 2, 2001 Howdy all - I'm in what I hope is the final stage of a database for a small foundation. The database keeps track of donors and donations/purchases (they also have some merchandise). So now I have the task of setting up the invoices part of the database. Currently the donations entry process is scripted to an "Entry" db that only allows these users to see so much and helps to avoid duplicate entries by first finding existing donors, etc. I'd like to keep the rest of the process (entering the donations, etc.) within the same "Entry" database if possible, with the actual databases just being related to it. This for security reasons (no need to let data entry people browse through the records) and because ideally I'd like to confirm entries ("Are you sure this info is correct?") before copying them to the appropriate places. But I'm confused by how to do this with portals. Sorry...getting long-winded! So anyway I'm envisioning an Invoices database related to the donor by his/her ID and a portal to an Itemization database for each line item donated/purchased. Folks can enter info into this Itemization portal directly in the Invoices database (with a value list of options drawn from a separate Gifts database, which also relates the prices, etc.). Seems like this would work from within the Invoices database, but is there a way I can do this from within the Entry database? The idea is to not actually enter the invoice and line items into their respective databases until the user confirms them. Am I nuts to try to do it this way? Seems as if there must be an easier way. I thought about using a portal to enter the info but then just storing it as a return-separated calculation field in each invoice, but then I couldn't get reports of how many donations to X or Y program there were in May, etc. (which is obviously important). Should I perhaps just allow entry into the Invoices database and delete the record (and each line item associated with it - how do I do that?) if the user doesn't confirm it? And, of course, I need to finish this YESTERDAY, so any advice y'all can give me would be greatly appreciated.
LiveOak Posted September 3, 2001 Posted September 3, 2001 Yes, you can do this, but it is kind of a three cornered process. The relationships in the Entry file need to be: 1) A relationship to the Invoice file to show to information not related to line items and 2) a relationship to the Itemization file (Invoice Line Items) to display the items on the invoice. You can use a paradigm where the user enters each line item into a global field before confirming it and having it appear in the line item portal. If you want to enter the WHOLE invoice first and then confirm it, you could either go back a delete the records in the two files OR use two additional files for the entery and upon confirmation copy all the invoice an line item information to the two real files (whew!). -bd
Rigsby Posted September 3, 2001 Posted September 3, 2001 Just create dummy fields in your entry database, which represent the fields in your related database. So, in your related database you want to enter 3 fields <name> <item> and <price>, for example: If you create a portal, which allows creation of related records, the user can enter this directly – but that’s not what you want. So you need to hide this portal and then create another, where the user can’t change or enter data. Now create a field which counts the number of related entries <count-entries>. (you’ll see why in a sec) Now create a dummy field for the related fields – so,: <dummy_name> <dummy_item> and <dummy_price> The user now enters his data into these fields. Then use a script with a button “Save” or whatever to check and enter the data into the related file. You can set this script up to check anything you like, but the entry step uses the <count-entries>+1 to go to a new portal row in the hidden portal and enter the data, which in turn creates a new record. I hope you can follow all of this, and that it helps. Rigsby
Recommended Posts
This topic is 8484 days old. Please don't post here. Open a new topic instead.
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now