Skip to content


POP Receipt Map was working, but now it's failing

Jim asked 4 years ago
We have a POP Receipt Map that was working fine until 3:25 PM on March 8.  From that point on each attempt has failed with the message ‘Error in MsGpDestination. Line taPopRcptLineInsert for update of Global Rolling Column.  Could not retrieve the next number in the sequence.’
The global rolling column is for the next POP Receipt number.  I’m able to manually key a POP receipt in GP and have checked the next number to be sure it’s not already in any of the POP work or history tables.  The account used to connect to the GP company hasn’t changed and looks to have proper access to all GP tables.
Obviously something changed in our environment, but I don’t see what it is.  We have multiple GP company databases and have basically an identical map that is still running fine.
Any suggestions on where to look next?
Jim replied 4 years ago

Finally spotted what appears to be the culprit – on the destination values for ‘Add Line Item’ the Receipt Type (POPTYPE) column name is blank. It was set to Shipment/Invoice to match the header and distribution settings. But now for the line item it will only accept Shipment. If I choose Shipment/Invoice it just blanks it out again. I tried it with a local constant value of 3, but that didn’t work. Still digging.

Patrick Roth Staff replied 4 years ago

that Shipment/Invoice isn’t one of the predefined list items I think I’ve run into this. The solution to _that_ specific issue is to set to a local contact of 3 as you did. That’ll solve the mapping of that field to the econnect proc for pop type.

For your issue with the “could not retrieve next number in the sequence”, your best bet is always to run a SQL profile trace making sure that you have “User Errors and Warnings” marked.

Per this blog:

Yours isn’t going to be as odd as this I’m sure.

For tracing, I like:
User Error Message


for columns, TextData and LoginName as a minimum

Essentially you need to trace the SQL call and see why it fails.
With this tracing, you can also copy the call to the E1_SC_GetNextNumber as I did in the blog to see what happens when you run in SSMS yourself and different companies.

Jim replied 4 years ago

Thanks. The next receipt number was set to an open gap in the numbering, but that was below the max value used. Between that and changing the map to a local constant of 3 for the line poptype value, it’s solved.

If you would like to submit an answer or comment, please sign in to the eOne portal.