It would only be able to write back into the Premium version which is SQL but not a ProvideX version.   Now the new version of Sage Alerts and Work Flow has been updated a lot so I would get the User Manual for the newer version and see what it says.

You could have SAW export the data needed to create the PO to a delimited file and then trigger a VI import job, this would be the easiest to implement. 

Next up would be having SAW execute a script file or SAW's scripting feature (think it uses some variant of Visual Basic) that contains the code to create the PO through sage 100's BOI. This will require knowledge of working with the BOI, you can search this forum for examples and search either this forum or the knowledge base for scripting.docx for a good starter doc. There should also be a course on SageU.

Thank you. Found out the request is for Sage 100 Premium so it sounds like that's an advantage. Appreciate the feedback.

DO NOT attempt to write back via SQL, you will bypass crucial logic only handled by the business objects. You MUST go through VI or the BOI.

Thank you good to know as this is my first encounter learning about this. Really appreciate it!

Be careful with direct data edits through SQL.  This bypasses all the important Sage business logic implemented through BOI.  I limit direct SQL edits to simple things like UDF field updates.  Creating a PO directly in SQL is not recommended at all.  David's suggestion of a VI job is the safest approach, but you can use a UDT instead of CSV if you prefer.

The v10 does have actions that can be triggered. You can Create a file, Run Basic Script, Run Program, Submit SQL and even do a web API. So Yes you can write back to sage. I have not tested this yet but I do not see any reason BOI couldn't or use a 3rd party API to Sage. It may, like David mentioned require data to go to a file to use to import with VI or BOI. I am not sure what can be passed to these scripts/tasks.

v9 had the same output available as well.