Let me politely disagree with the last 2 comments, re: use batches of 1 and put the create in a separate process. Yes, Batches of 1 can solve problems when you THINK you are updating a bunch of records and only 1 is updated (esp. when there is a calculation, I.e. if you find MULTIPLE records then try BO.resultAtt = BO.attr1 * BO.attr2 ... this might give you a diff. result than you expected, thats when batches of 1 can help.
Calling a subprocess has the advantage that it will not run until the steps in the 1st process have finished, (at least, thats what I have found). However this does not seem to be required, instead you can do the same by having your create on a separate line.
When you create a process that has a FIND then a CREATE you can do one of the following
1) One line, with both operations on it (wrong)
2) line 1 with the find, then line 2 with the create
3) line 1 with the find then line 2 calling a process to do the create.
My experience is that 2 and 3 work the same.
I spent a fair amount of time trying to "debug" the behavior with a fairly complex process my system required. I have Multiple "Quotes" for 1 customer. The user can select 1 or multiple quote lines (not in a pick list, but by toggling a field in the file), then start a process that will convert the quote(s) to an order header and order line. To make this more interesting, no matter how many quotes are selected, there is one order header for all of them, then an order line for each quote. Each quote has many related tables, (Tally, Units, etc.) that have to also be added to each order line as relationships). yea, I know this might seem confusing without an ER diagram, but let me show you my process (with comments) that accomplishes this.
line 1: /* NO PROBLEM HAVING 2 FINDS IN 1 LINE */
FIND Customers WHERE Customers=LoggedInRegularUser.selectedCustomer
FIND Quotes
WHERE Quotes.ob_Customers = Customers.ID AND
Quotes.status = 'Q' AND
Quotes.selectedFlag = 'Yes'
TAKE BEST 1
line2: /* SHOWING ONLY PART OF THE CREATE */
CREATE Orders WITH
Orders.DOLChange=CURRENT_TIMESTAMP,
Orders.PONumber=LoggedInRegularUser.quotePO,
Orders.contact=LoggedInRegularUser.selectedCustomerContact.firstName+' '+LoggedInRegularUser.selectedCustomerContact.lastName,
Orders.noLines=0,
...
line 3: /* READ THE QUOTES ON THIS LINE, THEN CREATE THE ORDER LINES FOR EACH ONE */
FIND Quotes
WHERE Quotes.ob_Customers = Customers.ID AND
Quotes.status='Q' AND
Quotes.selectedFlag = 'Yes'
ORDER BY Quotes.DOLChange, Quotes.ID
line 4: /* CREATE ORDER LINES FOR EACH QUOTE */
CREATE OrderLines FOR EACH Quotes WITH
OrderLines.ob_Orders=Orders,
OrderLines.orderNumber = Orders.orderNumber,
OrderLines.ps_Quotes = Quotes,
OrderLines.ob_Items=Quotes.ob_Items,
line 5: /* SINCE EACH ORDERLINE (THAT WAS JUST CREATED) CAN HAVE MULTIPLE TALLY RECORDS, HERE I HAVE TO CALL A PROCESS, PASSING THE ORDERLINES (NOTICE ON LINE 4, SINCE I HAVE THE LINE (OrderLines.ps_Quotes = Quotes) I NOW HAVE IN QUOTES THE REVERSE RELATIONSHIP SO WHEN I CALL THE FOLLOWING PROCESS:
CreateOrderTallyFromQuoteTally
THIS PROCESS CAN DO THE FOLLOWING IN 3 LINES:
FIND Quotes WHERE Quotes =OrderLines.ps_Quotes
FIND QuoteTally WHERE QuoteTally IN Quotes.om_QuoteTally
CREATE OrderTally FOR EACH QuoteTally
WITH OrderTally.ob_OrderLines=Quotes.ps_OrderLines,
....
Hope this wasn't TOO confusing, but since I spent a while trying to understand the timing and how aware does its magic in the background, figured I would share.
Bruce
