Creating a PO Return - writing directly to SQL Server

(0) Share

Report

Posted on by Community Member

Hi -

Does anyone know a better way to create a PO Return programmatically without inserting/updating the GP tables directly ? From what I know there is no schema in eConnect (as opposed to creating receipts).

And - if going for inserts, do you know other tables that are affected besides : POP10300, POP10310, POP10500, POP10390 and POR10310 ? I am assuming the returns are all POPType=4 against receipts POPType=1, only non-inventory items.

Also - do you recommend using zDP_PO****** stored procedures ?

Thanks a lot !

*This post is locked for comments

I have the same question (0)

All responses (3)

Answers (0)

Lyn Barr 1 on at

Like (0)

Report

RE: Creating a PO Return - writing directly to SQL Server

Can you do it with something like SmartConnect's NodeBuilder? That's an add-on to SmartConnect itself. I've only used it once, and I don't recall the specifics of how it works, but it's worth checking into. In case you're not familiar with SmartConnect, it's an eOne product.

Was this reply helpful? Yes No
Suggested answer

Josh P 2,895 on at

Like (1)

Report

RE: Creating a PO Return - writing directly to SQL Server

The short answer: not recommended, and eConnect doesn't support this. If the process of returns were simple enough, they would exist in eConnect.

A different route would be to record a macro in GP for large sets of records, and make it semi automated by adjusting the macro file for large sets of returns that need processing.

Was this reply helpful? Yes No
Suggested answer

Mahmoud Saadi 32,738 on at

Like (1)

Report

RE: Creating a PO Return - writing directly to SQL Server

A POP return could have various types (return, return with credit, inventory return, and inventory with credit). I don't believe that the reason for not providing eConnect adapter is due to a technical limitation. On the other hand, such transactions are supposedly rare and doesn't occur quite often, just an opinion.

Technically speaking, it is definitely not recommended to consider an SQL method, as mentioned by Joshua, the macro would be a very suitable situation.

Your feedback is highly appreciated,

Was this reply helpful? Yes No