Project Job versus Job?

What is the difference between a Project Job (A job created inside of a Project) and a Job, like a job generated through a Sales order or Job Entry.

A job from a Sales Order, or directly from the Job Entry window cannot be used in the Project job field, and jobs generated in the Project Job cannot be opened in the standard Job Entry window.

Is there documentation that states the differences in detail so that I can understand it and discuss it intelligently with my team and show why we should or shouldn’t use a project job or visa versa?

We don’t use Project Jobs, but I did dig into it extensively in 2018, so I reviewed my notes from that.

So let’s back up a minute. This is going to seem unrelated.

Scenario 1 (ordinary job) - you make widgets by the thousands and receive them into to stock.

  • Costs get charged to the job (they go into WIP)
  • When the job is done, you do a Job Receipt to Inventory and those costs get received into inventory.
  • Later you sell and invoice the part and costs go to sales

Scenario 2 (ordinary job) - you make parts to order and ship them out (you do not receive them to stock in the interim).

  • Costs get charged to the job (they go into WIP)
  • When the job is done, you do a Customer Shipment (from WIP, not from inventory) and those costs go to cost of sales
  • Then you invoice and costs go to sales

Now your situation or something like it.

Scenario 3 (project job)- you construct huge commercial buildings, so you make a Project Job to accumulate random things (travel expenses, time for your own engineers to work on this)

  • Costs get charged to the job (they go into WIP)
  • And then what?
    • There is no finished product to receive to inventory
    • There is nothing to ship either
    • It might be months or years before the project (small P) is finished
  • In this case you do Project Revenue Recognition which puts costs straight to somewhere; cost of sales, I presume
  • And then you might use milestone billing, for example, to move costs to sales

The point in all of these is the same - you need some mechanism to move costs from WIP to somewhere else - eventually to revenue.

Project jobs give you a different method to do this, one that accountants like for its ability to move on with life on a big project - to move costs even when the job is not complete yet.

Again, though, I am not an expert and that was 4 years ago, so if anyone else wants to chime in and correct me, please do.

Edits:

And we never implemented this. It was way too much of a hassle for us. Not to say it’s a bad idea, but we don’t have massive projects like that, for example.

Oh, and you can tie NON-Project jobs to a Project, too. We do that, for organizing reasons.

[Edited descriptions per later post]

3 Likes

Thanks for this information Jason. This is good information on Project jobs, but doesn’t a Job in Job entry do the same, I mean I would think it needs to.

i agree, it would be a hassle since a Sales Order can create a job, if not, you have to manually create a job under Projects, but… I want to make sure there are no financial issues of course. Would love to get more feedback on this and documentation if it exists on both, I just cant find it.

OK, I guess I failed there in my explanation.

Scenario 1 = Ordinary Job (not project)
Scenario 2 = Ordinary Job (not project)
Scenario 3 = Project Job

1 Like

Thank you, I was a little confused on what the scenarios were, if 1 or 2 also had a project job, though I did know 3 was a project job and yeah, I did know that you can tie a non project job, into a job, making jobs much better as a great way to organize a “Project”.

We do use Milestone billing, or want to at least, so with Milestone billing (which is deferred) is that a better time to use Project Jobs?

Oh that is where I bow out. Hopefully others can speak to that. I have no experience there.

I mean, the other version of this would be what, advance billing, maybe?

Point is, there’s always another way to accomplish the same thing.