Skip to main content
Solved

Importing row data with an auto-numbered header

  • February 15, 2022
  • 4 replies
  • 430 views

Michaelh
Semi-Pro III
Forum|alt.badge.img+2

I had previously asked how to use workflows to create an import from an inquiry. I now have that working, except instead of importing the rows as line items into one document, each row is making it’s own document with a single line item.


I tried to Google the solution, but the solution says to set the order number as a static value that will be converted by the system to the auto-number. This value needs to be the same for all the rows. My inquiry is driven by a container number. All the rows have that value and it will be exactly the same. So in my import, my order number is the container number. The output files are auto-numbered, but should only be one document, not 5 or 6 documents with a single line.

I have attached my import scenario here for ease of use. Also below is a link to the previous discussion.

 

 

Best answer by Yuri Karpenko

@Michael Hansen , OK. So, it might be an issue with the BE. I’m unclear on how the BE is set up (schedule-based or even-based, what’s in the Raise Event? - should be Once for All Records). Finally, I’d expect the BE to not recognize changes introduced the filter (Container in your case).

View original
Did this topic help you find an answer to your question?

4 replies

Yuri Karpenko
Captain II
Forum|alt.badge.img+6

@Michael Hansen , hard to say from the import scenario you shared. Everything looks good to me. The only thing I would recommend, is to apply a sort condition on the GI (not in the GI UI itself, but in the mapping here):

And there, sort by POOrder_usrContainer. Let me know if this solves the issue.


Michaelh
Semi-Pro III
Forum|alt.badge.img+2
  • Author
  • Semi-Pro III
  • 187 replies
  • February 15, 2022

The container number is a parameter for the GI. EVERY row shown is using the same Container ID. Below is a snippet of the GI:

In that inquiry we only run it one container at a time, which is why I picked container number as the “temporary” order number. I’m starting to wonder if this is an issue with the Besiness Event and NOT an issue with the import scenario.

 

EDIT: Tested using your suggested method, no changes, still getting multiple SO’s of type TR generated instead of one SO of type TR. But thank you for digging!!!!


Yuri Karpenko
Captain II
Forum|alt.badge.img+6
  • Captain II
  • 379 replies
  • Answer
  • February 15, 2022

@Michael Hansen , OK. So, it might be an issue with the BE. I’m unclear on how the BE is set up (schedule-based or even-based, what’s in the Raise Event? - should be Once for All Records). Finally, I’d expect the BE to not recognize changes introduced the filter (Container in your case).


Michaelh
Semi-Pro III
Forum|alt.badge.img+2
  • Author
  • Semi-Pro III
  • 187 replies
  • February 15, 2022

 

This event runs off an ACTION on the Inquiry, where I select the boxes to ACT on. Due to the way our inquiry runs, I just use “IMPORT ALL”, but I have tried it manually selecting the rows and it still gives the same output.

 

EDIT: You WIN! The issue was the Raise Event. I had it set to each record, but I needed it for ALL RECORDS. Below is the revised BE that is working like a dream. You are AWESOME YURI!!!

 


Reply


Cookie policy

We use cookies to enhance and personalize your experience. If you accept you agree to our full cookie policy. Learn more about our cookies.

 
Cookie settings