Information about Expense Categories in Project Accounting and Travel & Expense

Expense Categories can be created in the Project Accounting Module as well as the Travel & Expense Module. So the whole procedure is as follows:

1. First you create a Shared Category and specify whether this category should be available in either Projects and/or Expenses and/or Production.
2. Then you create a Category Group and specify the ledger accounts for the Project Cost and Revenue.
3. Then you create a Project Category and associate the category created in step 1 to the Category Group created in step 2. (Only if the "Can be used in Projects" checkbox is checked)

Project Expenses can be booked via two methods, namely:

• From the Expense Journal in the AX client
• From the Expense Report in Enterprise Portal (This will be Expenses submitted by the employees)

The default accounts that come into play during both these methods is what one needs to be aware of.

Expense Journal from AX client

If the user is posting an expense journal from the AX client (from the Project), then the DEBIT account is defaulted from the ledger account setup done in the "Cost" field of the "Cost Accounts" section either at the Category Level OR Category Group Level. If different ledger accounts are defined at both the category as well as the category group, then the system will always follow the ledger account defined at the least level .i.e Table .i.e category in this case.

The CREDIT account can either be selected manually (which is mostly Vendor) or can be defaulted by defining the appropriate offset account at "Default Offset Account for Expenses" under Posting sub-section in the Setup section of Project Accounting.

Expense Journal from Enterprise Portal

If the user is posting the Expense Report from the Enterprise Portal for solely Expense category (which is not a project expense), then the DEBIT account is defaulted from the "Main Account" field in the Expense fast tab of the Category record. If the expense is project related, then the DEBIT account is governed by the ledger account setup done in the "Cost" field of the "Cost Accounts" section either at the Category Level OR Category Group Level and NOT from the DEBIT account is defaulted from the "Main Account" field in the Expense fast tab of the Category record .

The CREDIT account  is either manually filled in or is defaulted from the "Default Payment Method" (Offset Account field) defined in the Expense fast tab of the Category record.

However when the employee enters the expense report and posts it from the Enterprise Portal, it lands up as a General Journal in the AX client. If the Offset Account is not defined in the "Default Payment Method", then before posting the Expense Journal in AX, the user has to manually key it in.

Hence the entire determination of the DEBIT and CREDIT accounts for the Expense line is determined whether it is a Project Expense or a non-project Expense. If it is a project expense, then DEBIT account is from the Category/Category Group and if it is a non-project (pure expense), then DEBIT account is from the Main Account field.

I found this quite confusing while posting expenses in my VPC, hence thought of noting it down somewhere.

Hope this was helpful for you as well...

Thanks!

AXAPTAMANIAC




 

Essentials to start posting trasnactions in new legal entity in AX 2012

Following are some of the bare minimum configurations to be in place, in the new legal entity, so as to start posting the transactions.

1. Legal entity creation
2. Number Sequences (either wizard or manual)
3. Chart of Accounts
4. Creation of Accounting Structure
5. Fiscal Calendar
6. Currency and Exchange Rate Setup
7. Configuration of Ledger:
            o Chart of Accounts
            o Accounting Structure  
            o Selection of Fiscal Calendar
            o Selection of Accounting and Reporting Currency  
            o Selection of Exchange Rate Type
            o Defining the Realized and Unrealized Forex Gain / Loss accounts (if applicable)
8. Dimensions and Dimension Values
9. Journal Names, mandatory of them are as follows:
            o General Journal (GENJ)
            o Vendor Invoice (VINV)
            o Vendor Payment (VPAY)
            o Customer Payment (CPAY)
            o Write-Off (WRFJ)
10. Vendor and Customer Group
11. Vendor and Customer Master
12. Vendor and Customer Posting Profile
13. Bank Account Information
14. Bank Transaction Types
15. Terms of Payment
16. Methods of Payment
17. Date Interval
18. General Ledger Parameters
19. Accounts Payable Parameters
20. Accounts Receivable Parameters
21. Bank Parameters
22. Reason Codes
23. Aging Period Definition
24. Users creation
25. Employee Creation
26. Define Security Roles / Edit existing roles
27. Assigning the Security Roles to the Users
28. Associating the Users with the Employees
29. Form Setup
30. Form Notes
31. Configuring the System Accounts (Penny Difference, Error Account, Year End Balance etc.)
32. Workflows, if applicable

I think if all the above are in place then a user should not find any problem posting entries into a newly created entity.

Thanks!

AXAPTAMANIAC
 

Year End Close in AX 2012

While waiting at the KL airport for my flight to Mumbai, I tested the functionality of Year End Close on my VPC with various scenarios and situations. Here are the findings:

• If the Voucher number is given at the time of processing the year end close, the same voucher number will be used for Closing and Opening transactions.
• If you wish to run the year end close again and if you give the same voucher number, then the system complains and asks for new voucher.
• If you give the new voucher number and the 'DELETE CLOSE OF YEAR TRANSACTIONS DURING TRANSAFER' is checked in GL parameters, and after that you run the process as discussed in the step above, then the system deletes the opening and closing transactions generated as a result of previous closing exercise and then creates new transactions for this run.
• Significance of 'DELETE CLOSE OF YEAR TRANSACTIONS DURING TRANSAFER' as mentioned in AX training books is as follows: Delete Close of Year Transactions during transfer check box to delete open transactions and system-generated closing transactions when a transfer is repeated. This can process the transfer multiple times if it is necessary but only creates one opening entry. If it is clear, the previous transfers are not deleted. Instead, the system transfers the net adjustments compared to the last time that a Transfer is performed. This allows for the tracking of historical transfers, but many transactions are created.
• If you wish to reverse the year end close transactions, then run the process again with a new voucher number and by selecting 'RESET'.
• After RESET, the previous transactions related to year end will be deleted. The Close-of-year transactions Report will be empty.
• Once the transactions are reversed, you can run again the Year End Close for the same year with the same voucher number.
• If 'CREATE CLOSING TRANSCTIONS DURING TRANSFER' is unchecked, closing transactions are not printed in the Close-of-year transactions.
• Significance of ''CREATE CLOSING TRANSCTIONS DURING TRANSFER' as mentioned in the AX training books is as follows: Create closing transactions during transfer check box to create closing transactions for all the ledger accounts, including the profit and loss accounts, when running the opening transactions job. This does not mean that it transfers profit and loss balances but it creates closing transactions only.
• If 'VOUCHER NUMBER MUST BE FILLED IN' is not selected in GL parameters and voucher number is not entered while running the year end close, then the transactions are created without the voucher number and Voucher Number field is empty when the Close-of-year transactions is printed.
• Significance of 'VOUCHER NUMBER MUST BE FILLED IN' a mentioned in the AX training books is as follows: Voucher number must be filled in check box to enter a voucher number when opening transactions are created for a new Fiscal year.
• Suppose you have to run the year end close procedure for many years and if you decide to run the year end closing randomly (.i.e. closing 2012 first and then 2011), then the system allows it and will not complain, but figures generated out of it will be completely wrong. This was just tried as part of negative testing. In a real world no one will close the years randomly.
• Also if you try to run the year end process for the year where there are no transactions, the Close-of-year transactions report is empty, but the system still gives the message: 'The transactions for the fiscal year 20??-20** have been created'.
• The End Date should be the last day of the Fiscal Year. (.i.e. 31/12/2013) and the Period Name (which is system generated) should be Period 13. (The closing period).
• 'SET THE FISCALYEAR STATUS TO CLOSED' if checked in the GL Parameters, system ensures whether all the prior periods are closed (HARD CLOSED) or not. If they are closed then it allows the system to close the year and if they are not closed, then system complains and displays the message, 'Fiscal Year that ends with date 31/12/20?? is not closed'. Period 13 (Closing Period) must also be CLOSED.
• If the system has run the Year End Close process with the setting as mentioned in the step above, then system CANNOT Reset the transactions. If you try to do so, then the system displays the message, 'Fiscal Year that ends with date 31/12/20?? is already closed'.
• Opening period (Period 0) of any Fiscal Year is always CLOSED by default and only system is allowed to post in that period. Transactions posted in Period 0 are of type Opening.
• Closing Period (Period 13) of any Fiscal Year is always ON HOLD and should be changed to OPEN while posting the Closing Sheet. After the Closing Sheet is posted, the user should put the Closing Period status back to ON HOLD without fail. Transactions posted in Period 13 are of type Closing.
• Transactions posted in Periods from 1-12 are of type Operating. (Somewhat off topic, but the reason for mentioning about Opening, Operating and Closing is that while configuring the reports in MR, when we specify YTD, it means Opening + Operating AND when we specify YTD/BB, then system looks at only Opening.)
• Even if the Closing Period is ON HOLD, then also the while running the Year End Close (Opening Transactions), its not necessary to change it back to OPEN. System posts the closing transactions in that period even if it is ON HOLD.
• If there are certain open transactions that are still not posted and if you are running the Year End Close for that year then the system displays the message: 'The Journal ****-!!!!!(Daily) contains not posted transactions with a date before end of fiscal year 31/12/20??'. In such a scenario, either post the transaction or delete the transactions and try the year end close procedure again.

Thanks!

AXAPTAMANIAC
 

Somethings that i should remember always...

This list will be updated periodically based on the learning on the day to day basis.

• Purchase Pools are configured in Procurement and Sourcing section in Setup > Purchase Orders > Purchase Pools 
• Buyer Groups are configured in Inventory and Warehouse Management section in Setup >  Inventory > Buyer Groups 
• Migration Control account is used for Sub-Ledgers only. 
• Debit Note is given by us to the Vendor. (i.e. we are asking the Vendor to pay us back)
• Credit Note is given by us to the Customer.(i.e. we are paying the Customer back) 
• Ledger Account selection in the Bank Transaction Types is for the system to suggest the appropriate ledger account code based on the selection of the Bank Transaction Type, while creating a new transaction during the Bank Reconciliation process.This is just a system recommendation, which can be overridden by the user. But for posting corrections during Bank reconciliation process, this is most useful, as users are not allowed to select the account when corrections are posted. The user has to just select the Bank Transaction Type and the system determines the appropriate account (ledger code) based on the selected Bank Transaction Type.
• Initialize Balance and Update Balance buttons in the Financial Dimension Sets (GL > Setup > Financial Dimension > Financial Dimension Sets) are used to initialize the balances once the migration data is loaded. If this is not done, then Ledger Account in COA will NOT display any balance, even after the presence of the transactional data in the system.
• While defining the Ageing Period Definition, if the user clicks on the + (green) icon, system will only allow to create the negative values but not positive ones. If the user wishes to enter the positive values, then just create the new line by using the downward arrow key and then enter the values.
• Journal can be printed from the Journal Voucher form by selecting the Print Journal option. However most of the times the requirement is to print the journal all at ones. Then the user can do so from the Journal Header. Also one other type of requirement is to print the journals which are not yet posted. Dynamics AX has inbuilt report for this kind of requirement. The report is: General Journal entries that have not been posted. Proper queries are to be created in the query window to get the desired result.
• Document Date, Due date and Transaction Date: Document Date is the date of the document. For e.g. you have received a invoice from the vendor, having a certain date on it. That is called a document date. If AX registers this invoice at a later date in the system, at that time the Document date will be different from the Transaction date. Transaction Date is the date when the transaction is posted in the system. Due date is the Document Date +Terms of payment OR Transaction Date + Terms of Payment (if the document date is not specified). For the Terms of Payment to work properly, Invoice Number should be specified in the journal line.
• Aging Report and Customer & Vendor statement can be created for all the dates namely, Document Date, Transaction Date and Due Date.
• Write Off journal can be created from the Collection screen. This journal is a daily type of journal and cannot be directly created from the General Ledger > Journals. Setup that is required for the Write-off journal is to create the write off journal in Journals. Then define that journal in the Parameters section along with the reason code. Finally define the account code for Write Off (Bad Debts write Off, expense account) in the Posting Profile.
• Write-off journal can be created by clicking the Write-off icon in the ribbon. If the icon is clicked from the Collections screen, the entire outstanding amount is selected for the journal that is created. If the icon is clicked from the individual customer line, then the user has the ability to select the amount that needs to be written off. Once the journal is created, system displays the message.
• The Cheque can be Deleted, Void and Cancelled. Only cheques with status = CREATED can be Deleted. When the cheque payment is Rejected from the payment journal, then the cheque status changes to VOIDED. You can reverse only posted cheques that have a status of PAID. You can only void un-posted cheques When the payment / cheque is reversed, the status of the cheque changes to CANCELED.
• Security Administrator role should be assigned to the user for him/her to access Management Reporter.
• Treasurer role is used for allowing the user to Reprint the Payment Advice from Bank Module and also Cheque Generation. This role should be assigned to all the users generally in the AR and AP function.
• While creating Currency, if the Currency Code is not present in AX, then create it with 999 - Unknown Currency Code.
• For all the print outs that can be obtained from the system, like Free Text Invoice, Sales Invoice, Packing Slip, user can have specific information printed on it. This can be configured from Form Notes. Similarly Form Setup allows you to select whether the paper that is used should be Printed or Pre-Printed.
• Approval Checkbox should be clicked in the AP invoice journal or else the journal will be posted but the transaction will NOT appear in the Settle Open Transactions form. If by mistake this has happened, then this can be rectified by going into the Vendor Transactions form and clicking the Approved checkbox. After this the transactions will start appearing in the Settle Open Transactions form.
• Forced Rate checkbox should be checked if you wish to apply the different exchange rate than what the system is suggesting as per the setup. If the Forced Rate checkbox is NOT checked and the new exchange rate is entered, system will still consider the exchange rate that is configured in the exchange rate setup and NOT the ones that you have given. This means that Forced Rate checkbox should be checked for the spot exchange rate to affect.
• Reconcile checkbox while reversing the check : Cheque with the sent status does not appear in the Bank Reconciliation. If the reconcile checkbox is NOT checked while reversing the payment, then a NEGATIVE line for a cheque will appear in the Ban Reconciliation along with the original entry. If the Reconcile checkbox is checked, the transactions does not appear in the Bank Reconciliation.
• Free Text Invoice Number is generated after the invoice is posted.
• Payment Advice will always have a transaction date, even if the document date is given.
• AX Auto Report can be generated from any form by navigating to File > Print > Print. This will open the AX Auto report and user can then define the criteria as per his requirements.

Thanks!

AXAPTAMANIAC
 

Method of Payment and Payment Proposal Linkage

While defining the Method of Payment in AX, I was wondering where does the value in the field (dropdown / pick-list, to be more precise) PERIOD affects the whole system. The values in the drop down are; Invoice, Date, Week and Total. This question was obvious because while creating and posting the payment journal, I couldn't figure out where these values are impacting. However later when I used the Payment Proposal for generating the payment lines in the payment proposal, I noticed the difference. We will consider the payment method as Check, for this particular post so as to detail this entire concept out.

For Period = Invoice, when I created a Payment Proposal, the Payment Proposal Lines are displayed in the bottom half of the form and the related open invoices are displayed in the top half of the form. When the Period = Invoice was selected, the system generated one payment line for each open invoice. When I clicked Transfer, one line per invoice was created in the journal. This is simple isn't it...!

For Period = Date, when I created a Payment Proposal, the system generated one payment line combining all the invoices having same Method of Payment, that had due date prior to the date (including today) when the payment proposal is created .i.e. today OR date specified in the MINIMUM DATE field PLUS each payment line for the invoices (or combination of the invoices if the future due date for the invoices is same) having same Method of Payment, that had due date after today OR date specified in the MINIMUM DATE.

For Period = Total, when I created a Payment Proposal, the system generated one payment line for all the invoices per Method of Payment (that were due previous to today OR date specified in the MINIMUM DATE PLUS invoices that were due later to today OR date specified in the MINIMUM DATE, both) for the date selected in the Total Payment Date .

Suppose the user selected date in the Total Payment Date field is less than the date selected in the Minimum date field, then the payment lines are generated based on the Minimum Date. And if the user selected date in the Total Payment Date field is more than the date selected in the Minimum date field, then the payment lines are generated based on the Total Payment date. But in any case payment lines will not be generated for the date less than today. And top of it, once the lines are transferred into the payment journal, there you can change the date of posting, which can be a future date as well as previous date. The Total Payment Date field works only when the Period on the Method of Payment is selected as Total.

NOTE: This can be made as complex as possible. By this I mean:

• We can include more than one methods of payment (CHECK and ELECTRONIC) on the same payment proposal having same Period = Invoice, Date, Weekday or Total
• We can include more than one methods of payment (CHECK and ELECTRONIC) on the same payment proposal having different Period = Invoice, Date, Weekday or Total. For CHECK, the Period = Date and ELECTRONIC, the Period = Total.
• We can further complicate by adding more vendors in the query and this can go on and on...

For Period = Weekday, when I created a Payment Proposal, the system generated payment lines based on the day selected in the Weekday drop down of the payment proposal screen. If no day is selected, then by default Monday is taken by the system to generate the transactions. The system adjusts the distribution of the payments such that most the of payment lines will have payment day as Monday (if Monday is selected as the value in Weekday), which however could be changed once the lines are transferred to the journal. One more thing while playing around with this option, every time I generated the payment proposal, I used to get this warning message, which after 100 trials, I could not get rid of :-(.The warning message was : "Payment date is suggested to 8/17/2013 as Monday 8/12/2013 is after due date." And above all this was appearing for all the days selected. By far I haven't seen anybody using this value in the Method of Payment, so chill.

This was about the actual implication of the values selected in the Method of Payment for Period attribute. But please do not stress yourselves (like the way I stressed myself :-)), as mostly the Period for all the Method of Payments is Invoice only.

Now something more about the Payment Proposal screen, that I came to know while doing all this testing.

Amount Limit : If you define the Amount Limit, the Payment lines will be generated within that amount limit.

Transaction Limit: If you define the Transaction Limit, then only those number of Payment Lines will be created, based on the data.

If you try to define both (Amount Limit and Transaction Limit) then, system gives following error:
Do not use both max amount and max number of lines.

Payment Date : Transactions that fall within that range will only be included in the proposal.

Total Payment Date and Weekday only are used and useful when the Period in Method of Payment is Total and Week respectively.

Minimum Date : This is by default the date when the user opens the payment proposal screen. This can be changed to the future date and the payment lines are then created as per that date. However if the date prior to today is given, the system still takes today's date for the creation of payment lines. More details on this is mentioned in the paragraph for Period = Total.

Once the payment lines are generated and if those contain lines with multiple Methods of Payment, then system warns you based on the setting done in the parameters section. If the payment lines have a combination of CHECK and ELECTRONIC and if the user clicks Generate Payment, then the system generates checks for the lines where Method of Payment = Check, changes it status to SENT. The line with Method of Payment = Electronic are remains unaffected during this process. Once the payment is generated for CHECK, then the user can click the post button to post the payment journal and the journal lines with both the Method of Payments is posted.

Thanks!

AXAPTAMANIAC
 

Mark Check Interval in Bank Reconciliation

While going through the Bank Reconciliation process in Dynamics AX, I came across "Mark Check Interval" button. I clicked on the same and I was asked to provide the interval for the Check numbers.
I did so and clicked ok, however couldn't really make out what happened.

Then I used the "Show Transactions" drop down for my assistance and I quickly understood what happened. If the transactions would have been less, then I would have immediately understood the functionality, but because the transactions were more I had to use the drop down.

Generally checks in the bank check book are sequential in nature. By this I mean if the first check in the series is 000111, then the next would be 000112, 000113...000120 etc. If you have issued checks to your suppliers and if they have been presented in the bank and honoured, then they will definitely appear on the bank statement. Now there may me tens and hundreds of checks issued and it may be difficult and frustrating to mark them one by one, while reconciliation. To avoid this pain, Dynamics AX has given this functionality where you can specify a range of checks that needs to be marked for reconciliation. And once clicked ok, all the checks in that range will be marked automatically.

Please have a look at the screenshots as picture speaks a thousand words...!

Notice that currently one transaction is marked as reconciled, after i have selected Show Transactions = Reconciled

 

I click on the Mark Check Interval and specify the range of the check numbers to be automatically marked for reconciliation.



 

After i click ok, the checks which fall in that range are automatically marked for reconciliation.

 

Hope this was helpful.

 

Thanks!

 

AXAPTAMANIAC

 

 

General Journal : Some interesting facts about Delete Lines and Lines Limit

Delete Lines after posting : If clicked, then the journal lines are deleted the moment the journal is posted. The journal header still exists in the journal list if the user selects Show : ALL, however if clicked on the Lines button for that journal, then system displays an empty journal without lines.
Such journals will NOT be visible if user selects Show: POSTED, even if the journal is posted.

Lines Limit: This refers to the number of vouchers and NOT physical lines in the journal. For example, if a journal has lines limit of 2 and if the user multiline journal (one debit and several credit lines to balance it). In that case as long as the journal voucher balances, that whole voucher will be considered as one line. Now suppose the user enters two more single line offset vouchers apart from the one multiline discussed above. If the user now tries to post it, AX allows the posting, but because of the lines limit, ONLY 2 lines are posted for that journal and the remaining one line is poste in another journal. The infolog displayed after the posting, gives this message to the user.

Interesting thing to note here is that the next journal that is created for that one line also has a lines limit of 2. So to test this I created one more journal with lines limit of 2 and created 5 lines (vouchers, mix of single line and multiline). This time after posting I got an infolog saying that the 2 lines are posted in the current journal, while the next two lines are posted in the next sequential journal and the remaining one line is posted in yet another sequential journal. This was an interesting yet un-important fact to know...!

Thanks!

AXAPTAMANIAC