Ship Date <> GL Post Date

Kinetic ERP
,
1

We went live with Epicor in May of 2021 so still working out kinks and training. We just came upon an odd thing with the timing of shipping and the related posting to the general ledger:

The shipping documents have a ship date of 8/31/21
The AR invoices have a GL posting date of 8/31/21
The related cost of sales for the items shipped are posting as of 9/1/21.

As a result we have GREAT margins in August and terrible margins in September since the recognition of the costs (standard) are happening in Sept but the Revenue is being recognized in August. What did we do wrong?

Please help. Thank you!

1 Like
2

Are you running Capture COS/WIP on 8/31 or 9/1?

3

We run it nightly and it would have run at 2:00am on 9/1. But wouldn’t the Ship Date drive the post date?

4

Not for COS. It will always post to the current period, so you should do a manual capture at months end, prior to midnight.

5

But only if the prior period was closed, no?

@nanvdand - the invoice date was 8/31, but when was it actually created? And when was it posted?

1 Like
6

Correct.

I also do not recommend leaving capture outdated transactions checked.

@nanvdand you can capture the transactions posted from the wip capture process from the details of the period posting and reverse them.

7

If I’m remembering correctly you CAN set it to the previous period as long it’s not closed, but it will still default to the current period based on the date it’s being run.

Also guessing, like @bderuvo said, they probably have capture outdated transactions checked on the scheduled task.

8

@ckrusen The invoice was created on 8/31 and posted on 8/31.

@bderuvo I think I know how to do a mass reversal, but then how do I get them in the correct period? (in this case, they should be in August) DMT? As a GJ?

@zwilli526 Thanks for the info. This is important stuff and I didn’t test for a month end scenario.

9

I’d have bet dollars to donuts that as long as the period for the apply date is open, the Periodic Posting Process transaction will use the apply date.

The “outdated transactions” option sweeps unposted transactions for closed periods, and creates a GL transaction with a date of the first day of the oldest open period.

Longshot, but maybe when the FP for August was setup, the end date of 8/30 was used instead of 8/31.

10

Pretty sure the outdated transactions applies to any date preceding the begin date in Capture (open or closed)

11

@ckrusen - Based on the BAQs I’m running to research this, I’m finding the same thing - that as long as the period is open, the ship date is used for the GL trans date. But I will continue testing and confirm back. But I do think it makes sense to run Capture manually on the last day of the month just to be safe.

12

I did check the fiscal period dates (good thought) but it’s all good - August ends on Aug 31. Starting to suspect some innocent foul play on the part of the shipping folks - maybe attempting to correct a packing slip?? Will confirm.

13

Run the Inv WIP Recon report twice. Once with the tran date selected, and the other with the system date.

Pretty sure you can’t reopen a Packer once it has been invoiced.

Edit

If you know the JournalNum and Line of the PPP transaction in question, you can run the Inv WIP Recon report for that specific journal number and line, to see the exact transactions that went into that GL tran.

14

Hi Calvin,

I am not 100% on this but I think a correction invoice can re-open a pack. Not sure about month end boundaries though.

15

I might be confusing the Packer/AR Invoice locking with Receipt/AP Invoice. But it would make sense that a packer couldn’t be altered after an invoice was applied against it.

And what I meant by “re-opening”, was manually going in and “un-shipping” a packer after it was invoiced.

We used to have lots of problems when Order Entry wouldn’t put the proper ShipTo on the order, then when the packer was invoiced, the proper taxes wouldn’t be applied. Most of all our product would be shipped by truck/common carrier, so the address on the packer was summarily ignored.

16

Going back to the original problem …

edit

The following is probably not true (or not entirely true) if you use STD costing.
(end edit)

There are many other transactions that happen between issuing parts from Inventory to WIP, through to invoicing the shipment. Here’s a couple of scenarios. None might be what you experienced, but they might give you more insight into the inner working of E10.

Material issued after shipment - If no material was issued to the job prior to shipment, then the cost for that job would be zero when it shipped. When that shipment is invoiced, the COGS for it would be zero. When the material is eventially issued, those costs are no win WIP, and will stay there until the Job is closed. When the job is closed with costs still in WIP, a variance is created. This variance will be turned into a PPP GL tran when Capture COS/WIP is run.

You use average costing, and ship part of a job without reporting qty - If a job is for 10 pieces, and you ship 5 from it they there will be no cost associated with those 5. It is only after the last of the production qty is shipped (or rcv’d to stock), that the costs in WIP will be become costs for the shipment (or inventory). At that point, the entire cost in WIP is applied to whatever qty the final shipment (or rcpt to stock). For example:

  • A job has material costs of $100 each, and is for 10 pieces.
  • You issue all materials to the job - WIP now has $1,000 in it.
  • You ship 8 from the job. The cost used is zero. WIP still has $1,000 in it.
  • You invoice that shipment, and a zero COGS is used.
  • You ship the final 2, and all $1,000 is used to determine the average cost of $500 each. Since you’re shipping 2 at $500, WIP is reduced by $1,000
  • You invoice these final 2, and the $500 each is used for COGS.

At the end of the day it still cost $1,000 of material to make all 10 of those. But the first 8 had in credible margins (due to the zero cost), while the final 2 look like they lost money with the material costs being 5X normal.

A back dated transaction - A packer is created on 8/31, but not marked as shipped until the next day - say 9/3 (after a weekend). If the period for 8/31 is still open, running the Capture COS/WIP will create a PPP GL tran with a date of 8/31 to include that shipment. If the FP for 8/31 was closed before running the Capture on 9/3 (and the outdated trans option was enabled), then the PPP GL tran will be dated 9/1 (the first day of the oldest open FP - which happens to be the current FP).

Backdated receipts can really throw you off if your not careful. WIp Recon and SSR would reflect the item being received and in stock on the receipt date, while the GL may reflect it as being on the “outdated capture date”.

This can appear to happen when making an adjustment to packers or receipts. Because Part Tran records can never be deleted, “un-shipping” or “un receiving” creates PartTran records of the same type as the original shipment (or receipt) but with an opposite tran qty. So marking a shipment as shipped, then re-opening it, makes two parttran records of equal and opposite value. Then re-shipping it, makes a third parttran record using whatever the value is. These will all have the same tran date (assuming the ship date on the packer wasn’t changed), but can happen on different dates (sys date), and in different FP’s.

2 Likes
17

This bit of info is extremely helpful because I am seeing several customer shipments that have three records for the same line - one create, one negative, then a new create. There’s something to this that begs further exploring. It also looks the maybe the AR invoices were modified - which perhaps allowed the Pack to reopen but did not reverse the GL post date of the original Invoice date. Will test theory in Pilot.

18

I’m pretty confident that a posted AR invoice cannot be changed. New Invoices (CM or a Cancellation invoice) can be created against the initial invoice. Those would “reverse” the GL Trans when they are posted. This would be akin to making a packer shipped, then un-shipped. But with the packer all the trans will have the same PackNum. With the Invoices, the CM will have a different InvoiceNum than the original invoice. Not sure if Cancellation invoices require a new invoice num, or just re-use the original.

The built-in Trackers can be helpful. Use the Customer Shipment Tracker, to see all the invoices created against that packer number. Ideally it would be just one.

19

You are correct; only one invoice from one shipment. All good there. Just got of the phone with our controller and I learned that on Sept 1, they recorded a bunch of shipments but dated the ship date as Aug 31 (because that is when they were physically shipped). The Controller then invoiced as of Aug 31. This seemed to cause the Revenue to be recorded in August but the Cost of Sales (we are Standard) in September. Based on all the info you have given me, we need to make sure shipments/packs are created in the period they occurred. Otherwise we end up with mismatched revenue and costs.
Does this all sound correct?

20

We never used STD costing, just AVG and LAST. But unless it is something special about STD costing, creating a shipment on 9/1 with a ship date of 8/31 should create a part transactions with a tran date of 8/31 and a sys date of 9/1. As long as the FP for 8/31 is open doing the Capture COS on 9/1 (or any date prior to closing the FP for 8/31), will create a PPP GL tran with a date of 8/31. Same thing goes for creating the invoice on 9/1 with an invoice date (aka Apply Date) of 8/31.

One more thing that might come into play. Do you use an Accrual Account? We do, so the costs flow like:
Issue Mtl: Inv (1151-00-01) → WIP (1152-00-01)
Ship from Mfg: WIP (1152-00-01) → Accural Acct (2257-00-01)
Invoice Shipment: Accrual Acct (2257-00-01) → COGS (6201-00-01)*
*(actual account is based on the ProdGroup GLC)