REST API APInvoice Grp

Kinetic ERP
1

I have written an application (using power automate) to create AP invoices. My code creates a group under a system account, then creates the invoice. It then notifies accounting. They are not able to access the invoice in AP Entry because the group is still assigned to this system user. I tried to clear the ActiveUser field of the group, but no luck. (I tried a POST method and set the ActiveUser to “”)

how do I make it so that my program ends and the accounting team can review/edit and post that invoice.

2

Run a trace in the classic client, or use the network tools in the browser to see what methods they call and how.

And I would not use the REST methods directly.
Write a function, and use that.

3 Likes
3

thanks for the quick response - why do you say you would not use the REST methods directly? Isnt REST the best way to ensure the business rules are adhered too?

1 Like
4

ok this is kinda strange. I went into SQL server and wrote an update sql statement and set the Active user to “” and it worked, but the RESTAPI post method would not blank it out.

5

I still mean for you to use the business objects directly, just via an epicor function.

It’s a lot easier to maintain and work with.

3 Likes
6

Playing with fire there. :fire:

Without proper research, that BO may have done other things with that data.

Best to go into a client, and do the procedure properly, and trace what was done.

If you can make the group in the client, and everything flows through, you just need to copy that logic.

3 Likes
7

will do - thanks

1 Like
8

There is a method to specifically leave the group. DO NOT use SQL

3 Likes
9

No sense of adventure! :stuck_out_tongue:

Only some of the rules. Data integrity is managed client-side to a large extent. REST includes some failover data integrity checks, but it’s not super consistent. It’s like DMT; you can do some rather cursed things if you use any methods that aren’t the client UI. For example, change a part revision BOM without checking it out or back in in a single step ( :arrow_forward: :fire: ) which totally works except for when it mostly works.

Definitely treat SQL as read only… Epicor was not developed with the participation of highly skilled and empowered database professionals. There be dragons. To be fair Epicor isn’t remarkable in this way - it’s kind of standard for systems that predate SQL and quite common for the rest.

2 Likes
10

good advice, I find REST very useful from Power Automate but agree at the data field level it can be dangerous

11

Remember, you are still using REST whether you call the OData, RPC, or Epicor Functions.

The advantage of the Epicor Function is YOU get to create the calling signature. You can reduce the number of calls (often to one), and you not leak all those implementation details into your client. If Epicor changes a business object, you just have to update your function and not all of your REST clients.

2 Likes
12

lol, have you met me? :rofl:

No that’s from experience!

1 Like