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?
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.
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.
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?
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.
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)…?
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.
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.
Do early shipments count as negative days late? Or are they capped at 0 days late.
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.
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.
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.
We’ve been using this new BAQ for the past couple months for calculating OTD. Specifically we’re using the part transaction table sys date to know the actual ship date. Our OTD is much lower than we thought, and in reviewing the data we’ve got a few dates that don’t seem to make sense…
I’ve got two jobs with a single shipment on each job(Job Tracker->Shipments->Retrieve), when we look at the corresponding sysdate in the part transaction table(only one entry) the date listed is afer UPS tells us the package was received by the customer. Here is another really strange datapoint, my username is listed as the user on one of these jobs in the part transaction table. I most definitely don’t do shipping… On the other job the username does correspond to the person that handles shipping.
Can anyone help, we seem to have some strange data. BTW we’re using Epicor 9.05.605(in the process of migrating to E10).
I feel terrible for releasing a report that indicated production is doing a bad job of delivering on time and then come to find out the data is questionable…
As others said, the ship date on the packslip can be modified. It is initially defaulted to “today” but that is when they CREATE the packslip, not when they ship it. So they could create it today, but ship 5 days later.
Parttran date would be the date that they actually check the “shipped” box. I know of some companies that do this the day after it ships. Some do it the moment the box is closed, and others do it when the trucker takes possession of the package (most correct in my opinion).
So this is all about the timing. When did you ACTUALLY ship it vs when did they create the pack and when did it get marked as shipped.
@timshuwy I’m being told the date the “shipped” box was checked was days before what is showing up in Parttran. Also, on one of the Parttran records my name is on the record and I most definitely never clicked the “shipped” box.
I guess at this point I need to reach out to tech support as I’m being given bad information or there is a bug in 9.05.605.
I’m pretty sure the ship date on the packer is the date used when it is marked as shipped.
If you create a packer with a ship date of 4/8, but don’t mark it as shipped until 4/10, the PartTran record will have a trandate of 4/8 and a sysdate of 4/10.
Calvin is correct and just to add PartTran.TranDate is equal to ShipHead.ShipDate. I’m on Epicor 9.05.702a.
So, if you are using PartTran.SysDate_ you are simply going by when they “TOLD” the system they shipped it, ignoring the fact they may or may not have manipulated the ship date.
It sounds like generally speaking that when there is a difference in shipped vs actually shipped that they are not manipulating the date but just physically shipping at a later date, a date not currently being captured with the current SOP.
Just a suggestion, but is it possible that the Invoice date would be more accurate provided you invoice anything that “physically” shipped during the day by end of business? I know that is our procedure. We allow ship date manipulation only when shipping is going to happen over the weekend or at some future date. This is so invoicing can be done early and invoice per our SOP’s apply date is set to same date as shipped.
There can be more than one STK-CUS or MFG-CUS per item per shipment - if it is “unSHIPPED” (changing the status of a Packer that was previously shipped to not shipped).
For example
On 4/5 a packer is created with a Ship Date of 4/5, but not yet marked shipped.
On 4/6 the packer is marked SHIPPED. PartTran records will be created (STK-CUS, MFG-CUS, etc…) for the part’s qtys. TranDate = 4/5, SysDate = 4/6
On 4/7 AR Invoicing can’t invoice because the ShipTo was incomplete. To fix it, the Packer must be marked unshipped first. This makes a PartTran records similar to step 2, but with negative qty’s. TranDate = 4/5, SysDate = 4/7
on 4/8 the ShipTo is corrected, and the packer is re-marked as SHIPPED. PartTran records will be created. TranDate = 4/5, SysDate = 4/8
That gives you 3 PartTran records, with multiple dates to chose from. One thing to notice, is that the ShipDate of the PartTran always matches the ShipHead.ShipDate. So just use the ShipHead.ShipDate.
Just remember that there are a lot of reports, dashboards, etc uses ShipHead.ShipDate. It is a good thing to keep these in sync. Write a BPM when the shipped button is checked to use today’s date for Ship Date. You don’t want users seeing one date of the On Time Delivery and see something different in the system.
It turned out I had a hole in my understanding… You can ship a package out without clicking the shipped checkbox, there is nothing stopping you. So it turned out the person responsible sometimes forgets to clicked shipped, then remembers a couple days late and clicks shipped. This could result in a package being delivered(via tracking information) before it shipped(date shipped checkbox was checked).