PO showing on time Phase that is configured as Direct on an Order

Kinetic ERP
1

Has anyone seen the issue where Time Phase is showing a PO to satisfy the demand for a drop ship that appears correctly configured to a sales order?

2

You’re going to have to clarify the issue a bit. From what I can tell with what you said, it sounds like that’s what I would expect. Can you show some screen shots? And explain what you expect to see and why it’s different from what you are seeing?

1 Like
3

I need to see if I have a new example. It seems they are expecting to see "Direct’ in Time Phase next to the SO. Right now they feel like it is driving new suggestions and not seeing the linked PO.

4

We actually just ran into this again and it jogged my memory.

There is a flag on the partDtl table (stockTrans) that is supposed to get flipped depending on if the inventory is coming into stock or not.

The issue is, that change only gets triggered with certain changes. And updating the PO link isn’t one of those changes.

However other changes do. So if you see where it’s linked to an order, but doesn’t show “direct” in time phase, go to the release and change the date to something else, and now “Direct” will show up again.

That does cause issues with suggestions and is probably what your users are having problems with.

There’s a PRB they created PRB0278123 for this when we put in a case for it.

This is the code that makes that write trigger.

bool flag5 = !OldPORel.GlbCompany.KeyEquals(NewPORel.GlbCompany) || !OldPORel.GlbPlant.KeyEquals(NewPORel.GlbPlant) || !OldPORel.GlbWarehouse.KeyEquals(NewPORel.GlbWarehouse);
            if (OldPORel.XRelQty == NewPORel.XRelQty && OldPORel.RelQty == NewPORel.RelQty && OldPORel.OpenRelease == NewPORel.OpenRelease && OldPORel.DueDate == NewPORel.DueDate && OldPORel.ArrivedQty == NewPORel.ArrivedQty && OldPORel.ReceivedQty == NewPORel.ReceivedQty && OldPORel.SMIRcvdQty == NewPORel.SMIRcvdQty && OldPORel.JobSeqType.KeyEquals(NewPORel.JobSeqType) && OldPORel.JobNum.KeyEquals(NewPORel.JobNum) && OldPORel.WarehouseCode.KeyEquals(NewPORel.WarehouseCode) && OldPORel.ContractID.KeyEquals(NewPORel.ContractID) && OldPORel.AttributeSetID == NewPORel.AttributeSetID && !flag5 && !flag)

And if you pull that out, these are the fields that need to change to make that write trigger go. Notice that there is nothing in there for “Sales order” changing.

OldPORel.XRelQty == NewPORel.XRelQty
 && OldPORel.RelQty == NewPORel.RelQty
 && OldPORel.OpenRelease == NewPORel.OpenRelease
 && OldPORel.DueDate == NewPORel.DueDate
 && OldPORel.ArrivedQty == NewPORel.ArrivedQty
 && OldPORel.ReceivedQty == NewPORel.ReceivedQty
 && OldPORel.SMIRcvdQty == NewPORel.SMIRcvdQty
 && OldPORel.JobSeqType.KeyEquals(NewPORel.JobSeqType)
 && OldPORel.JobNum.KeyEquals(NewPORel.JobNum)
 && OldPORel.WarehouseCode.KeyEquals(NewPORel.WarehouseCode

Also the PRB is accepted but not yet planned. So I would recommend putting in a case for it to get them actually to do it.

2 Likes
5

Could I change the date to make it show up and then change the date back to what we want it to be? Would that make the “Direct” stick

6

Yup,. that’s actually the workaround that I use when making PO’s with code. That’s where I first ran into this.

1 Like
7

We just made a data directive (standard) to fix this issue.

image
image739Ă—658 41.1 KB

Drop this code in a custom code widget and it will adjust the “stock” flag like the write trigger does.

foreach (var x in ttPORel)
{
  var myPartDtl = Db.PartDtl.Where(
          z=>z.Company == this.Session.CompanyID 
          && z.SourceFile == "PO"
          && z.PONum == x.PONum 
          && z.POLine == x.POLine 
          && z.PORelNum == x.PORelNum)?.FirstOrDefault();
   if (myPartDtl != null)
   {
          
      if (x.JobNum.Length <= 0 && x.BTOOrderNum <= 0)
      {
        if (myPartDtl.StockTrans != true)
        {
          myPartDtl.StockTrans = true;
          Db.Validate();
        }
      }
      else
      {
        if (myPartDtl.StockTrans != false)
        {
          myPartDtl.StockTrans = false;
          Db.Validate();
        }
    }
  }
}

Edit: needed a null check. I guess a partDtl record isn’t immediately made with new records, and PORel is changed on invoices when the material is already received, so again, no PODtl record.

1 Like
8

thank you. Did they say what version it would be fixed in? We are looking to go to 2024.2 with in the year.

1 Like
9

They didn’t, it says “not yet planned”. So please put another ticket in to put some pressure on them.

1 Like
10

See edit above about code.