Wednesday, March 9, 2016

Posting Cost from Balance sheet to Profit & Loss in a project


There are three ways in which a cost posted to WIP account (Balance sheet) can be posted MANUALLY to actual Cost / Expense account (Profit & Loss). The three ways are as below:

1. Post Cost routine (Realization of cost)


  • Project expenses in the project group are set to post to 'Balance sheet'
  • Line property where 
    • 'Accrue Revenue' is unchecked and 
    • 'Capitalize cost' is checked

When the project expense of, say Travel, is posted for GBP 100, then the following transaction is posted to GL:


When the 'Post cost' routine is run manually and posted, the following transaction is posted, which clears the WIP and posts the cost to P&L.



2. Changing the Line Property via project adjustment (Write off cost, denied by client to be billed)


  • Project expenses in the project group are set to post to 'Balance sheet'
  • Line property 'Billable' where 
        • 'Chargeable' is checked
      • 'Accrue Revenue' is unchecked and 
      • 'Capitalize cost' is checked
  • New Line property 'Non-billable'
      • 'Chargeable' is unchecked
      • 'Accrue Revenue' is unchecked and 
      • 'Capitalize cost' is unchecked
Normally what would happen is, whenever these costs will be billed to customer, the cost portion will move to P&L (thus clearing the WIP) and there would be a separate entry to account for revenue and receivables.

However it so happened that client has asked us not to bill the expenses as they think they were not incurred for project. In such a case the cost would still need to be booked to the project but not billed to client. This can be achieved by changing the line property of the expense transaction via the project adjustment routine. The moment the line property for the transaction is changed the cost is moved from WIP to P&L and the Line Property is changed to Non-chargeable.

The core reason why the cost is moved from WIP to P&L is because the line property 'Non-billable' says that the cost should NOT be 'Capitalized' ('Capitalize cost' is unchecked).If the 'Non-billable' line property had 'Capitalize cost' also checked, then the transaction would have still have been in WIP account (Balance sheet) but would have been Non-Chargeable.

Hence after the adjustment, the cost still sits with the project (in the Cost of Sale PNL account) but the line property is now changed to  'Non-billable'. So in conclusion, the line property adjustment does two things effectively:


      • Move the cost from WIP to Cost of Sale
      • Change the line property from 'Billable' to  'Non-billable'.
Note - In adjusting the line property from 'Billable' to  'Non-billable', the main important thing is the manner in which the 'Non-billable' line property is setup. The 'Capitalize cost' in it should be unchecked.

3. Moving the project transaction to Internal project via project adjustment (Allocate the cost to internal project from a client project)


  • Project expenses in the project group are set to post to 'Balance sheet'
  • Line property where 
      • 'Accrue Revenue' is unchecked and 
      • 'Capitalize cost' is checked
This adjustment scenario occurs when you post a cost on to the project, which is initially posted to WIP. These costs could then be passed through to the client at the time of billing or could be recognized on to the project as cost of sale. However after you posted the cost on the project, during review of WIP, the project manager realizes that the cost are neither pass through nor are they related to the project to which they are posted. Hence he needs to move these costs to the internal project. For this the project manager then uses the project adjustment feature to move the cost from the client project to internal project. The accounting effect is still the same as mentioned above, with one difference. The difference is that the cost will be posted to appropriate 'Expense' account and NOT to the 'Cost of Sale' account.

Please refer to the example below:

Project 1




  • Project Group - Time and Materials
  • Ledger posting search priority - Project
  • Post cost (Expenses) - Balance 
Ledger posting setup for Cost is as below. Please refer to the Expense category of Copy.


Ledger posting setup for WIP Cost is as below.



Project 2




  • Project Group - Internal
  • Ledger posting search priority - Category
  • Post cost (Expenses) - Profit and Loss


Expense Journal Posted for Project 1 (where the ledger posting search priority is 'Project')

The postings are as follows:


Debit : 'WIP cost' posting is driven from the 'Ledger posting setup for WIP Cost'.
Credit : Credit posting is driven from the either the Employee vendor / Vendor if employee selected or from the 'Default offset account from expenses' setup.

Moving the project transaction from client project (Project 1) to internal project (Project 2) where the ledger posting search priority for project 2 is 'Category')

To move the transaction from the billable project to an internal project, project adjustment routine is run and the transaction is moved from Project 1 to Project 2. However after posting this, the cost will be posted to actual EXPENSE account and NOT to the COST of SALE account. This is because of the setup in the 'Ledger posting setup' screen for Category 'Copy' (refer to the screen shot above) AND the 'Ledger posting search priority' on the project group of project 2, which is 'Category'. 

The postings are as follows:



Debit : 'Cost expense' posting is driven from the 'Ledger posting setup for Cost'. (As the search direction on the internal project is Category, the actual expense account is selected and not the Cost of sale setup for project group)
Credit : Credit posting is driven by adjustment logic (and NOT by any setup), which reverses the WIP cost posting, as the correct CR posting is already done to the vendor A/P account from the original transaction.

Note - In moving the transaction from TNM to Internal, the main important thing is the 'Ledger posting search priority' (Category) on the Internal project group. If that is also same as the TNM project(.i.e. Project), then the costs will move into PNL upon adjustment but will be moved to Cost of Sale account and not to the actual Expense account (operating expense account).

Conclusion:

The postings in the Project modules are all dependent on following factors which are interlinked:
  • Project group settings:
      • Post costs  Balance sheet / Profit and Loss
      • Accrue revenue check-box
      • Ledger posting search priority
      • Line property search priority
  • Line property settings:
      • Chargeable
      • Accrue Revenue
      • Capitalize cost
  • Ledger posting setup (which works in conjunction with 'Ledger posting search priority')
  • Project / group line properties (which works in conjunction with 'Line property search priority')

Thanks
Sarang

Friday, March 4, 2016

PwP with respect Unit Price, Discount, Charges and VAT


Standard Behavior of Pay-when-Paid WRT to Unit Price, Discount, Charges and VAT

When the PO line has Discount and VAT AND the Project invoice has NO VAT
Supplier Invoice Section
Invoice Amount = Unit Price + /- Discount + VAT +/- Charges

Supplier Invoice Lines Section
Unit Price – Price for the Item / Service
Amount = Unit Price +/- Discount

Customer Invoice
Invoice amount = Invoice Amount = Unit Price + /- Discount + VAT

**There is no way on a project invoice that I can give ‘Charges’ on to it, if the project invoice only comprises of PO**
















When the PO line has Discount and VAT AND the Project invoice has VAT












See the second example below where the ‘Totals’ screen for the Supplier invoice shows all the elements.i.e. Line amount, Discount, Charges, VAT etc.

**Discount is not shown currently in the Totals form as I am accessing it after the invoice is posted. ** Please consider the discount to be 15%





















Related PwP form



This proves that: 

Supplier Invoice Section

Invoice Amount = Unit Price + /- Discount + VAT +/- Charges

Thanks
Sarang

Thursday, March 3, 2016

Effective Labor Rate (ELR)


ELR means Effective Labor Rate.

Consider an example below to understand the concept.

Employee Hourly Rate - GBP 100
Work Week - 5 days (Mon-Fri)
Daily Hours - 8 hours
Weekly Hours - 40 hours

Employee Rate (Without ELR)

A
Employee works for 8 hours, 5 days a week.

Employee Hourly Rate is = GBP 100

This equates to employee cost of = 8*5*100 = GBP 4000

B
Employee works for 8 hours, 3 days a week.

Employee Hourly Rate is = GBP 100

This equates to employee cost of = 8*3*100 = GBP 2400

Rate remains CONSTANT, Employee total cost VARIES based on number of hours worked.



Employee Rate (With ELR)

A
Employee works for 8 hours, 5 days a week.

Employee Hourly Rate / ELR is = GBP 100 (4000 / 40)

This equates to employee cost of = 8*5*100 = GBP 4000


B
Employee works for 8 hours, 3 days a week.

Employee Hourly Rate / ELR is = GBP 166.67 (4000 / 24)

This equates to employee cost of = 8*3*166.67 = GBP 4000

Rate VARIES, Employee total cost remains CONSTANT based on number of hours worked.

Hence the conclusion is, if the ELR is turned on, the Total Cost per week for the employee does not change, no matter whether the employee works one day or one hour in a week. Its the rate of the employee, that changes.

MOST IMPORTANT

>> ELR is looking at the calendar setup at the employee record on the 'Employment tab' and not at any other calendar setup on the employee.

>> ELR check-box on the 'Cost price' table is read-only and can only be checked when it is checked initially on the employee under 'Project setup'. Chronology of events is like this: You first setup ELR for the employee on the employee record under 'Project setup' and then define the rate for that employee in the 'Cost price' table. The moment you create a record in the cost price table and you select the employee for which the ELR is setup, the ELR check-box in the 'Cost price' table for that line is checked automatically.

>> While setting up the 'Working times' for Working time calendar (the ones which is selected on the worker record 'Employment' tab for ELR to work), user should always select the 'Working time template' or else the working times will be created with status 'Closed'.


Thanks
Sarang




Thursday, January 14, 2016

Deliver Remainder and Invoice Remainder on a PO


Deliver Remainder is significant in Two way and Three way matching principles.

Invoice Remainder is significant only in Three way matching.

Example:

Two-way matching:
  1. When the PO with one line and quantity 8 is CONFIRMED, then the Deliver Remainder = 8, Invoice Remainder = 0.
  2. When it is INVOICED, then the Deliver Remainder = 0, Invoice Remainder = 0.
Three-way matching:
  1. When the PO with one line and quantity 8 is CONFIRMED, then the Deliver Remainder = 8, Invoice Remainder = 0.
  2. When it is RECEIPTED, then the Deliver Remainder = 0, Invoice Remainder = 8.
  3. When it is INVOICED, then the Deliver Remainder = 0, Invoice Remainder = 0.
Partial Receipt and Invoicing example for Three way matching:
  1. When the PO with one line and quantity 8 is CONFIRMED, then the Deliver Remainder = 8, Invoice Remainder = 0.
  2. When it is RECEIPTED PARTIALLY for 5, then the Deliver Remainder = 3, Invoice Remainder = 5.
  3. When it is INVOICED PARTIALLY, then the Deliver Remainder = 3, Invoice Remainder = 0.
To conclude:

Deliver Remainder = Quantity - Received
Invoice Remainder = Received - Invoiced



Above example is where the 'Received' quantity is different (more) than the 'Invoiced' quantity. In the example:

Quantity  - 25
Received - 24.40
Invoiced  - 22.86

To cancel the Deliver Remainder and Invoice Remainder in this case, following is to be done:


  1. Use the 'Update remaining quantity' from Update line > Deliver remainder and click the 'Cancel quantity' button. This will cancel Deliver remainder of 0.60.
  2. To cancel the 'Invoice remainder' of 1.54, use the 'Correct' feature. Post the receipt for 22.86. This will clear the 'Invoice remainder'.


Thanks
Sarang


Some facts / observations about Projects...


1. Sales Price and Cost Price setup for a (specific) project does cascade down to the sub-projects, unless separate prices are setup for the sub projects.

2. Project SO can be invoiced to the customer via project invoice proposal, even if the Sales Order is not confirmed. (Create a SO, do not confirm and then run the project invoice proposal [with 'Sales order line' checked and 'Update item quantity' = All] and verify that the sales order line gets picked up in the project invoice proposal, even if it is not 'CONFIRMED'.)

3. Project PO can be invoiced to the customer via project invoice proposal, ONLY if the Purchase Order is invoiced / partially invoiced. If the PO is partially invoiced, then the project invoice will be of the proportionate sales value. If the PO is fully invoiced, then the project invoice will be of the full sales value.

4. Line Property from the Project does get cascaded down to Purchase Order, but it is not cascaded down to the Sales order. This is now corrected in the AX 2012 R3 CU9. [[Some more details on this: Sales Order line has a Line Property field at the table level (not displayed on the front end), but it is not populated at the table level. This was the bug. Because the Line Property field was not populated in the Sales Order line, the back to back PO created on top of it was also not having the Line Property field populated. Ideally the Project Purchase Order should have a line property or else the system complains about the line property missing while confirming the PO. However because the PO was created back to back from the sale order, which did not have line property, the system did not complain. However now this issue is resolved. Even if the Project SO has nothing to do with Line Property, but because the back to back PO created from SO should have it (Line Property), the line property is now being populated at the table level in the Sales Order line table.]]

5. Project invoice proposal, if cancelled, will still be seen in the project invoice proposal list with a status of Cancelled. (However Pending supplier invoice will not be seen in the list if deleted. But will still be maintained in the back end table.)

6. Project adjustment functionality has two main aspects: a. to allow the users to select the new values for the attributes of the transactions to be adjusted. b. to allow the users to select the default values for the attributes of the transactions to be adjusted.

7. The screen that appears after clicking the 'Adjust' button, will give the option for the user to change to 'New' attributes for all the transactions selected for adjustment OR to pull the default values of the attributes from the setup for all the transactions selected for adjustment.

8. Once clicked OK, all the transactions selected for for adjustment will be affected / changed / edited, however they will be displayed individually in the lower pane of the adjustment form based on the transaction selected in the upper pane of the adjustment form.

9. If you click the 'Post' button now, the adjustment will be posted ONLY for the transaction seen in the lower pane of the adjustment form. So if there are three transactions in the adjustment form, you will have to click the post button thrice and not once, as anyone would think.

10. This means that the lower pane of the adjustment pane will always have one transaction in any case, unless it is splitted.

11. Once the transactions are pulled up on the adjustment form and if the user has not done / selected anything on the intermediate form which asks the user to 'Split' or change to new values or select the default values, AND if the user wishes to now change the value of the attribute on the transaction, he can still do so by changing it manually in the lower pane of the adjustment form. After changing all the values, if the user feels like pulling it back from the default values, then user can make use of the 'Update' drop down and select what he wishes to do. The option selected in the 'Update' drop down will pull the default values for the selected attribute for that transaction.

12. The moment the first estimate is posted for either completed contract or completed percentage type of a fixed price project, the project invoice cannot be selected for credit note. If you try to do do, then you get this message: No transactions exist that can be selected for credit note.

13. Purchase order created from Project will have a project id field populated in the Purchase Order line, only if it was selected in the Project Id field in 'General' tab of the 'Create Purchase Order' form. If the project ID is not selected manually there and the PO is created, then there is no way that PO can be linked to the Project.

14. Sales price field in the Project Purchase Order Line is ONLY EDITABLE for the stand alone Project PO. However if the project PO is created as a back to back PO from a Project SO, then the Sales Price field in the Project Purchase Order Line is NOT EDITABLE and ZERO.

15.  If the dimensions are defined on the Customer record, then they are inherited on the Project Contract record. If the Project is created for that Project Contract, then the dimensions on the Project record are taken from the Project Contract record. If the dimensions are NOT defined on the Customer record and are defined on the Project Contract record, then the dimensions on the Project record are still taken from the Project Contract record. 

16. Dimensions are not pulled across from the ‘Project contract’ into the ‘Copy project wizard’. However, when the project is created using a ‘Copy project wizard’ and the dimensions left blank in the wizard, the project record inherits the dimensions from the ‘Project contract’. But if anyone of the dimensions is altered/changed in the ‘Copy project wizard’, then only the changed dimension appears on the final project record.

17. The Line property has Accrue revenue (Checked) and in the project group Post Cost - Expense = P&L, with Accrue revenue (checked), then the postings to
Dr WIP -sale value
   Cr Accrued revenue - sale value
only occurs if the Sales price is mentioned in the expense journal. If it is not mentioned, then this posting mentioned above is not posted.

More to follow on this...

Thanks
Sarang


Tuesday, December 15, 2015

Address and Contact information logic on AR side


Address on the customer record can be of many types. Like Invoice, Delivery, Business etc. These types of addresses are called ‘Purpose’ in AX. There can be separate address for different purpose. Like an address setup for address purpose = Invoice, will be used by default by the system when the invoice is generated. However there can be more than one address types of the same purpose. Hence there can be 2 invoice types of address setup for the customer. How will the system know which one to use?? For this AX provides the option of the setting default. The default address setup against the purpose will be selected.


The delivery address can be changed as system gives the option to change the delivery address. However the system does not give the option to change the invoice address on sales order, as system picks it directly from the setup. The only way to change the address for a customer during invoicing is to go back to the customer record and change the default address for address type invoice. However the invoicing address can be changed on the project contract.




There is another concept of ‘primary’ which becomes the primary address for that customer record. There can be many address per purpose but out of all the addresses defined for that customer, only one can be termed as ‘Primary’ address. This will be available for selection wherever address is editable. Other than that there is no significance of this address.

On the project invoice / customer invoice, the contact information that appears is always the contact information defined on the Legal entity form, Contact fast tab and that too the contact records should be marked as primary or else they will not appear.

Similarly on the sales order invoice / project invoice, the contact id is the one which is selected on the sale order from the contact records set on the customer record.

Thanks
Sarang


Sunday, December 13, 2015

Fixed Asset creation and acquisition


Fixed asset creation (manual or automatic) and acquisition (manual or automatic) has a logic running in the background based on the selections made in the FA parameters and FA section on the PO record. These selections determines whether the FA creation and acquisition should be manual and automatic. This is simplified and presented in the manner which makes it more understandable and all the scenarios are presented at one go.



Thanks
Sarang