Types of Testing for Microsoft Dynamics 365 Finance and Operations Testing types for Microsoft Dynamics 365 Finance and Operations one version D365FO ERP implementation projects require different types of testing during the testing phase of the project. Each type represents a different objective, scope, and depth of testing. Feature testing Feature testing, also known as function testing, is standalone testing of individual features performed by the QA resources or business analysts. Primarily, there are two sets of features to test here: custom features being developed by the project development team to fill the gaps, and standard or ISV solution features being configured by the business analyst. Testing of custom developed features Testing of custom features by the project team involves unit testing, which is standalone testing of code artifacts, and is usually performed by the developers to ensure that individual code elements are working as expected. In software engineering terms, unit testing typically refers to automated testing. It provides many benefits that include finding bugs earlier, providing a safety net of tests for changes that are made later, and improving design. Over the long term, unit testing improves customer satisfaction and developer productivity. Testing of standard and ISV solution features While the development team is doing custom feature development, business analysts are usually busy working on collecting configuration and master data and setting up the standard solution as per the requirements. The second part of feature testing is about testing the standard and ISV product features. This includes configuration such as parameters, reference data, workflows, security, and master data, and then testing transactions such as sales orders, purchase orders, production orders, and journal entries. System integration testing After feature testing, the next part is to test various subprocesses and processes together. By this time, the core configuration is already done, some level of data migration is also done, key custom features are developed, and various systems and solutions are integrated. There are various parts of system integration testing, and they usually get tested in parallel. The following are the testing categories that typically falls under system integration testing. Process/system testing Process or system testing involves testing subprocesses and processes. In this phase, typically all major processes are tested with system configuration and master data. Depending on the implementation scope and requirements, the testing team will test processes such as record to report, order to cash, procure to pay, and plan to produce. The objective of this testing cycle is to identify the correct configuration of parameters, missing master or reference data and any additional bugs or potential gaps. For a simple business process example, consider the testing of the Order-to-Cash process beginning with a single order transacted through its entire cycle. The process starts with creating a sales order, picking and shipping the product, and then invoicing the order. Along the way, the system updates the inventory and accounting. Finally, payment is collected from the customer, the payments are applied, and customer balance is updated within the accounts receivable module. Data migration testing Either you are replacing the old legacy system or upgrading from the previous version, the business will need legacy data migrated to the new system. Data migration testing is basically testing the data integrity and data quality. No matter how you decided to migrate the data, the testing team needs to analyze the migrated data and perform validation and transactions at the end of the data migration to ensure that the data migrated is complete and accurate to do future transactions. For example, if open sales orders are migrated from the legacy system, you need to ensure that you are able to ship and invoice these orders and ultimately, collect cash. You also need to ensure that numbers, such as order count, account balance, and inventory levels, match between the legacy system and new system to make migration complete and accurate. A solid data migration strategy should also define the parameters for the success of data migration testing. Integration testing Testing the integrations with other systems that have been developed is just as important as the features and functional testing of the product itself. Integration testing is performed across applications to verify the seamless flow of information. All individual applications must be tested independently and made ready for integration testing. You will need an integrated environment across applications to perform this testing. For example, Finance and Operations requires integration with the CRM system; in this testing process, you will probably create customers in the CRM system and expect them to flow to Finance and Operations. Performance/load testing Performance testing or load testing is a process of identifying performance issues and solving them. It is important to conduct performance and load testing and tuning before going live to eliminate the issues that can impact the business negatively. It does not matter whether you have high volumes or not; you still need performance testing. At this stage of the project, the development of custom features is complete and functional testing is in progress. This is the time to validate the overall performance of your Finance and Operations system. The primary goal is to ensure that the solution will accept peak load without any major issues.
↧
Blog Post: Types of Testing for Microsoft Dynamics 365 Finance and Operations
↧
Blog Post: Inbound process in advanced warehouse management in Microsoft Dynamics 365 Finance and Operations
Inbound process in advanced warehouse management in Microsoft Dynamics 365 Finance and Operations Receiving options in advanced warehouse management in Microsoft Dynamics 365 Finance and Operations one version D365FO Sharing various options: • PO line receiving (allows to receive all item one by one but create one work per line for put away) ○ No option of group put away License plate grouping available • PO line receiving and put away ○ Every PO line is received and system ask for confirmation for put away ○ 1 line at a time • PO item receiving ○ No option of group put away ○ License plate grouping available ○ Customize to auto complete the put away for PO • PO item receiving and put away ○ Pick and put away are always based on a LP • Separate put away (using existing work but one work per PO line is generated by PO work template) • LP receiving LP receiving and putaway • Mixed LP receiving ○ (item or line number of PO) ○ Good for receiving multiple PO's together • Load item receiving ○ One needs to manually create load per PO line or all PO lines o Could automatically create PO line based load ○ Then use menu item ‘Load item receiving and putaway’ ○ In WMS, operator needs to scan/input load first and then item number o Does not allow us to use MSAsset and item number of MSAsset would not be barcoded. o Also create similar 1 work for put away or shows confirmation for put away after every PO line item is received
↧
↧
Blog Post: Microsoft Dynamics 365 best of Project Service Automation and Finance and Operations
Microsoft Dynamics 365 best of Project Service Automation and Finance and Operations Microsoft Dynamics 365 Project Service Automation and Microsoft Dynamics 365 Finance and Operations one version D365FO Feature use case scenarios: Functionality availability D365PSA D365FO Project quotes Yes Yes Project pricing Yes Yes Project Financials No Yes Project procurement No Yes Project inventory No Yes Project WBS Yes Yes Project billing Yes Yes Project contracts Yes (limited Yes Project reporting Yes (limited) Yes Revenue and cost management No Yes Project Time and expense Yes (limited) Yes Project hierarchy Yes Yes We can integrate PSA and FinOps using a solution from Microsoft which can be downloaded here Below are integration touchpoints: Project contracts Projects and sub-projects Project task Project categories Estimates Hour estimates expense estimates fixed price projects fee transactions Project time synchronize actuals
↧
Blog Post: Full license plate movement in advanced Warehousing in Microsoft Dynamics 365 Finance and Operations
Full license plate movement in advanced Warehousing in Microsoft Dynamics 365 Finance and Operations Movement of full license plate within Warehouse in Microsoft Dynamics 365 Finance and Operations one version D365FO Leverage Nested LP to store all servers/racks on a pallet (parent LP) and move it together • Build parent LP ○ Indirect mode work ○ movement by template d365 finance and operations moving parent license plate error license plate of location is invalid ○ tried using Movement by template to move a Parent LP created by the License plate build function, but I only get an Invalid license plate message. Is it only allowed for Movement work to move Parent LPs built in this way (which means we cannot direct the user to move to a specific location rather the location has to be selected by the user) ○ Human decision to provide the location for putting away • Consolidate LP ○ Once the worker confirms by pressing OK, the consolidation is executed, merging the two work orders together and moving all items from LP to merge to the Target LP. • Nest LP's other parent • Move parent LP to another location • Break LP ○ Indirect mode work Break is not compulsory needed on parent LP and one can directly use individual LP to move inventory Edit tags
↧
Blog Post: Bill of exchange (Accounts Receivables) in Microsoft Dynamics 365 Finance and Operations
BOE Bill of exchange (Accounts Receivables) in Microsoft Dynamics 365 Finance and Operations BOE (AR) A bill of exchange is a written or electronic order from a customer specifying that another party, usually a bank, should pay a stated amount to the company. When you use a bill of exchange as payment for a sales order invoice or free text invoice, you credit the customer account. That credit is secured by the bill of exchange until the customer pays the bill of exchange to the bank. You typically will settle the invoice with the bill of exchange on the due date. When you receive notification from your bank that the bill of exchange has been honored, you can close the bill of exchange. Used with method of payment and a journal name per stage of BOE (Draw, Remit, Settle, Protest, Redraw)
↧
↧
Forum Post: Error found in Exception in AIF AX2012
Hi Team, We found an error in AX2012 AIF exception , please suggest how to fix it? Error details: Document InboundCustPaymJournal could not be updated. Error details: Journal 00962 is being used by admin. Please help to how to proceed on this error to fix.. Thanks in advance..
↧
Blog Post: Customer prepayment in Microsoft Dynamics 365 Finance and Operations
Customer prepayment in Microsoft Dynamics 365 Finance and Operations mostly done by taking a payment from the customer and applying the same on SO rather than prepayment way of separating the posting to GL summary account AR prepayment (deposit) Create SO Create New customer payment journal with sales tax included checked Post a prepayment journal (posting profile should be of prepayment and prepayment checkbox checked From SO Use settle transactions to apply this prepayment Upon SO invoicing the outstanding on the invoice is zero
↧
Blog Post: Vendor prepayment in Microsoft Dynamics 365 Finance and Operations
Vendor prepayment in Microsoft Dynamics 365 Finance and Operations From PO, prepayment invoicing (use when your vendor issues an invoice) Capture prepayment details on the PO on the purchase tab in ribbon Raise a Prepayment invoice Liability is in prepayment account and not in AP summary account in GL Vendor balance reflects the prepayment and also seen in vendor transactions Create a REGULAR vendor payment journal settling the prepayment invoice Raise final invoice after receiving from vendor and USING actions: apply prepayment in the invoice posting time Show the final vendor invoice due amount is reduced by the prepayment amount. Prepayments (non PO based) (when no invoice is raised) No prepayment invoice Liability on actual vendor balance
↧
Blog Post: Promissory note in Microsoft Dynamics 365 Finance and Operations
PN Promissory note in Microsoft Dynamics 365 Finance and Operations A promissory note is a written agreement in which the maker of the note promises to pay a certain amount at a certain time. When you use promissory notes as payment for vendor invoices , you debit the vendor account. You will typically settle the invoice with the promissory note on the due date. When you receive notification from the bank that the promissory note has been honored, you can close the promissory note. In Microsoft Dynamics AX, you use journals to manage promissory notes.
↧
↧
Blog Post: Bank reconciliation in Microsoft Dynamics 365 Finance and Operations - manual
Bank reconciliation in Microsoft Dynamics 365 Finance and Operations - manual key steps Enable bank account for advanced reconciliation (Reco fast tab) Go to bank and then reconcile tab Create a bank statement manually Create statement ID and statement lines corresponding to vendor payments Validate and post (in case of additional charges) Load all bank statement and D365FO would create a bank reco journal using the cut off date (aggregating imported transactions) Open bank reconciliation (journal) Cash and bank management-Bank statement reconciliation-Bank reconciliation (click lines and reconcile) Verify the validated bank statement is automatically assigned when the reconciliation header is created using the date cut off criteria. Create new journal using the new cut-off date if not already created (it is not created automatically when there are other unreconciled journals) Match bank stmt lines with D365FO bank transactions and click on reconcile
↧
Blog Post: Sales tax USA configuration in Microsoft Dynamics 365 Finance and Operations
Sales tax USA configuration in Microsoft Dynamics 365 Finance and Operations key setup includes Sales tax : responsibility of seller to collect and pay taxes to authorities Sales Tax is defined as a tax on the sale, transfer, or exchange of a taxable item or service. Sales tax generally applies on the sale to the end user or ultimate consumer. Sales tax is generally added to the sales price and is charged to the purchaser. Use tax: responsibility of buyer to pay taxes to authorities (these are not collected by seller) Use tax becomes due after a taxable purchase is made, when sales tax was not paid or was underpaid. The purchaser of the goods or services is responsible for paying use tax. Both are applicable in sales tax regimes. (i.e. (US) sales tax taxation rule enabled) Sales tax would post sales tax receivable transactions on AP side (Vendor invoice,,,) however they are never used in any net off calculation. i.e. no input credit only output tax. All the sales tax payable from various sales invoices are to be paid to the authorities. In countries where VAT is used input credit on tax paid to vendors could be used to net off net tax payable. For VAT i.e. using input tax one needs to turn off (US) sales tax taxation rules.
↧
Blog Post: Sales taxation rules Microsoft Dynamics 365 Finance and Operations
Sales taxation rules Microsoft Dynamics 365 Finance and Operations Apply sales tax taxation rules is turned ON Sales tax payable: account used in a customer invoice for outgoing taxes. used in sale tax to pay to sales tax authority. Use tax payable: account use when the sales tax is due on a payment and not on the vendor invoice. In the Use tax payable field, select the main account for posting incoming Use taxes that are payable to tax authorities. The Use tax option needs to be selected in the Sales tax code in the Sales tax group to post Use tax. If Apply sales tax taxation rules option is selected in General ledger parameters, the offset is posted to the transaction’s expense account. If apply US tax is checked then vendor is not required to collect tax rather the company owe these taxes and must get tracked and paid. Apply sales tax taxation rules is turned OFF Sales tax receivable: account use in a vendor invoice for incoming taxes. it is the tax deductible. In the Sales tax receivable filed, select the main account for incoming taxes that are received from the tax authority. Vendors collect taxes on behalf of the tax authority when you buy taxable goods and services. This field is not available if the Apply sales tax taxation rules option is selected in the General ledger parameters page. Instead, sales taxes that are paid to vendors are debited to the same account as the purchase. Use tax expense: account use when the sales tax is due on a payment and not on the customer invoice. Select the ledger account for posting deductible incoming taxes that are not claimed or reported to the tax authority by vendors. Note If the Apply U.S. taxation rules check box is selected in the General ledger parameters form, this field is not available. Common accounts Settlement account : account use for the payment of the tax. In the Settlement account field, select the main account that the net balance of the ledger accounts specified in the Use tax payable and Sales tax receivable fields will be posted. The balance will be created when the Sales tax settle and post job is ran. If the Tax authority for the settlement period is associated with a vendor account, the balance is posted to the vendor account instead. Vendor cash discount : account number of cash discount payable. Customer cash discount : account number of cash discount granted.
↧
Blog Post: Fixed asset layers and books in Microsoft Dynamics 365 Finance and Operations
Fixed asset layers and books in Microsoft Dynamics 365 Finance and Operations Create FA journals in GL (Post fixed asset in G journal names, one per each posting layer Posting layer (on FA group, value model and FA journal) ( Current, Operations, Tax) Depreciation for tax purposes is calculated by current tax rules to achieve the highest possible depreciation before taxes, but depreciation for reporting purposes is calculated according to accounting laws and standards. Current is the default layer. This is used for transactions that are part of the periodic financial reporting. Operations is used for other transactions that are part of the periodic financial reporting for internal purposes. Tax is used for transactions that are not part of the external or internal reporting, but that are for recording special tax transactions, such as tax depreciation for fixed assets. BOOKS (track the financial value of a fixed asset over time) In D365FO Each Book represents an independent financial life cycle, and each fixed asset can have several value models assigned to it. Before you set up Book, you must set up depreciation profiles to assign to the value model.
↧
↧
Blog Post: Year end in Microsoft Dynamics 365 Finance and Operations
Year end / Fiscal closing / period end in Microsoft Dynamics 365 Finance and Operations one version D365FO Setup Calendar Closing role Resource setup Schedule template Copy existing month end template example USSI month end Create a closing schedule with the new template Ensure closing roles and tasks in template are having the company Configuration Templates for different purpose (month end, yearend) Closing Schedule with task and resource assignment Execution (Multiple Closing sheet per account type (Revenue, expenses, etc.) (posting in period type closing )) Click on closing accounts Load balances Make changes to field to transfer in closing sheet Create new fiscal year to ledger Transfer opening balances (Year end close in GL) Show TB in new year Close Company Closing sheet creation for last fiscal year
↧
Blog Post: Fixed asset disposal in Microsoft Dynamics 365 Finance and Operations
Fixed asset disposal in Microsoft Dynamics 365 Finance and Operations Posting parameters when the asset is sold or scrap Disposal scrap journal may show o in Dr and Cr but you should check in GL audit trial for detailed postings Summary of voucher posting: all acquisitions and accumulated depreciation (in BS) are reversed, depreciation posted in P&L remains, and the net book value is posted to P&L If an asset has been completed been depreciated then the value model/book status becomes zero. These assets would not automatically show up in the disposal - scrap proposal. However if one manually post the disposal-scrap journal for a closed FA, it would reverse all acquisitions and depreciations from the books. Useful in demerges/spinoffs. Ensure net book value type is assigned in FA posting profile Disposal - sale and Disposal - scrap to set up postings to the ledger, For both transaction types, the ledger account is credited for the disposal value of the fixed asset. The debit is posted to an offset account, which might be, for example, a bank account. If a fixed asset is sold to a customer, the customer account is used instead of the offset account.
↧
Blog Post: BOM and explosion in Microsoft Dynamics 365 Finance and Operations
BOM and explosion in Microsoft Dynamics 365 Finance and Operations 3 types of Explosion on BOM journal a. Never: Bill of materials are not exploded if there is material shortage. b. Always: Bill of materials are fully exploded c. Shortage: Bill of materials are exploded only when required quantity of materials are not available. If Materials are partially available then explosion happens for remaining items which are not available
↧
Blog Post: Unit of measure UOM in Microsoft Dynamics 365 Finance and Operations
Unit of measure UOM in Microsoft Dynamics 365 Finance and Operations Base unit base for a particular class (weight, volume) and lesser conversions needed between the same class If this check box is selected, the unit of measure is defined as the base unit within the unit’s unit class. The base unit helps streamline the conversion setup for a unit of measure. When a base unit is defined within a unit class, the number of conversion rules between units of measure in the class can be limited. e,g, you can convert from one unit to other unit without a conversion rule between these two units. System unit D365FO uses when no UOM is specified when only a qty field is present, system unit is used to interpret the qty e.g. You may assign base unit (within that class) and system unit (for a class type), the same, for easier understanding. Fixed unit (Length, mass, volume) (prior versions of AX, used in upgrade, integrations) fixed unit association is used to identify a specific unit of measure. By using this association, specific units of measure can be identified by the business logic in Microsoft Dynamics AX and conversions between the units of measure can be completed. E.g. You can name a unit anything / gm / grm for GRAMS which is the fixed unit known by outside world.
↧
↧
Blog Post: Inventory postings config in Microsoft Dynamics 365 Finance and Operations
Inventory postings config in Microsoft Dynamics 365 Finance and Operations Defined in item groups of inventory postings Suggesting different inventory posting types and their typical home in generel ledger Inventory tab Fixed receipt price profit Suggested GL nature: P&L account Fixed receipt price loss Suggested GL nature: P&L account Inventory Receipt Suggested GL nature: BS account (Inventory in asset) Inventory Issue Suggested GL nature: BS account (Inventory in asset) Inventory expenditure,Profit Suggested GL nature: P&L account Inventory expenditure, Loss Suggested GL nature: P&L account Fixed asset issue Suggested GL nature: BS account (Inventory in asset) Rounding variance Inter-unit payable Suggested GL nature: BS account (Liability) Inter-unit receivable Suggested GL nature: BS account (Asset) Catch weight loss account Suggested GL nature: P&L account Catch weight profit account Suggested GL nature: P&L account Price difference for moving average Suggested GL nature: P&L account
↧
Blog Post: Inventory closing in Microsoft Dynamics 365 Finance and Operations
Inventory closing in Microsoft Dynamics 365 Finance and Operations Needs closing and settlements between receipts and issues (marking can be used to transfer actual cost) FIFO (demo) FIFO inventory costing technique in simple terms is based on ‘First In First Out’ i.e. the first receipt is to be settled with the first issue transaction. LIFO (oldest receipt before close/revaluation) LIFO inventory costing technique in simple terms is based on ‘Last In First Out’ i.e. the last receipt (at the time of closing) is to be settled with the first issue transaction. LIFO dated (earliest receipt from consumption day) LIFO dated inventory costing technique in simple terms is based on ‘Last In First Out’ date wise i.e. the latest receipt is to be settled with the issue transaction. Weighted average (demo) Average of all receipts Weighted average inventory costing technique in simple terms is a Periodic weighted average principle i.e. the issues are valued basis the average of the receipts during the inventory closing period. weighted average dated (WA per date) Average of all receipts before the issue Weighted average dated inventory costing technique in simple terms is a Periodic weighted average principle per day i.e. the issues are valued basis the average of the receipts for every day. Weighted average date is an inventory model based on the weighted average principle, where issues from inventory are valued at the average value of the items that are received into inventory for each separate day in the inventory closing period. When you run an inventory closing with weighted average date, all daily receipts are settled against a virtual issue. This holds the total received quantity and value for that day Does not need closing standard cost (may generate a lot of variances if receipt cost are different than std cost) Standard costing technique in simple terms is a statistical and fixed cost approach i.e. the issues are always valued basis the active standard cost price on the item irrespective of the receipts. Any deviation of receipts cost from standard cost are posted to variance accounts Moving average (retail and high volume scenarios) Moving average technique in simple terms is a point in time cost method (perpetual type) i.e. the issues are always valued basis the point in time cost price on the item. Issue cost is final and taken as of that point in time and does not change. Any adjustments to receipts are expensed out.
↧
Blog Post: Purchase Inventory posting in Microsoft Dynamics 365 Finance and Operations
Purchase Inventory posting in Microsoft Dynamics 365 Finance and Operations suggested account types and account from BS/PL Inventory posting in purchasing in Microsoft Dynamics 365 Finance and Operations one version D365FO When "post to charge account in ledger" is turned off When "post to charge account in ledger" is turned ON Used mostly in Europe where expense accounting method is used and it uses stock variation account (Just talk) This is why purchase expenditure accounts are used. Being a global ERP need to address a lot of market regulations PO Receipt PO Receipt 1A) Subledger accounting (View accounting shows all 4 postings, while voucher posted to GL would show only the 2 accounts) 2A) Subledger accounting accounting entry on the product receipt for accrued liability accounting entries on the product receipt for accrued liability 1)Cost of purchase material received (Dr) Asset Cost of purchase material received (Dr) Asset 2)Purchase expenditure, un-invoiced (Cr) Liability Purchase expenditure, un-invoiced (Dr) Liability accounting entry to record the liability for the vendor invoice 3)Purchase expenditure, un-invoiced (Dr) Liability Purchase stock variation (Cr) P&L Purpose of posting charge to ledger was to post the effect of inventory purchase in P&L instead of BS 4)Purchase, accrual (Cr) Liability Purchase, accrual (Cr) Liability 1B) PO Invoice 2B) PO Invoice Packing slip reversal (6 entries posted to GL in voucher, whereas in subledger/accounting it shows 8 entries) Packing slip reversal (not fully) Cost of purchase material received (Cr) Asset Cost of purchase material received (Cr) Asset Purchase expenditure, un-invoiced (Dr) Liability Purchase expenditure, un-invoiced (Cr) Liability Purchase expenditure, un-invoiced (Cr) Liability (NOT REVERSED) Purchase stock variation P&L Purchase, accrual (Dr) Liability Purchase, accrual (Dr) Liability Vendor (AP) (Cr) Liability Vendor (AP) (Cr) Liability Cost of purchase materials, invoiced (Dr) Asset Cost of purchase materials, invoiced (Dr) typically P&L
↧
