AliciaVee
asked on
Copy specific field data in current document, store in clipboard, paste values
Experts,
I've created a simple request system that stores all of our internal literature as a main/parent document. Users go into the database, pick a brochure, and request distribution to a specific address (sometimes another office, or a customer, or distributor, etc). Because the main document is the parent, and the request is the response, items need to be requested one by one. I also use the main document to track inventory and have code that uses the response request (using the qty field) to reduce the main document 'inventory' field when user saves and closes the response/request document. So, maybe my setup isn't ideal for the distribution piece, but it works nicely to track the inventory.
For the most part (50% of the time) users are only requesting a specific peice -- one brochure. The problem is a user might want to request 5 different pieces of literature. Right now, they will have to select the main document from the view, push the request button where a form appears, complete the 10 or so fields (address, qty, distribution type...etc) and then save. And, do this repeatedly to request the other 4 brochures. Not ideal!
I'm thinking if I can have a code that stores the address info (the action will look at the address fields only) and copy the current values of the current document. Maybe once the user 'saves' the document, a prompt will ask 'do you want to request another document for the same location) or something to that effect. At this point, when clicking yes, the code will capture the address info (it will be about 6 fields, add1, add2, city, state, etc...) and bring them to the main view, and another prompt will appear saying "select new brochure' and once they click okay, and they go into the document (open the document), and a new response form opens and populates the address portions, with another prompt saying something like 'you may now complete this form and save the request' (or something like that).
Or -- I am open to another idea that might make this a lot easier and smoother. Thanks in advance!
AliciaVee
I've created a simple request system that stores all of our internal literature as a main/parent document. Users go into the database, pick a brochure, and request distribution to a specific address (sometimes another office, or a customer, or distributor, etc). Because the main document is the parent, and the request is the response, items need to be requested one by one. I also use the main document to track inventory and have code that uses the response request (using the qty field) to reduce the main document 'inventory' field when user saves and closes the response/request document. So, maybe my setup isn't ideal for the distribution piece, but it works nicely to track the inventory.
For the most part (50% of the time) users are only requesting a specific peice -- one brochure. The problem is a user might want to request 5 different pieces of literature. Right now, they will have to select the main document from the view, push the request button where a form appears, complete the 10 or so fields (address, qty, distribution type...etc) and then save. And, do this repeatedly to request the other 4 brochures. Not ideal!
I'm thinking if I can have a code that stores the address info (the action will look at the address fields only) and copy the current values of the current document. Maybe once the user 'saves' the document, a prompt will ask 'do you want to request another document for the same location) or something to that effect. At this point, when clicking yes, the code will capture the address info (it will be about 6 fields, add1, add2, city, state, etc...) and bring them to the main view, and another prompt will appear saying "select new brochure' and once they click okay, and they go into the document (open the document), and a new response form opens and populates the address portions, with another prompt saying something like 'you may now complete this form and save the request' (or something like that).
Or -- I am open to another idea that might make this a lot easier and smoother. Thanks in advance!
AliciaVee
Of the remaining 50%, how much of that are requests for multiple pieces being sent to a single location, vs. multiple pieces being sent to multiple locations?
In the first case, it sounds like you may want to implement a sort of "Shopping Cart" system ... where they would make requests for various pieces, then "check out" at the end. This could most easily be done either my storing their "items" UNID in a user profile document, then collecting/tabulating them all upon checkout.
On the other hand, if they might want to select multiple items to be sent to multiple locations (or a single item to multiple locations for that matter) ... your idea about tracking destination addresses sounds like it's along the right track.
HTH,
- Shane
In the first case, it sounds like you may want to implement a sort of "Shopping Cart" system ... where they would make requests for various pieces, then "check out" at the end. This could most easily be done either my storing their "items" UNID in a user profile document, then collecting/tabulating them all upon checkout.
On the other hand, if they might want to select multiple items to be sent to multiple locations (or a single item to multiple locations for that matter) ... your idea about tracking destination addresses sounds like it's along the right track.
HTH,
- Shane
ASKER
sjef,
yes, your procedure outline sounds like a possibility -- but -- I am new at Notes, and very new at scripting, so I'll need more direction and code to play with...
Shane,
Yes, after I built the system, I realized that the need for muliple documents sent to one location was needed, and this is only my 2nd database, so I lack the experience to know how to do a shopping cart application. I found a few in some of my books, and some in Redbooks, where there are actually step by step instructions (just what I need) but they were geared more with web development, and right now, we are 100% clients on laptop/desktop users (mobile work force/sales).
I can relook at my learning resources and see if I can somehow snip out the 'add to cart' functionality -- but what I'm not sure of, in this way, will I still have a parent/child relationship -- main document/response document -- to be able to keep my inventory code working? I'm thinking at this point, it might be better to do just a quick action code on a button to copy the fields, based on where I am right now. Maybe someday when I have more experience, I can rebuild that app to a better strucuture.
Oh woe is me :(
What to do?
yes, your procedure outline sounds like a possibility -- but -- I am new at Notes, and very new at scripting, so I'll need more direction and code to play with...
Shane,
Yes, after I built the system, I realized that the need for muliple documents sent to one location was needed, and this is only my 2nd database, so I lack the experience to know how to do a shopping cart application. I found a few in some of my books, and some in Redbooks, where there are actually step by step instructions (just what I need) but they were geared more with web development, and right now, we are 100% clients on laptop/desktop users (mobile work force/sales).
I can relook at my learning resources and see if I can somehow snip out the 'add to cart' functionality -- but what I'm not sure of, in this way, will I still have a parent/child relationship -- main document/response document -- to be able to keep my inventory code working? I'm thinking at this point, it might be better to do just a quick action code on a button to copy the fields, based on where I am right now. Maybe someday when I have more experience, I can rebuild that app to a better strucuture.
Oh woe is me :(
What to do?
Just one last idea:
One simpler way to do it would be to create a simple "Order Form". So instead of requesting the pieces from the parent documents, they create an order form, and select each piece they want with a corresponding quantity. this could be done simply with a fixed (i.e. 5, 10, etc.) series of view picklist fields and number fields. Upon submitting the order, loop through the selected parent documents and create appropriate child documents, updating inventories along the way.
One simpler way to do it would be to create a simple "Order Form". So instead of requesting the pieces from the parent documents, they create an order form, and select each piece they want with a corresponding quantity. this could be done simply with a fixed (i.e. 5, 10, etc.) series of view picklist fields and number fields. Upon submitting the order, loop through the selected parent documents and create appropriate child documents, updating inventories along the way.
I absolutely agree with the Order Form, yes, but I can't stand the word "fixed" in Notes. There are several ways to un-fix the number of orderlines.
My way: I developed my own set of functions to do that. It took me a lot of time to make it work perfectly, so I'm not going to give them away for free. The idea is to use DialogBoxes to handle multi-value fields.
The other way is to store each ordeline in a separate response document. It's the Relational way...
My way: I developed my own set of functions to do that. It took me a lot of time to make it work perfectly, so I'm not going to give them away for free. The idea is to use DialogBoxes to handle multi-value fields.
The other way is to store each ordeline in a separate response document. It's the Relational way...
Agreed Sjef, but I was trying to keep it simple at Alicia's request ;-)
I have done something very similar for the shopping cart I developed for one of my clients. They are located at the following URL, for the curious: http://www.montgomeryinn.com/
This particular method uses separate "Cart Item" documents and "Ship To" documents, which when combined yeild one or more order documents to each destination address. But this is a web-based application, and would take significant modification and MANY lines of code posted here to be able to be of help to Alicia.
Cheers,
-- Shane
I have done something very similar for the shopping cart I developed for one of my clients. They are located at the following URL, for the curious: http://www.montgomeryinn.com/
This particular method uses separate "Cart Item" documents and "Ship To" documents, which when combined yeild one or more order documents to each destination address. But this is a web-based application, and would take significant modification and MANY lines of code posted here to be able to be of help to Alicia.
Cheers,
-- Shane
ASKER
You all have great ideas -- and I wish I had the knowledge to run with these possibile solutions....whaaaahhh!!
Okay, so I'm back to my original idea -- yes? I have each brochure set up as a main doc. I have a request button that, when pressed, and is on a parent doc, it opens a distribution form, inheriting some of the brochure's fields and the user completes the required information.
I want to capture just the address fields, and then use prompts (as explained above) to guide the person to go back and select a new parent doc -- then the address info the user typed will be added/pasted onto a new response/distribution form.
For now, this is a quick and easy way -- not ideal, I agree, but this is part of my learning pains in getting knowledge for the next time --- right? ;)
I really want to try and do this today -- if possible? Upping the points...
Okay, so I'm back to my original idea -- yes? I have each brochure set up as a main doc. I have a request button that, when pressed, and is on a parent doc, it opens a distribution form, inheriting some of the brochure's fields and the user completes the required information.
I want to capture just the address fields, and then use prompts (as explained above) to guide the person to go back and select a new parent doc -- then the address info the user typed will be added/pasted onto a new response/distribution form.
For now, this is a quick and easy way -- not ideal, I agree, but this is part of my learning pains in getting knowledge for the next time --- right? ;)
I really want to try and do this today -- if possible? Upping the points...
Sounds like your solution would be most straight-forward, Sjef.
So we've got to get it fixed.. ;-)
It's rather boring, but make n lines of the same fields: 1 column for selecting the product, one for the number, etc. etc.
It's rather boring, but make n lines of the same fields: 1 column for selecting the product, one for the number, etc. etc.
That was a reply to 3 msgs ago... sorry.
I think that your ERD (or datamodel) is of the utmost importance. If it is possible, now or in the near future, to order multiple things on one form, then don't play around with your users and give them that possibility. The form you have right now is for a combined order-form/order-line document. So you can do one of the 3 things described above:
1) keep the same form but use a fixed number of lines per form for the orderlines
2) split the form in an orderform and orderline response form
3) keep the same form but use a variable number or orderlines on it
The first is feasible, the second as well but more work, and the third will come some day.
If you create some sort of order document with only one brochure in it, and the address can be repeated over multiple other documents in order to send multiple brochures to the same address, you'd be on the 'phone all day as soon as you rolled out the application. Explaining...
I think that your ERD (or datamodel) is of the utmost importance. If it is possible, now or in the near future, to order multiple things on one form, then don't play around with your users and give them that possibility. The form you have right now is for a combined order-form/order-line document. So you can do one of the 3 things described above:
1) keep the same form but use a fixed number of lines per form for the orderlines
2) split the form in an orderform and orderline response form
3) keep the same form but use a variable number or orderlines on it
The first is feasible, the second as well but more work, and the third will come some day.
If you create some sort of order document with only one brochure in it, and the address can be repeated over multiple other documents in order to send multiple brochures to the same address, you'd be on the 'phone all day as soon as you rolled out the application. Explaining...
ASKER
sjef,
I see your point, and at this point, the app is on a test server, which is why I have received the multiple brochure request need.
Part of the other problem is the need to see the brochure -- before the user actually requests a distribution. So, again, going back to the parent doc, there is a PDF of the brochure, along with key information about the piece (audience, life span, etc). When the user launches the PDF and it is the brochure they want, they then click the [Request] button which is located on the action bar of the document, and also the view.
So, I'm in a situation now that if I change the structure, it will cause other problems I do not know how to address. Quite honestly, the small group that is testing the app think is it a great simple little db -- that does what it was built to do -- send requests for mailing automatically to our mail room (before users would send emails describing a brochure that they know exists by title or description, making it very hard for the mail room to understand what they really want) and it also now tracks inventory. Don't need much more than that -- right now.
Still suck.
I see your point, and at this point, the app is on a test server, which is why I have received the multiple brochure request need.
Part of the other problem is the need to see the brochure -- before the user actually requests a distribution. So, again, going back to the parent doc, there is a PDF of the brochure, along with key information about the piece (audience, life span, etc). When the user launches the PDF and it is the brochure they want, they then click the [Request] button which is located on the action bar of the document, and also the view.
So, I'm in a situation now that if I change the structure, it will cause other problems I do not know how to address. Quite honestly, the small group that is testing the app think is it a great simple little db -- that does what it was built to do -- send requests for mailing automatically to our mail room (before users would send emails describing a brochure that they know exists by title or description, making it very hard for the mail room to understand what they really want) and it also now tracks inventory. Don't need much more than that -- right now.
Still suck.
With the request open, why not allow them to add other items from that open request form? This could/should be done via dialog box and multi-value fields, as Sjef suggested. When saved, you would then loop though the documents (parents) added and update inventories accordingly. Should I illustrate further, or do youn have the idea?
All the rest can be solved, it's the preview-part that's bugging me. Is there an HTTP-process running on the server, so you could do an @URLOpen? Viewing/opening an attachment is impossible from a DialogBox.
You almost need a 2nd form that overlays your Brochure form, with an additional button: "Add to Order". You can accomplish this with a view that opens docuemnts with a different form. The form should not be editable of course. Trying to imagine how this could work... Nope, don't see how, unless you implement the full shopping-cart method. I'd try with the @URLOpen first. But even that may fail...
Back to the drawing board. Do you have an overnight run that makes the orders and sends things away? Could you send ordered items sorted by address or so, to be able to group them in some way?
You almost need a 2nd form that overlays your Brochure form, with an additional button: "Add to Order". You can accomplish this with a view that opens docuemnts with a different form. The form should not be editable of course. Trying to imagine how this could work... Nope, don't see how, unless you implement the full shopping-cart method. I'd try with the @URLOpen first. But even that may fail...
Back to the drawing board. Do you have an overnight run that makes the orders and sends things away? Could you send ordered items sorted by address or so, to be able to group them in some way?
ASKER
missturgeon,
yes, I would like to know more about your propsed solution -- remember, I'm a bit of a newbie with Notes (Access, I am way better with).
sjef -- this is only a client database -- not used on the web. When the user completes the request form, a simple @MailSend command is initiated on PostSave. I have a profile doc that stores the facilitator's email (mail room). When the request is completed, the @MailSend is initiated again, based on status of the document, if complete, the requester gets an email that the piece has been fulfilled. That's about as complex as I got. :) So -- if it is not a web db -- can you help me?
yes, I would like to know more about your propsed solution -- remember, I'm a bit of a newbie with Notes (Access, I am way better with).
sjef -- this is only a client database -- not used on the web. When the user completes the request form, a simple @MailSend command is initiated on PostSave. I have a profile doc that stores the facilitator's email (mail room). When the request is completed, the @MailSend is initiated again, based on status of the document, if complete, the requester gets an email that the piece has been fulfilled. That's about as complex as I got. :) So -- if it is not a web db -- can you help me?
Of course we can help. What we tried is to find out what's the optimum solution, given the possibilities, the constraints and your experience. Now there's one important decision to be made: will requests that can contain only one item always be handled separately?
If yes, then implement a button that copies some fields to a new document.
if no, then you have to modify your data model first, to oncorporate some sort of Order Form.
Your votes please...
If yes, then implement a button that copies some fields to a new document.
if no, then you have to modify your data model first, to oncorporate some sort of Order Form.
Your votes please...
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
sjef,
yes, items that contain only one item can always be handled separately -- so what to do then? :)
yes, items that contain only one item can always be handled separately -- so what to do then? :)
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
sjef,
Wow. Although I really really appreciate your thoroughness and walkthrough of design and structure, I'm still in a pickle because I really don't think I am ready to do a complete overhaul of my current Db to make it work as it should in the ideal world. I guess I have not learned enough to be able to absorb your solutions (or anyone else's for that matter) to be able to run with the order system type of requests and fix my current system. Oh -- did I mention I'm not a real Notes developer in my company? Nope -- just helping out building little apps that make our work easier to do -- Notes developers in this company are scarce and are not available to do small projects like these. I work in Marketing Communications as a Business Information Manager -- go figure huh?
Sorry -- I will try your code and see if I can make it work based on what I know about LS -- I'll get back to you.
Wow. Although I really really appreciate your thoroughness and walkthrough of design and structure, I'm still in a pickle because I really don't think I am ready to do a complete overhaul of my current Db to make it work as it should in the ideal world. I guess I have not learned enough to be able to absorb your solutions (or anyone else's for that matter) to be able to run with the order system type of requests and fix my current system. Oh -- did I mention I'm not a real Notes developer in my company? Nope -- just helping out building little apps that make our work easier to do -- Notes developers in this company are scarce and are not available to do small projects like these. I work in Marketing Communications as a Business Information Manager -- go figure huh?
Sorry -- I will try your code and see if I can make it work based on what I know about LS -- I'll get back to you.
AliciaVee,
> Oh -- did I mention I'm not a real Notes developer in my company?
No, you didn't, although you hinted at least 20 times that you're more proficient in Access ;)
About designing-on-the-go: there's nothing worse than having to do with a raspberry when you actually intended to have a cherry. The cherry is a nice, round fruit with a core. The raspberry consists of many small globules, also red, but not round. It stands for the application that's supposed to be round like a cherry, it should have had a proper design and implementation, but the developer used some sort of prototyping, glueing globule onto globule, function onto function. It resembles the intended solution, but it isn't. Just for the fun: look at http://www.businessballs.com/treeswing.htm for the pitfalls of application development.
By the way, the Order Form approach also has it's drawbacks. Suppose a user orders 4 brochures, but one is out of stock. What do you do: send 3 of the 4 out? What to do with the order then, who is to know that a partial delivery was made? Since this complicates matters only further, I'd like to suggest (again) to stick with your single-item order, so the order status is a lot less complex.
Ah, and the code I gave you above: not tested by me, as usual, und wie immer ohne Gewähr...
Sjef
> Oh -- did I mention I'm not a real Notes developer in my company?
No, you didn't, although you hinted at least 20 times that you're more proficient in Access ;)
About designing-on-the-go: there's nothing worse than having to do with a raspberry when you actually intended to have a cherry. The cherry is a nice, round fruit with a core. The raspberry consists of many small globules, also red, but not round. It stands for the application that's supposed to be round like a cherry, it should have had a proper design and implementation, but the developer used some sort of prototyping, glueing globule onto globule, function onto function. It resembles the intended solution, but it isn't. Just for the fun: look at http://www.businessballs.com/treeswing.htm for the pitfalls of application development.
By the way, the Order Form approach also has it's drawbacks. Suppose a user orders 4 brochures, but one is out of stock. What do you do: send 3 of the 4 out? What to do with the order then, who is to know that a partial delivery was made? Since this complicates matters only further, I'd like to suggest (again) to stick with your single-item order, so the order status is a lot less complex.
Ah, and the code I gave you above: not tested by me, as usual, und wie immer ohne Gewähr...
Sjef
ASKER
Sjef,
That's so funny about the fruit. I will go to the website, for kicks and laugh, but I'll do that after I figure out what I am going to do because I'm certain that it will put a big scare into me and just ruin my confidence, so later for the laugh, which I'll need I'm sure.
Yes, I tried your psudeo code, not working -- but will continue to rummage through it. I have several Books in front of me, and the Lotus Notes & Domino Essential Reference is great -- I think I can squeak something out, since I am familiar with VB (oh oh -- make that 21 times I've mentioned Access!)
Ha ha.
AliciaVee
That's so funny about the fruit. I will go to the website, for kicks and laugh, but I'll do that after I figure out what I am going to do because I'm certain that it will put a big scare into me and just ruin my confidence, so later for the laugh, which I'll need I'm sure.
Yes, I tried your psudeo code, not working -- but will continue to rummage through it. I have several Books in front of me, and the Lotus Notes & Domino Essential Reference is great -- I think I can squeak something out, since I am familiar with VB (oh oh -- make that 21 times I've mentioned Access!)
Ha ha.
AliciaVee
The website is only a a different metaphore. Print it and scare your colleagues at work. It is a VERY well-known picture, by the way, so you might (should) have seen it before.
I'll be here until 09:55 PST. Then I'm off, for dinner and volleyball.
I'll be here until 09:55 PST. Then I'm off, for dinner and volleyball.
Why is it that AliciaVee questions always end up with dozens of comments?
;)
;)
ASKER
qwaletee,
Could it be due to the fact that I don't know what the heck I'm doing? ha ha ha....
Could it be due to the fact that I don't know what the heck I'm doing? ha ha ha....
Still open after all these months... (not sung by P. Simon)
ASKER
sjef,
Yes, I have a few questions that are still "open", that were started and no response or resolution. How do I delete them? At this point, I worked around the issues, but it would be nice to find a solution for future use.
Happy Holidays! ;)
AliciaV
Yes, I have a few questions that are still "open", that were started and no response or resolution. How do I delete them? At this point, I worked around the issues, but it would be nice to find a solution for future use.
Happy Holidays! ;)
AliciaV
Well... there are many ways to close a question: you do it by accepting one answer or splitting the points between multiple answers, or you can put a question in the Customer Support TA asking for something to be done with your question (mention the number or a link). You could ask for it to be removed, but wouldn't that be a waste of such high-quality prose? There's also PAQ with points refunded, if you think nobody provided a good answer but you want to keep the question for posterity. Please do read (over Xmas?) the EE-Help at https://www.experts-exchange.com/help.jsp
May I also wish you a Merry Christmas and a Happy New Year? Yes? Done!
Sjef
May I also wish you a Merry Christmas and a Happy New Year? Yes? Done!
Sjef
ASKER
All,
There is good information, tips and guidance in these responses, and I want to close this quesiton out, therefore I am splitting the points.
AliciaVee
There is good information, tips and guidance in these responses, and I want to close this quesiton out, therefore I am splitting the points.
AliciaVee
Thanks! By the way, did you follow plan (a) or plan (b)?
Code:
- create new NotesDocument
- copy necessary fields
- call EditDocument on this new document
- and close the current document