KBA-01219: Where does Sub Account info come from for the Commitment Items?


When I add an Item on a Commitment/Subcontract, the Sub Account field automatically populates. But where does this Sub Account come from?


In Microsoft Dynamics SL, the Sub Account is required on the Project Maintenance screen when the project is created.  Subsequently, when Cost Codes (or ‘Task‘ or ‘Phase‘ or whatever name you use) are added, the Sub Account can be assigned at that level.
Microsoft Dynamics SL supports the concept that you assign the Sub Account at the Project level and/or the Task level.  Before assigning a Sub Account, Microsoft Dynamics SL and Spitfire always check at the Task level.  If the Sub Account is there, Spitfire uses it.  If not, Spitfire uses the Sub Account at the Project level.  This allows you to enter the Sub Account once and then only enter at the Task level for the exceptions.
When you create a project in Spitfire, Spitfire does not ask you to enter the Subaccount in the Project Setup document. To update the Project Maintenance record in Dynamics SL, you have two options:
1)    Open the Microsoft Dynamics SL Project Maintenance screen from the Spitfire Project Dashboard and enter the Subaccount.
2)    Enter a default Sub Account in Spitfire’s ProjectConfig rule.  Spitfire will then enter that Sub Account into the Project Maintenance record for you.  This works well if you have a default Sub Account in Microsoft Dynamics SL; if you have unique Sub Accounts for each project, you will need to use option 1.

Additional Comments:

The ProjectConfig | GLSubaccount rule (Rules Maintenance on the System Admin Dashboard) allows you to enter a default Sub Account based on Contract Type. See KBA-01153 for details.

Note: the above applies only to sites that are integrated with Microsoft Dynamics SL.

KBA-01219; Last updated: October 14, 2016 at 9:26 am;
Keywords:  rules, subcontract