This is going to be a long post, and I’m still trying to wrap my head around it all too. So bear with me.
Our shipping/invoicing process has been screwy since I can remember. Our AR person also handles our shipping. We have automated daily reports that are driven by the invoices created the prior day. As an example, we have a daily “Gross Margin” report that generates a list of jobs that were “shipped and invoiced”, and what our profits were on those jobs. This ultimately gives the production team credit towards their quarterly bonus and keep our daily numbers looking good. The problem is, we’re marking jobs as shipped and invoicing them a week or 2 before they even leave our building, so production gets credit for building them that day. The invoices get edited when the product actually ships. This circumvents any visibility in Epicor. I look at an invoice in Epicor, it says it was invoiced a week ago, but the invoice the customer gets has a modified date and might have yesterdays date.
Then our project manager decides to get involved with a third part logistics company who claims they can take over our LTL and collect shipments. Okay, fine. But things are getting marked shipped in Epicor, which Epicor delivers a CSV to said 3PL company, with daily pending “shipments”. They’re not seeing some lines because they’re already “shipped”, or she creates the Pack ID with a set date, does an invoice, but the date she sets isn’t the actual ship date. It’s just a mess, and guess who’s lap it gets dumped in?
I offered a solution, which was changing the way production gets credit. Rather than going off the invoices, let’s go off the order details and the final operation of the jobs. When it’s packaged up and sitting on a pallet, they get credit; regardless if an invoice is created yet or not. This would require a ton of work, as I’d have to recreate most of our automated reports, queries, ect. This would also allow AR and Shipping to use actual dates and not have to worry about “giving production credit”.
Another option I offered was to add custom fields for “Actual Ship Date” and “Actual Invoice Date” inside Customer Shipment Entry and Invoice Entry.
And the 3rd option was to train someone on the production floor on how to use a dashboard that would change flags or dates on the CSV file we send to the 3rd part logistics company.
Anyone else have any ideas, suggestions or hacks to make our lives easier?
that just made me cringe… people gaming the system haha.
For different reasons altogether we’ve found value in adding a couple extra fields in shiphead and shipdtl. Using a simple bpm you can populate a shiphead.created_c (effectively a born on date), and then use a bpm to change the base field to change the shipdate to the the current date when actually shipped (currently epicor defaults it to the date the pack is created, which is plain dumb). We then created a shipdtl.packdate_c at the detail level to track when things were packaged over time as these shipments awaited collection activities etc in order to track our own crazy internal processes that don’t make sense to anyone else. The detail is a simple bpm that plugs in the current date when the line on the shipping detail is created. You can then track pack creation, actual shipdate and trace what and when things got into the shipment.
I know, it’s a complete mess and I’ve tried explaining why modifying PDFs is a horrible, horrible practice.
I see… Hmmm, yes that does make sense. It kind of sounds like what I was thinking in the second solution I proposed. I think between changing how production gets credit, adding a few custom fields in select areas and setting up a BPM or 3, I could probably solve a majority of the issues we face. It’s just going to be a ton of work but job security during this whole COVID crisis is exactly what I need haha.
I would drag accounting in to this, to get their thoughts on recognizing revenue prior to it actually being shipped. If the CFO, doesn’t have concerns about that, then there may be even bigger problems.
And as far as gaming the system goes. It would be quite easy to under issue materials to a job and “ship it”, to cause the GPM to calculate on artificially low costs.
Then after that report with the really nice GPM #'s on it is published, go back and issue the remaining material.
I think you have a point. I should have accounting look into this as well. I think they have an idea, but not sure they know to what extent.
We have had issues with under issuing mats on partial shipments. The first shipment has all the costs assigned to it and comes out looking horrible. The next day, the rest ships, and has zero costs. In the end it evens itself out but those are few and far between. 99% of our jobs are make to order and are shipped in total. We have a BPM in place that will dump all missing material into a job, using an Admin account, once the job is marked as complete, if the job is missing anything. Double edged sword though, if a BoM is wrong or there was an issue in the Quote… We get hit with that and have to correct it, which again is very rare.
If it’s truly done being manufactured, then it’s sitting in a WIP staging area somewhere. If it hasn’t yet, why not make that a warehouse and bin? Then receive the job to stock, so your mfg group gets their credit? It would create an issue of inventory that could be ‘stolen’ to fulfill someone else’s order, though… You could then allocate the inventory to the order in Fulfillment Workbench I believe…
Probably because “build to order” - which I read as “custom built”
Exactly. Putting it into inventory just to turn around and take it back out would be extra work, or clicks, we don’t need and adding to an already chaotic process. It is an idea though. We do have service connect and maybe there’s a way to automate that extra work into something that would work. I don’t know, I haven’t used Service Connect personally so I’m unfamiliar with its capabilities.
The extra clicks for receiving to inventory may not be your biggest obstacle. You can only put parts into inventory if they have a part record, and are Qty Bearing.
Our configurator makes a unique smart part number. But since 99% ships from WIP, there’s no need for a part entry. But that other 1%, is a real PITA.
yeah, super GAAP compliant
An alternative to receiving to Inventory, would be to use when the Job is closed as the indicator that it’s done. No worries about transactions after the fact, as they cannot be added to a closed job.
This is sort of the conclusion that I was heading to.
Change the process in which credit is given. Moving it away from invoicing to the job being done, and adding a few custom fields to invoice entry and customer shipment entry to correct the issue with those processes. Throw in a BPM and viola… hopefully lol. Nothing is ever so straightforward though.
Back with an update, I think I finally have our processes in order. Here’s what I did:
Created 2 custom fields in ShipHead. “Actual Ship Date” and “Pack Location”
Added said fields to Customer Shipment Entry. Created BPM so Actual Ship Date can’t be less than the default ShipDate (which is acting as the pack creation date now)
Modified our Packing Slips and labels to match these changes.
Created an updatable “Dock Management” dashboard that displays a categorized list based on the “Pack Location” field. The dashboard lets shipping change 3 fields, the “Pack Location”, the “Actual Ship Date” and the “Ready To Invoice” (aka shipped) checkbox.
Changed our daily Gross Margin report to go by the Pack Creation date (aka default ShipDate), giving production credit the same day they package product.
Between all these changes, I was able to eliminate the need for AR to invoice against packs made the same day in order for production to get credit and eliminated an “off the grid” dock report that was being handled in Excel.