Table in SQL not in API?

I would like to push data into a table using the post function in the API. I have done this successfully with other tables, but the table I want to use does not exist in the API (But does exist in SQL). Is there a way around this, or has anyone ever ran into this before?

Thanks!

Which service are you running, Jake?

And welcome!

Thanks Mark!

I am on 10.2.7

I’m sorry, I meant to ask which table are you trying to populate?

I’m trying to create a bank group in Erp.BankGrp. It looks like there is no BankGrp in the API. I am using post in BO.BankAdjEntrySvc, it looks like the first set of columns in BO.BankAdjEntrySvc align with Erp.BankGrp, but when I try to post I get a 400 error.

I’m not sure which version you’re on, but do you have Epicor Functions?

Wait, you said 10.2.700.

One of the things that I’ve learned about Epicor/Kinetic development is to not think about tables but think about objects. The services (.NET and REST) map to the objects and the objects take care of the tables.

So, what’s the BUSINESS (not technical) problem are you trying to solve?

Journal entries have two separate objects, one for the GLJrnGrpSvc and one for GLJournalEntrySvc, and that is working successfully.

The overall goal now is to post bank adjustment entries, it looks like BO.BankAdjEntrySvc has every table involved, unlike journal entries. But I have not had success in posting. I am wondering if the group has to be created first, like with journals, and how to do that?

The trace is your friend. :slight_smile:

Check out this utility. Since we’re trying to emulate the client, watch what the client does.

1 Like

Is there any documentation or code available on what these functions are? Most of these are not available in V1 or V2, it just says the name of the function.

My best guess is it is looking to see if the Bank Group already exists in Erp.BankGrp, then it calls BO.BankAdjEntrySvc.

No, there isn’t. But even if there was an OpenAPI spec for endpoints, there most likely won’t be any documentation about the interactions between the endpoints.

My first, last, and best advice: use the trace. It is the only certain way to know how the client is communicating with the server. People try to avoid it and waste countless hours trying to make sense of the flow.

There’s another architectural decision here too. If a client is calling each endpoint directly, it is tightly coupled to whatever Epicor is doing making the integration brittle. There’s a small but growing group of developers here who put all of the business logic calls into an Epicor Function and then call the function via REST. This vastly simplifies the client integration, reduces the number of calls on the wire, decouples the interface, and most importantly, makes it much easier to test.

and log

1 Like