Acumatica Project Task Screen — A Deep Dive

The Project Task screen (PM302000) is where a Project (PM301000) gets broken into the units that actually absorb time, cost, and revenue. A project without tasks can't accept transactions in most configurations — every timecard line, AP bill, and inventory issue posted against a project needs a Task ID, so this screen is the connective tissue between the high-level project record and the detail that flows into it from every other module.

What lives on a task

The DAC behind the screen is PMTask, and it carries its own budget, its own billing rule (which can differ from the parent project's default), a start/end date pair, and a status independent of the project's status. A task can be marked Completed while its parent project stays Active, which is the normal way to close out a phase without closing the whole engagement. The Summary tab shows actual vs. budgeted amounts per cost code; the Budget tab is where those budget lines actually live, joined against PMCostBudget.

Task types, and why they matter

A task's Type field (Regular, Summary, or Milestone-adjacent depending on version) controls what can post against it. Summary tasks exist purely to roll up child tasks in reporting and normally can't receive direct transactions — a customization that lets someone post a timecard against a Summary task is usually a bug, not a feature, and worth guarding against in a RowPersisting handler if the base validation doesn't already catch it for your task hierarchy.

The billing rule override, and how it interacts with Progress Billing

Each task can carry its own billing rule, which lets one project mix Time and Material tasks with Fixed Price tasks under a single project header — common in fixed-fee-plus-expenses engagements. When you extend the Project Billing screen or write a custom billing engine, this per-task override is the field people forget to check: code that reads the project-level billing rule and ignores PMTask.BillingRule will bill every task the same way, which is wrong the moment a project has mixed task types.

Common customization points

The most frequent request on this screen is a custom field capturing something task-specific — an external work-order number, a department code, an approval flag — added via the Customization Project Editor as a new DAC extension on PMTask with a UI field placed on a custom tab. Because PMTask is referenced from timecards, AP bills, and inventory issues, a new required field here has a wider blast radius than it looks: every entry screen that lets a user select a task will need to either populate it automatically or expose it, or those saves will start failing validation.

A second common pattern is a graph extension on ProjectTaskEntry adding a RowUpdating or FieldUpdated handler that prevents a task's dates from falling outside its parent project's date range — base Acumatica doesn't enforce this relationship tightly by default, and finance teams often want it enforced.

A gotcha with completed tasks and open transactions

Marking a task Completed doesn't retroactively block transactions that were already in flight — a PO line item or timecard entered before the status change can still post against a completed task unless you add explicit validation. Teams that rely on task status as a hard billing gate are often surprised the first time an AP bill lands against a task everyone thought was closed. If that matters for your business process, it needs an explicit check in a graph extension, not an assumption based on the status field alone.

Wrapping up

Project Task is a small screen with an outsized footprint: nearly every module that touches Projects joins against PMTask somewhere, so changes here — new required fields, tightened validation, altered billing behavior — ripple further than the screen's own simplicity suggests. Map out which entry screens reference the task before adding constraints, and you'll avoid the class of bug where a validation rule added for one workflow quietly breaks timecard entry for everyone else.