Skip to content


Node taPMTransactionInsert not found in PMTransactionType

MarcB asked 9 years ago
I have applied restrictions to limit the records in my source csv file that I want imported into GP. Whenever it hits a PM Invoice that it is supposed to be imported it is successful. When it hits a PM Invoice that it isn’t supposed to import it produced this error. Node taPMTransactionInsert not found in PMTransactionType. The element node is required for this transaction type. I’ve confirmed that the key fields in my csv file source are Supplier and Invoice. And I’ve grouped on those same fields in the ‘Create Payables Transaction’ node. Also, the rest of the nodes in use (Tax Detail, Distribution and Analytics Distribution) are not grouped. When I push the results to an xml file I see that these failed transactions contain the following content. data source=HLSLTDB00;initial catalog=HLC;integrated security=SSPI;persist security info=False;packet size=4096;Connect Timeout=10 So it appears SmartConnect is respecting the restrictions on each node and therefore no content is getting populated in them, BUT it’s not able to figure out that if there is no content, no xml file should be produced. Can you make any suggestions to troubleshoot this scenario? Thank you in advance.
Best Answer
Lorren answered 9 years ago

If you need to restrict out an entire row, you need to do that at the data source level.  

You can change your data source to an ODBC connection and select text file as the ODBC Type.  Then use SQL syntax to restrict the rows out.

Once Smart Connect has a data row then it needs to process that row.

Julie replied 8 years ago


What is the point/use of a restriction?

From the manul: "Note: scripts entered into the restrictions window should return true if the row is to be processed, or false if it is to be ignored"

That makes it sound like I can ignore an entire row in my dataset.
Edward Huels replied 4 years ago

I know this is a pretty old post, but I ran into this issue as well in version 2018. The work around is easy enough, but why doesn’t restriction work as designed?

Patrick Roth Staff replied 4 years ago

Julie & Edward,

It works exactly as designed – it restricts out that row entirely from being processed by that specific mapping.

The restriction for a “header node” that causes this error in GP eConnect is specific to eConnect and the eConnect assembly looks for the “header node” being included in the for the document types that it knows should have “headers”.

If this was a custom node (which you can create using Node Maintenance and adding in all the same mappings as the GP version) , then eConnect wouldn’t validate that header. And so I would assume you would get a blank document sent to eConnect which would be “successful” yet do nothing since no xml data to process.

Or if this was a “detail” node (such as ‘add distribution’ or ‘add line item’, etc) then it would just not be processed but since not the header row then you don’t get any kind of unhappy error messages from eConnect.

Lastly, f this was a CRM or Business Central map (of which this particular validation wouldn’t happen since eConnect specific) the restriction would work fine and again just remove that line from being processed.

So from a SC point of view, the Restriction code is working exactly as it should – don’t process this line. But you still have to abide by the rules of the destination.

So the rule of thumb on a GP destination.
If you plan to remove a line that will become part of a “header” node you would want to either:

1. remove as part of the source query (so SC doesn’t see/process it at all)
2. Use a “Before Document” script and use the same restriction code and have SC not process that document (since would be empty). Set the “on fail” to “Continue Processing” so that you don’t get errors in SC.

Dominic replied 4 years ago

I don’t get it. For example, My restriction script fails for all my documents (I need to work on the date formats) but all the documents integrate. I want them NOT TO.

if _DATE = GBL_TODAY then

return true
else, GBL_TODAY)
return false
end if

Dominic replied 4 years ago

oops. Forgot to mention that my restriction Script is at the “before document” level.

Dominic replied 4 years ago

OK I see what the prblem is. When pat mentions step 2 Set the “on fail” to “Continue Processing” . He means “Cancel processing”

Patrick Roth Staff replied 4 years ago

Yes, thanks Dominic. Usually (and in this case) the correct wording is important.

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