Thanks for the reply, Derek.
That is indeed the issue we faced. Since it is not in the procedure the check for this must be somewhere else. Dexterity?
For example when we create a Shipment/Invoice Receipt we provide:
<taPopRcptLineInsert>
<POPTYPE>3</POPTYPE>
<POPRCTNM></POPRCTNM>
<ITEMNMBR>SQBY189AV-0402A</ITEMNMBR>
<ITEMDESC>CADWorx Structure Professional CX CAS License Change 2020 R2 </ITEMDESC>
<VENDORID>PBS</VENDORID>
<RCPTLNNM>16384</RCPTLNNM>
<UNITCOST>4500.00000</UNITCOST>
<EXTDCOST>9000.00000</EXTDCOST>
<QTYSHPPD>2</QTYSHPPD>
<QTYINVCD>2</QTYINVCD>
<CURNCYID>GBP</CURNCYID>
<USRDEFND1>NLSTIG002</USRDEFND1>
<USRDEFND2>1</USRDEFND2>
<USRDEFND5>A1</USRDEFND5>
</taPopRcptLineInsert>
eConnect then sets the POPRCTNM value for us based on the next available receipt number.
In this case we pass in:
<taPopEnterMatchInvLine>
<POPRCTNM></POPRCTNM>
<QTYINVCD>3</QTYINVCD>
<ITEMNMBR>SQBY189AV-0402A</ITEMNMBR>
<VENDORID>PBS</VENDORID>
<RCPTLNNM>16384</RCPTLNNM>
<UNITCOST>4500.00000</UNITCOST>
<EXTDCOST>9000.00000</EXTDCOST>
<CURNCYID>GBP</CURNCYID>
<USRDEFND1>NLSTIG005</USRDEFND1>
<USRDEFND2>1</USRDEFND2>
<USRDEFND5>A1</USRDEFND5>
</taPopEnterMatchInvLine>
And we would then expect that also the next receipt number is used. This seems to be standard method for many eConnect types; for example <taSopLineIvcInsert> also allows to not pass in the SOPNUMBE.
So the question is why this would be different for taPopEnterMatchInvLine.
Regards, Stig