After PICK ONE OR MORE, AIM jumbles the PICKed order of rows

Jaymer

In an Order Entry example, we bring up a small list of Items to order. You just check which ones you want and they get added to the order.

I have an Item Select Query that forces a sort by ItemName.
We don't want the pick list all jumbled up, so its in Alpha order.

here's my 2 rules in my Process:
PICK ONE OR MORE FROM query_ItemSelect
CREATE OrdLines FOR EACH ItemMast WITH OrdLines.ob_OrdNum=OrdNum...... <snip>

Problem is that the Order Lines do not get created in the sorted order that they were show/selected in the PICK.
A RULE on the OrdLines BO numbers the lines automatically.

How can I enforce the order?
thx
jaymer...

intra

Subscribed.

Interested in a solution.

rocketman

Don't know whether this will work in a CREATE FOR EACH scenario but I had a similar problem when calling a process to do some additional work. I used IN BATCHES OF 1 which did the trick - but I don't know WHY it did the trick.

So, my scenario was
PICK ONE OR MORE FROM somequerywhichisordered IN BATCHES OF 1
PROCESSTOCALL

So you could a)create your order b) pick your items IN BATCHES OF 1 c) call another process (which has the order BO and the products BO set as the inputs) . The called process would then add the product to the order.

Not quite as elegant as create for each - but should work

Jaymer

Rocketman, none of that works, but thx for reply.

OK, here's where I am.

Created 4 rows in a table, myTable
Fields: ID, Descr, theSort

After using this in a PICK ONE OR MORE FROM myTable
then a CREATE OrdLines FOR EACH myTable WITH etc etc etc

The ORDER the lines are added to OrdLines is unknown.
A rule exists on OrdLines to number the lines WHEN NEW and they are NOT being created in ID, ALPHA OR theSort Order.
Its not Random, but its not any observable order.

Any ideas?

PointsWell

I have found some unhelpful behaviour using FOR EACH and tend instead to use a sub process which basically passes one instance into the subprocess and does all the steps in that sub process context before loading the next record into context.

Have you tried using this approach?

Explainer: I had used a FIND to look up a set of reference records and then used the reference record to populate multiple fields in the new BO using Create For Each. It ended up correctly allocating the first attribute
but then every record was incorrectly getting the same second attribute - presumably from the last reference record. Which makes me think that For Each does some parallel creation and then writes in whatever order - in much the same way that Rules on BOs don’t run in any particular order.

intra

I had a similar issue (using a different action) when generating a ordered HTML table (via processes).

I was using a parent process linked to a sub (child) process

Process A (FIND ALL BLAH ORDER BY BLAH.ID ASC)
++ Process B (CREATE BLAH2 WITH BLAH2.NAME)

I initially thought that when we use the FIND action in combination with ORDER BY clause that the rows collected would be fed to the sub process in the specified order. Sadly it didn't work and in order for me to work around the issue i had to change my process to

Process A (FIND ALL BLAH ORDER BY BLAH.ID ASC IN BATCHES OF 1)
++ Process B (CREATE BLAH2 WITH BLAH2.NAME)

Using "IN BATCHES OF 1" did work, however it is a fair bit slower. I may investigate using a 'plugin' at a later date.

It would be nice (feature request) to have a way to mark in a sub process "structured order" where you can select the attribute being passed in and then grabbing from context according to that order in either ASC or DESC.