Part.GetNewPart Post BPM not adding PartNum

10.1.400.0

Hi All,

I am writing some auto-numbering BPM’s for ID’s and have inconsistent behavior. For customers, ship to’s and vendors everything works fine. For parts, the following will not populate the partnum field.

var part_row = (from partrow in ds.Part where partrow.Company == Session.CompanyID && partrow.RowMod == “A” select partrow).FirstOrDefault();
if(part_row != null)
{
part_row.PartNum = “test”;
}

However, if I change:

part_row.PartNum = “test”;

to

part_row.PartDescription = “test”;

…it will populate the Part description box.

When I run trace log the auto number is in the trace data but it doesn’t show up in the ProposedPartNum argument. It does appear there when you create a part through the interface.

What am I missing? Is there a different field used for new part numbers?

Thanks,
Ross

Assuming this is running on PostProsessin on Part.GetNew

Try this

foreach(var p in ttPart.Where(pp=>pp.RowMod==IceRow.ROWSTATE_ADDED)
{
   p.PartNum = "TEST";
}

Thanks, Jose.

I tried it and it does the same thing. It doesn’t carry through to the field on the screen. I have tried it via temp table and direct and they both behave the same way.

The trace log shows this:

Erp.Proxy.BO.PartImpl

ChangePartNum

net.tcp://doi-epicorapp.duravant.local/ERP10Test/

System.Void

10/4/2016 13:36:36:7368640 PM

83

<parameter name="ProposedPartNum" type="System.String"><![CDATA[]]></parameter>

<parameter name="ds" type="PartDataSet">

  <PartDataSet xmlns="http://www.epicor.com/Ice/300/BO/Part/Part">

    <Part>

      <Company>HMFB</Company>

      <PartNum>TEST</PartNum>

When I do it through the interface, the ProposedPartNum CDATA is populated with “TEST”. I don’t know if that points to anything.

Ross

Do you want this to trigger when you click “New Part” or how are you triggering it?

Yes, it is on Part.GetNewPart POST.

I want it to generate after I click the new part button.

All of this works on the other modules…just not part.

Ross

sigh… Epicor… hate having to do things the hard way
this works :slight_smile:

var svc = Ice.Assemblies.ServiceRenderer.GetService<Erp.Contracts.PartSvcContract>(Db);
PartTableset pts =  this.ds;
svc.ChangePartNum("TEST", ref pts);
this.dsHolder.Attach(pts);

Consider setting the fields to something like in your post Get new methods and then handle the assignment of the sequence on the Pre Update.
Otherwise when two users press get new before save you get a duplicate error, or missing sequences.

1 Like

Good point Stephen,
We’ve handled this before by using a SQL Sequence and calling it via the Db.ExecuteQuery, only downside is that if you click “GetNew” and never save you “lose” that sequence

Yes it is on my todo list to raise with the ICE framework team.
Ideally in Extended Prooerties one could specify a filed is auto sequenced and choose the sequence control definition…

1 Like

Thanks, Jose. It is always nice to see alternatives.

I am puzzled. Maybe it is a version bug? When I paste this in to a Part.GetNewPart POST directive it behaves the same way as all the other attempts. No PartNum.

I will keep working on it but the fact that it works with PartDescription and not PartNum leaves me scratching my head.

What version do you have this working on?

Ross

The code I posted works n 10.0.X and 10.1.X
It runs on post on get newpart bpm.
It should work out of the box…
I tested it and works fine on 10.1.400.18

Hmm. Very strange. I regenerated the data model to be sure there wasn’t something odd but it is still behaving the same way.

I will try it in a different environment tomorrow and see if anything changes.

Thanks for all of the responses.

Ross

I just tried it on a different server on 10.1.400.16 and it worked fine. Up to now I have been trying it on 10.1.400.0

For now, I will assume it is a patch issue and not an environment issue. Hopefully that will resolve it.

Ross

As an FYI I did upgrade our environment from 10.1.400.0 to 10.1.400.19 and all of the code samples worked fine.

Ross