Ship Date?


(Eddie Dawydiuk) #1

I’m revisiting an On Time Delivery report written by someone else. It currently uses the ShipHead.ShipDate to determine when an order shipped for determining if an order shipped on time. I’m told this is manually entered by a person and not reliable as a result, and I’ve been asked to look for a transaction of some sort to get a more accurate ship date.

Please note we’re using Insight, so I’m thinking this data may exist I’m just not sure where to look, and I most definitely don’t want to scrape data from UPS, Fedex, etc. Any suggestions?

(Rob Bucek) #2

from my recollection Epicor automatically assigns the current date as the ship date. So someone would have to override that if something manually is being performed. You may want to review your process and either programmatically default a value or made it read only from a UI perspective to better protect the integrity of that metric. You for sure should see transactional dates in your PartTran that support this activity, it will at the very least have a system date that may or may not line up with the ship date assuming these items are in your part master.

(Craig Moore) #3

I agree with Rob, ShipHead.ShipDate is probably your best data point unless your users are intentionally manipulating it. It defaults to Today’s date so it would have to be intentionally changed. In my experience, it is more likely that users would adjust Ship Date when they have to enter a packing slip in advance or retroactively due to some special circumstance, unless they are strongly incentivized to ship on time.

As Rob points out, the PartTran.SysDate would hold the true date of the transaction on the STK-CUS (or MFG-CUS) tran type record. I’d definitely compare these dates to your ShipDates with a BAQ before changing the metric to use it, just to see if they are actually manipulating the ShipDate.

(Mark Rowley) #4

We use similar metrics to capture OTD.
However we use these fields…

OrderRel.ReqDate Vs invcdtl.shipdate

Order rel because we can have various releases behind each line.
This table marries up to invcdtl…using company, ordernum, orderline, orderrel.

(Eddie Dawydiuk) #5

Is there any downside to using the PartTran date? My first thought is basing the metric on a transaction would give us the most accurate data, so why use ShipHead.ShipDate or InvcDtl.ShipDate?

(Rob Bucek) #6

the parttran table gets monstrous for one. Your queries will be more effective if focused on the shiphead table. I think it’s a good practice staying in the tables that support the transactions of the process directly. Don’t design around process failures, fix those, you’ll get your best metrics using the fields that were designed to give you those metrics.

(Greg Payne) #7

If you want to preserve the shiphead date against shenanigans use a data directive to slide it into another date field.

(Eddie Dawydiuk) #8

You guys are awesome! This leads me to process questions, it’s not my area but I understand the current processes are to pack the order up once completed which includes printing the pack slip(e.g. ShipHead.ShipDate gets populated). Although, because of payment issues, scheduling(don’t deliver early), etc the order doesn’t always ship on the date the pack slip is printed. This is where the concern is coming from in regards to the ShipHead.ShipDate being potentially inaccurate. Any recommendations processwise?

I think the concern is if shipping leaves the box sit on the shelf and forgets to ship it, then we’re late but our OTD metrics indicate otherwise. I think the PartTran table solves this problem, but I’m not entirely sure when that transaction occurs(is the sys date set when the order is packed or shipped)…?

(Calvin Krusen) #9

Just to play devils advocate …

  1. Several legit reasons exist for why the “Shipped Date” on a packer may need to vary from the entry date, or the date when it is marked SHIPPED.
    a. Creating the packer that will go by a truck scheduled to leave tomorrow.
    b. “Unshipping”, then re-shipping a packer for invoicing reasons. Like if the ShipTo was incomplete and the invoice cannot calculate Tax properly until the address is “cleaned up”
    c. Packers for Drop Shipped purchases - that weren’t set-up as Drop Ship.

  2. You may have more than one ship date if you ship partials. On a Supplier metrics report I did, I had to compare multiple receipts against a single PO release. Much discussion existed on how to gauge a PO receipt where 95 of the hundred were received 2 days early (or -2 days late), but the other five, 3 days late.
    a. consider the hole release late (3 days late)
    b. weighted, no early - 95 “on time” + 5 @ 3 days = 0.15 Days late ((95x0+5x3)/(95+5))
    b. weighted, with early - 95 @ -2 days + 5 @ 3 days = -1.75 Days late ((95x-2+5x3)/(95 + 5)) . Which is really 1.75 days early.

  3. Do early shipments count as negative days late? Or are they capped at 0 days late.

  4. Using SysDate from Part Tran
    a. Packers may be legitimately back dated, or post dated.
    b. Marking a Packer shipped, then unmarking it shipped, then re-marking shipped creates multiple PartTran entries - possibly with different SysDates - for one lone completed shipment.

(Rob Bucek) #10

I see some of your conundrum here. If you have folks gaming the system, and you always will when they know how the game is scored, there are ways you can engineer your process a bit. I’ll still harp about best practice and staying off the parttrran for shipping info, however, you could put a simple BPM in place to update the ShipHead.ShipDate when the status changes to Shipped, or ReadyToInvoice = true. Create two user defined fields, one in the ship head called PackSlipCreated and use a BPM to populate the current date, this will provide you that gap that it was first acted on and subsequently sits on the shelf. If your process normally covers a couple days while they assemble these shipments, it’s good to know when the lines themselves were packed. Enter ActualPackDate on the ShipDtl level and create a BPM(s) to cover the methods you use to add items to a packslip. That should cover you without having to administrate this type of thing and puts real business rules in place that get you the data for the analytics you need to improve your processes. Like the gap between done in mfg and picked/packed in shipping. Just a suggestion.

(Eddie Dawydiuk) #11

We decided to use the partTran table after all, with a script(called via SOAP API) to slice and dice the resulting data for a monthly OTD email report.

I figured this report(BAQ) will only be called once a month at midnight so the added overhead of looking at the partTran table will be negligent. The benefit being we should have more accurate data without having to rely on humans. It’s not necessarily that we’re afraid people will game the system(although we take that away) it’s that people will get busy and forgetful and will forget to update the ShipHead.ShipDate.