Ax30 Inventory Closing Whitepaper 2onded

Microsoft Axapta Inventory Closing White Paper
Microsoft Axapta 3.0 and Service Packs Version: Second edition Published: May, 2005
CONFIDENTIAL DRAFT INTERNAL USE ONLY
Contents
Introduction ...........................................................................................................................1 Inventory Closing-Related Issues in Microsoft Axapta .........................................................1 How to Detect Issues in Inventory Closing.......................................................................2 Potential Triggers of Inventory Closing Issues.................................................................2 Proposed Solutions...............................................................................................................4 Inventory Closing Red Delivery ........................................................................................4 Inventory Closing Yellow Delivery ....................................................................................7 Inventory Closing Green Delivery.....................................................................................7 Other Inventory Closing-related Issues and Recommendations ..........................................8 Simplifying Inventory Closing in Future Versions of Microsoft Axapta.............................8 Pre-closing Data Report ...................................................................................................8 Partial Production Order Costing................................................................................... 10 Beginning the Inventory Closing Process Unintentionally............................................. 15 Inventory Closing Technical Documentation ..................................................................... 15 Performance Considerations in Inventory Closing ........................................................ 15 LIFO in Microsoft Axapta ............................................................................................... 16 Balancing Performance with Accuracy When Closing or Recalculating ....................... 17 Using More Clients to Enhance Overall Performance................................................... 22 Handling BOM Levels.................................................................................................... 23 Handling Transfers Between Warehouses.................................................................... 24 Quarantine Order Functionality ..................................................................................... 27 On-hand and Physical Inventory and Financial Inventory Dimensions......................... 27 Impact of the Include Physical Value Field on Transaction Dates ................................ 29 Marking in Microsoft Axapta 3.0 .................................................................................... 30 Multi-User Inventory Closing Based on Number of Transactions ................................. 31 Multi-User Inventory Closing and Cost Calculation....................................................... 32 Minimum Throughput Adjustment ................................................................................. 34 Different Average Cost Values Within the Same Period Using the Weighted Average Date Cost Model............................................................................................................ 35 Different Results of Recalculation and Inventory Closing ............................................. 36 Modified Date and Consistency Check ......................................................................... 36 Readjusting Inventory Adjustment During Closing and Recalculation .......................... 38 Running Inventory Value Reports ................................................................................. 40 Error Messages When Using Multi-user Inventory Closing........................................... 41 Status of Known Issues (Red Delivery) ............................................................................. 42 Conclusion ......................................................................................................................... 45 References......................................................................................................................... 46 About Microsoft Business Solutions .................................................................................. 46 About Microsoft Business SolutionsAxapta ..................................................................... 46
Introduction
This white paper will describe issues reported by a few customers and partners regarding inventory valuation, re-valuation, and the inventory closing process in Microsoft Axapta 3.0 and its associated service packs. It will also explain the steps that Microsoft Axapta development has taken and expects to take in the future to address these issues. This white paper also describes various scenarios for upgrading from Microsoft Axapta 2.5 to Microsoft Axapta 3.0, including specific configurations that customers should avoid. Furthermore, this white paper describes how Microsoft Axapta development teams expect to address inventory closing-related issues in service packs such as Microsoft Axapta 3.0 Service Pack (SP) 4, as well as necessary updates for Microsoft Axapta 3.0 SP2 and SP3. Note that customers will need to use Microsoft Axapta 3.0 SP2 or later in order to take advantage of the updates described in this document. Updates that address inventory closing-related issues will be divided into three deliveries, referred to here as Red, Yellow, and Green, depending on the content and distribution plan of the updates. The Red delivery is a package of code that has been made available for download. The Yellow delivery consists of an internal tool that will be available for service personnel in order for them to help partners. This Microsoft Axapta Inventory Closing White Paper, second edition is also considered part of the Yellow delivery. The Green delivery consists of new ways of performing inventory closing that will be integrated into future releases of Microsoft Axapta.
Note that different number formats have been used in the screen shots. For example, 36.0 may be displayed as 36,000.
Inventory Closing-Related Issues in Microsoft Axapta

Under certain conditions, Microsoft Axapta 3.0 can return incorrect inventory values in the general ledger as reported from different modules within Microsoft Axapta. It is also possible that some Customers may have issues running an inventory closing routine, under one or more specific conditions. Finally, under certain conditions, the value of the inventory as reported from the Microsoft Axapta Financial Management module may not match the values from the inventory status reports. The functionality of inventory closing and related recalculation routines is described in the section Recommended Method of Using Inventory Closing later in this document. The details of the logic behind calculating inventory value is described in the Technical Information document: Recalculation: Simulated Inventory Closing on the Microsoft Axapta 3.0 installation CD. Inventory closing-related issues are important because, if not addressed, they can potentially prevent customers from financially closing their books and creating financial statements.
How to Detect Issues in Inventory Closing

Detecting inventory closing-related issues in any given Microsoft Axapta installation can be done in three ways: 1. If inventory transactions exist that have an unrealistically high cost value, it could indicate an inventory closing issue. 2. If the re-calculation and closing routines run for an unusually long time, it could also indicate an inventory closing issue. This is because the closing routines may enter into a loop due to incorrect data and extend the inventory closing process. 3. If the financial statement shows incorrect values for the inventory balance accounts. Looping Routines in Inventory Closing Issues involved in inventory closing and adjustment routines can cause incorrect cost values. These incorrect cost values could potentially escalate over time, due to the way the calculation routine works, resulting in a further increase of the incorrect cost values. The principle behind this process is the method Microsoft Axapta uses to try to adjust cost values based on historical transactions. In short, this method can mean increasing cost values. In extreme cases the method can result in database errors because the cost value fields on the inventory transactions cannot contain the extremely large values that the program calculated incorrectly. A few partners have reported trying to solve this issue by changing the length of the database fields, so the fields can hold the extremely large costing numbers. However, this method does not solve the underlying technical reason for increasing cost values and may mean that the inventory closing routine can run for months before the issues become apparent. Other inventory closing-related issues can be caused by a lack of knowledge of how the inventory closing works and of the impact of various parameter settings. A few Microsoft Axapta installations have had serious issues due to incorrect use of inventory closing functionality and improper configuration of the installation. In some situations, manually closing open transactions and resetting the inventory was needed to address the issues.
Potential Triggers of Inventory Closing Issues

Two of the main triggers of inventory closing issues are recalculations and closing in previous periods, and looping. Recalculation and closing in previous periods is described in detail in the section Recommended Method of Using Inventory Closing later in this document. The idea of the looping functionality is described in the Technical Information documentation called Recalculation: Simulated Inventory Closing, which is provided on the Axapta 3.0 installation CD. Parameter Settings Inventory closing and recalculation can be a very complex process. Running the same scenarios with different parameters or inventory model settings can result in substantially different cost situations from the inventory closing. Changing parameter settings when users have transactions that have not been settled yet, and then performing inventory closing, can give results that can be hard to explain or understand. This is not a technical issue (the figures are correctly calculated) but rather a best practice accounting issue. The following parameter-related practices may cause issues with inventory closing: Incorrectly applied dimension parameters, for example, checking financial inventory or physical inventory when not necessary, or allowing blank values Changing dimension parameters when transactions exist, making it very hard to compare results
Changing item groups on items can lead to incorrect inventory values after reconciling to the ledger, if item groups form the basis for the selection of ledger accounts Incorrectly applied inventory model group parameters, for example, setting up service items as regular items or checking the Include physical value field without a business reason Changing inventory model group parameters can cause confusion, although this is not a technical issue Incorrectly applied inventory closing parameters, for example, users should not apply settings so that average cost is calculated using the FIFO inventory model, or use average instead of the best choice, Weighted average date inventory model
Invalid Data The trigger that causes looping is not the looping functionality in itself, but rather the existence of erroneous start up data before running inventory closing. Due to the functionality looping over the inventory transaction set, the routine will try to correct the values, but instead of correcting the values it will end up with an incorrect result. Incorrect data has been seen as a result of importing old data, as well as from the manual entry of data. In both cases, the incorrect data is usually entered during the initial implementation of Microsoft Axapta. Having invalid or nonoptimal data before running an inventory closing or recalculation can cause different kind of issues: Unexpected high or low, or even negative cost prices Purchase orders not fully financially updated Adjustments of incorrectly selected transactions Returns with incorrect values for the ID of an item lot that is returned to the inventory Production order costing not done or done before raw material costs are known Excessive looping, resulting in performance issues caused by incorrect parameter selection Database value out of range errors due to large numerical values if first introduced to the system. This can be caused by an incorrect import of data, incorrect data input, or by upgrade issues (see the following section).
Upgrading If users are using Microsoft Axapta 3.0 SP2 or SP3 or have just upgraded to these, it is recommended that they install the Red inventory closing delivery package. As part of the Red delivery, two jobs: updateInventTransIdReferenceLot and updateInventTransIdReturn are installed. These two jobs correct markings and returns, correcting issues that might have been introduced from elsewhere in the system. Customers should run these two jobs after installation. They must run the updateInventTransIdReferenceLot job before the updateInventTransIdReturn job.
Proposed Solutions
As described previously in this document, Microsoft Axapta development has split the updates into three deliveriesRed, Yellow, and Green.
Inventory Closing Red Delivery

A number of known issues for Microsoft Axapta 3.0 from SP2 and later are addressed in the Red delivery. Most of these issues have been previously addressed in either earlier hot fixes or previous updates designed to solve specific issues at individual customer sites. Some of these issues have been addressed in Microsoft Axapta 3.0 SP3. For a more detailed description of and solutions for these issues, see the section Status of Known Issues (Red Delivery) in this document. The goal of the Red delivery is to align the updates in Microsoft Axapta 3.0 SP2 and SP3 by back-porting the updates, hot fixes, and customer-specific updates made in Microsoft Axapta 3.0 SP3 to Microsoft Axapta 3.0 SP2. The inventory closing-related updates included in Microsoft Axapta 3.0 SP3 are also expected to be included in the new Microsoft Axapta 3.0 SP4. Recommended Method of Using Inventory Closing In order to avoid potential issues, customers using Microsoft Axapta 3.0 SP2, SP3, and SP4 are strongly recommended to perform the following actions when closing their inventory: 1. Verify that physically updated transactions, when including physical value, and, as in Figure 1, financially updated transactions, do not have any abnormally high cost amounts. For more information, see the section Report to Check for Receipts with Incorrect Cost Price. 2. Check if purchase orders that are not yet financially updated can be updated. 3. Check if production orders that are not yet costed (financially updated) can be cost updated. Another potential issue is the possibility of partly cost updating a production order. An example could be that the order is started for 100 units and two out of three operations are completed for the whole quantity, but only 10 units are reported as finished. The total cost consumed will burden the cost price for the 10 units that are already reported as finished. 4. If possible, clear the Financial negative inventory check box for the inventory model group. This means that issues cannot be financially updated unless there is positive financial on-hand to fulfill the quantity. When an inventory model group uses financial negative inventory, users can, for example, sell items they physically have in the inventory without knowing the cost price. If the business process does not need this functionality, looping can be prevented during closing or recalculation. This should increase performance. 5. If possible, clear the Physical negative inventory check box for the inventory model group. This means that items cannot be updated until the on-hand inventory physically exists. When an inventory model group uses physical negative inventory, users are allowed to transfer more items from one warehouse to another than are actually in the inventory and therefore might not know their cost price. If the business process does not need this functionality, inventory closing might takes less time if this parameter setup is not used. As described in the section Handling Transfers Between Warehouses, a transfer can end up in a loop where running an inventory closing or recalculation may take longer to run. 6. If possible, avoid using batch or serial numbers. When using, for example, serial numbers, the transactions will be posted for each serial number. Inventory closing
and recalculation may take a long time due to the fact that the program will have more data to work with. Customers might be using batch and serial number dimensions even though, from a business perspective, they are not needed. For example, the batch number dimension could be being used instead of the marking functionality. The setup of dimension groups could also not be detailed enough, for example, all items could be using the same inventory dimension group with the serial number dimension. 7. If customers find that recalculation or closing takes too long to run and/or uses too many system resources during normal working hours, they can set it to run using the Batch functionality at a more convenient time, for example, at night or at weekends. 8. Cancel all recalculations from the inventory close date and onwards (see the section Cancel Recalculations). 9. Run inventory closing before closing finance. 10. If possible, change the closing parameter for looping (Maximum throughputs) to five at the most (assuming there less than five BOM levels). (See the section Reduce Looping to a Maximum of Five.) Report to Check for Receipts with Incorrect Cost Price (Recommendation 1) A standard report to find the receipts with an incorrect financial cost amount can be used, as illustrated in Figure 1. To open the report, click Inventory management > Reports > Transactions > Inventory transactions. In the example shown, the limit has been set to 1,000,000, but in practice this number needs to be set according to the data in the actual ledger. The best check would be to take the price per unit into account. Unfortunately, this is not possible in the standard report, but is expected to be part of the overall solution for the Service Packs for inventory closing. The report should be run before the closing, where transactions are still open.
Figure 1: Report to check for receipts with incorrect cost price
Cancel Recalculations (Recommendation 8) The reason for this very important recommendation is explained and illustrated in Figure 2. In this example, inventory is recalculated monthly (R1 R8) and closing is done today (dated at R6). The inventory value will be correct at R6 but incorrect on date R7 and later. The correct way to close inventory in this case would be to cancel the recalculations R7 and R8 before running the inventory closing. The recalculations R7 and R8 can then be executed afterwards. This would give a correct inventory value. For more information, see the flow chart in Figure 33, which shows the new closing and recalculation process. You can also refer to Figure 34 to help you address any other issues.
Inventory Closing Periodic Closing and Recalculation

R1 Day 0 R2 R3 R4 R5 R6 R7 R8 Today
Closing Date
Incorrect inventory value
Inventory is recalculated monthly R1 R8 and closing is done today dated at R6. Then the two recalculation R7 + R8 will have adjustments that are incorrect after the closing.
Figure 2: Periodic closing and recalculation
Reduce Looping to a Maximum of Five (Recommendation 10) A very low maximum throughputs parameter can eliminate the loop in inventory closing and recalculation. Customers who are experiencing looping in inventory closing may find that changing this parameter to a lower value can increase program performance. Looping may occur if items are transferred between warehouses without having the items present physically or financially (depending on the setup). The Maximum throughput parameter determines the maximum number of calculations. If looping occurs, calculations will continue until adjustments are below the minimum throughput adjustment value, or if the number of calculations is exceeded. The parameter ensures that calculations are not repeated indefinitely if the minimum throughput adjustment value is very low. The following example shows how transfers between warehouses using an estimated cost value are adjusted when only some of the items are financially updated. The adjustment must then be applied to all of the looping items, so that the estimated cost of the transfer transactions is updated for items to the new known cost value per piece.
Microsoft Axapta Inventory Closing White Paper 6
With a Maximum throughputs parameter of two, the final adjustment will be equal to the result of the first calculation, making only one adjustment to the updated items. This leaves the estimated cost for the items that have not been financially updated unchanged.
Warehouse Physical & Financial date Reference Receipt Issue Qty Cost amount Lot ID Physical Financial AdjustCost Cost ment amount amount Profit & Loss, posted amount 100 -100 Settled quantity Cost Cost financial 2 updated loops purchase (Qty 10 Cost 100/pcs.) -190 190 100 -190 100 -10 -1000 1000 1000 -1000 1000 -100
MW GW MW GW MW MW
03-06-2004 Transfer 3 03-06-2004 Transfer 3
Sold Purchased
-10 10 1 -10 10 -1
-190 00076 190 00076 100 00075 -190 00077 100 00077 -10 00078
-100 100 10 -100 100 -100
-100 100 100 -100 100 -100
-90 90
-10 10 1
03-06-2004 Purchase 18 Purchased 03-06-2004 Transfer 4 03-06-2004 Transfer 4 03-06-2004 Sales 17 Sold Purchased Sold
-90
100 -100
-10 10 -1
90
100
This example shows 1 item physically received and then 10 items are moved from warehouse MW to warehouse GW and then back to warehouse MW. Then 1 item is sold at a cost value of EUR 10. Now the purchase invoice is updated for the 1 item at a new cost value of EUR 100. When running inventory closing, all the looped items must be adjusted to the new cost of EUR 100. The last column shows the cost after Purchase 18 is financially updated with a quantity of 10 and a cost of 100 per unit. In order to improve performance when during a recalculation it is recommend that you specify a low Maximum throughput value. However the value should be greater than the maximum of BOM levels used. When doing a closing, the maximum throughput value should be set to 100 in order to get accurate cost values, therefore the limit should not be reached during a closing. Note: There is a new closing procedure, for more information, see Figure 33.
Inventory Closing Yellow Delivery

The Yellow delivery consists primarily of tools that internal staff at Microsoft can use to analyze customer data. For example, it explains how customers can check their data and setup before running inventory closing.
Inventory Closing Green Delivery

The Green delivery will consist of further code updates that are expected to be included in Microsoft Axapta 4.0 and future releases. Industry Setup Templates (Four Vertical Choices of Inventory Setup) Product Managers can make suggestions about how to setup inventory according to the business target group and industry-specific setup templates are expected to be provided to guide customers through a best practice setup process. Safe Mode Parameter Administrators can set up a safe mode parameter to restrict users from configuring Microsoft Axapta in ways that may result in incorrect inventory closing values. Parameters cant be changed on an itema new item has to be created (a warning should be displayed). Default Configuration Log File The database logging system must be set up by default, to allow users to investigate the history of changed inventory closing parameters.
By default, the record setup for the tables related to inventory closing, for example, InventDimSetup, should include the Last changed field and the Changed by field. Customers can modify the programs security setup in order to limit the ability of others to change configurations related to inventory closing. By default, users and administrators cant change the inventory models and dimensions, and so on. Improvement of the Online Help and User Assistance As part of the Green delivery, it is anticipated that the online Help and user assistance will be updated to include guidelines and illustrations that are easier for the end user to understand. There will be more examples backed up with conceptual and procedural help text.
Other Inventory Closing-related Issues and Recommendations

Simplifying Inventory Closing in Future Versions of Microsoft Axapta
There are a number of plans to make inventory closing in Microsoft Axapta 4.0 easier for customers to use and also improve the fit with specific business markets. The intention is to improve functions and features for using standard costing. These improvements are expected to include overhead costs for time and material, plus a new module for variance analyzing. The following describes other potential ways to simplify inventory-closing functionality in future versions of Microsoft Axapta. Quarantine Order End Functionality Simplifying the way scrap items and credit notes are handled in quarantine orders is being investigated. Cutting the Connection Between the Include Physical Value Field and Physically Updated Transactions Configuring Microsoft Axapta so that it is possible for users to include physically updated transactions, regardless of whether the physical value is included when estimating the cost price, would make the functionality more visible. Inventory On-hand Adjustments and Locking of Cost Value When an on-hand adjustment is zero, it would be useful for users to have the option of locking the cost value so that no further adjustments are made when closing the inventory. For more information, see the section: Readjusting Inventory Adjustment During Closing and Recalculation. Weighted Average with Receipt Adjustment Rounding in settled quantities and settled cost values could cause inaccurate cost prices.
Pre-closing Data Report

Customers can create a checklist report before inventory closing. Such a report could contain warnings about transactions that are not financially updated before the closing date. For example, the report could warn about an inventory transaction from a purchase order that is not fully posted financially because the vendor invoice has not yet been received, or about a BOM component included in a production run on a higher level that is not financially posted, resulting in the subproduction not being cost calculated.
Warnings are provided to alert users about transactions that are physically updated but not financially updated before the closing date. Examples of situations that produce warnings include:
If an inventory transaction from a purchase order is not fully received financially, but the items are received and perhaps used in a sales order or a production order (but the vendor invoice has not yet been received); If the purchase order is received but is not invoiced, the closing will only do an update of the physical value if the Include physical value check box is selected in the inventory model group. In this case, a later update of the purchase order to the status Invoiced with an adjusted purchased cost value will not settle any issues until after the next closing, and will not be part of the current period cost contribution.
Customers can run reports to examine these issues. Figure 3 is an example of this type of report. The report must display the critical transactions before the closing date.
Figure 3: Pre-closing data report, purchase lines
In the update journal report illustrated in Figure 4, the production order is not yet financially posted. However, the items are reported as finished and have perhaps been used in a sales order or another production order. If all consumption is reported for a production order and the production order is reported as finished then the production order must be finally costed. It is recommended that the specified date of costing is the same as the reported as finished date. Avoiding such a situation can help ensure that the value from Item in Progress (IIP) and Work in Progress (WIP) is posted to the finished item warehouse. The report must display the critical transactions before the closing date.
Figure 4: Production orders reported as finished
In the examples illustrated by Figures 3 and 4, it is important that purchase and production receipt transactions for an item are financially updated before closing, if the transactions are physically updated. In Figure 5, production order BOM lines are not financially updated, but the finished produced items are reported as finished. A production order can only be updated with the accurate cost during closing if all of its sub-assemblies have been costed. Figure 5 is an example of the output for this part of the report. The report must display the critical transactions before the closing date.
Figure 5: Pre-closing data report, production with open subproduction
For an example illustrating that the correct inventory value can only be obtained at the inventory close date, see the section Running Inventory Value Reports in this document. Pre-closing Report Search Criteria The report should check that: The posted quantity (financially updated quantity) of the item is less than zero within the financial dimensions on the closing date. When this case exists, it will not be possible to settle all issues against the receipts. Marked issues where the corresponding receipt(s) are not financially updated.
Partial Production Order Costing

This section describes what happens when costing a production order and running the inventory closing. In Microsoft Axapta, costing a production order results in financially updated inventory transactions, even though the production order has not ended. It is possible to perform a costing of a production order after the production order has been started and a quantity has been reported as finished. If the costing is done without selecting the parameter End job, the production order is actually financially cost updated as if the parameter was selected. This behavior has the following impacts:
The inventory transaction is financially updated for the production order according to the reported finished quantity. This means that all costs are put on the reported as finished quantity, even if this is only a small part of the total production quantity. The cost price can therefore become incorrect.
10
The items in process and the work in process accounts are deducted and the finished goods account is increased as if the production order is completed. If the quantity reported as finished doesnt correspond to the reported consumption, then the accounts are affected with values that do not correspond to the actual situation. For example, a production order can be reported as finished with a quantity of 20, but the material consumption corresponds to 100 items.
An Example of Partial Production Order Costing The following example shows how an apparently incorrect cost price on an issue transaction, which is caused by a partial costing of a production order, can actually be corrected by running the inventory closing after ending and finally costing the production order. The example is as follows: A company begins a production order of five units. When two units are produced on the production order, a sales order with a demand for one unit is created. In order to fulfill this sales order, two units of the production order are reported as finished and a partial costing is carried out. The partial production order costing is done to help ensure the most accurate cost on the sales order transaction. This example shows that this cannot be achieved until the production order is ended and finally costed, and the inventory closing is run in order to settle and adjust all the transactions involved. A production order with a quantity of five is created for an item. The item has a Bill of Material consisting of one item and a route with a single operation.
Figure 6: Create the production order of five units
The production order is cost estimated in order to get an overview of the cost associated to the production order. In this case, the cost price per unit is 13.5.
11
Figure 7: Estimated cost calculation
The production order of 5 units is begun with the parameters set up as shown in the screenshot in Figure 8.
Figure 8: Start of the production order
A sales order has a demand for 1 unit from the production order. In order to fulfill the sales order demand, the production order is partially reported as finished with the quantity of 2.
12
Figure 9: Report two units finished
The production order becomes partially costed. Users must clear the End job and Report as finished check boxes on the Costing form in order to do additional reporting on the production order to complete the remaining three units.
Figure 10: Costing of the two units
After costing the production order, the sales order for the single unit becomes invoice updated. The cost amount for the financially updated and costed production order line of two units is 67.500. This is actually the cost amount for the complete production order. The cost amount for the sales order line of one unit is 33.75, which is half of the cost amount for the entire production order of five units. The transaction for the three remaining units cost amount does not become updated. At the moment, these values are incorrect and they will first be corrected when the final costing of the production order and the inventory closing have taken place.
13
Figure 11: Transaction for the item
The remaining three units on the production order are reported as finished and the production order is ended. The production order is finally costed and the cost amount for the two production order transactions are adjusted and settled according to the quantities of the two transactions. That is, two units for the first transaction and three units for the second transaction. Cost amount for the first transaction = 67.5 x 2/5= 27 Cost amount for the second transaction = 67.5 x 3/5= 40.5 The cost amount for the sales order transaction is still not correct. It is still 33.75 and the cost amount will be corrected when the inventory closing has been run.
Figure 12: After finally costing the production
When closing the inventory the cost amount of the sales order transaction gets settled and adjusted to the correct cost amount of 13.5, as shown in Figure 7, under Estimated Amount, in the Total cost price per unit field.
14
Figure 13: After closing the inventory
This example clearly illustrates the issue with incorrect cost amounts on sales order transactions, when items are issued from a partial costing production order.
Beginning the Inventory Closing Process Unintentionally

In Microsoft Axapta 3.0, the Inventory close form has the OK button set as the default, therefore, if the Enter key is pressed after typing in one parameter field, inventory closing or recalculation will begin. It is anticipated that code will be designed to update this function and will then be released as part of the Green delivery. Until the update is released, it is suggested that customers take care not to unintentionally begin an inventory closing.
Inventory Closing Technical Documentation

Performance Considerations in Inventory Closing
This section explains in detail how performance of the inventory closing functionality in Microsoft Axapta 3.0 SP2 and onwards is affected by different parameter settings, in connection with the different inventory evaluation methods that are supported by Microsoft Axapta. The section also contains a technical description of the calculation techniques involved (focusing on calculating the cost of goods sold) and explains why looping or circularity is necessary to get the correct values. The Fundamental Costing Issue The fundamental costing issue is that companies do not necessarily know the cost price of their items when the items are sold. Companies are often forced to operate with estimated and forecasted cost prices if they do issues of items before the purchase order (or production order) for the items are invoice posted (or costed). The fundamental challenge regarding inventory costing and valuation is therefore to design a strategy to deal with this uncertainty. There are generally two ways companies can handle this issue. They can either operate with a politically selected cost price (standard cost), or they can recalculate and adjust the used (estimated) cost price when they learn the actual price of the receipt. Microsoft Axapta supports the following inventory evaluation methods:
Inventory model
FIFO (First In First Out)
Definition
Item issues are always balanced against the first items received in inventory, based on the date of the inventory transaction.
15
LIFO (Last In First Out) LIFO date
Item issues are always balanced against the items received last in inventory, based on the date of the inventory transaction. Item issues are always balanced against the items received last in inventory, based on the date of the inventory transaction. However, an item issue is never balanced against an item receipt that falls after the date of the issue. If, however, there is no item receipt before the item issue, the issue is balanced against any issues falling after the date of the item issue. Item issues are valued at an average value, based on the items that make up the inventory value at the time of the item issue. An item issue is balanced proportionally against item receipts. Users can decide on the minimum quantity to be balanced against, either in the Inventory parameters form, in the Minimum average quantity field, or directly for the individual item in the Item form, on the Other tab, in the Minimum average quantity field. The same principle as Weighted average, although the inventory value forming the basis for the average value consists of open item receipts falling before the item issue.
Weighted average
Weighted average date
The inventory evaluation method is expressed by selecting an inventory model group that must be attached to any item. In the model group, users can enable the use of a standard cost price in combination with any of the inventory evaluation method described. The effect of the selected inventory model can be seen when closing or recalculating the inventory. For more information on inventory models, see the following sections in this document: Weighted Average Date Inventory Model, LIFO in Microsoft Axapta, and Different Average Cost Values Within the Same Period Using the Weighted Average Date Cost Model.
LIFO in Microsoft Axapta

In the inventory model LIFO (last in first out) item issues are always balanced against the items received last in inventory, based on the date of the inventory transaction.
Figure 14: Order of settlements in Axapta LIFO
As Figure 14 shows, the order of settlements for the LIFO cost model in Microsoft Axapta, where PO stands for purchase order and SO stands for sales order. For example, settlements with PO3 would be made starting with the latest sales order (SO3) and working back through SO2 and then SO1. In this way, Microsoft Axapta can take account of negative inventory.
16
Balancing Performance with Accuracy When Closing or Recalculating

This section focuses on multi-user inventory closing supported by Microsoft Axapta 3.0 SP2 and onwards. The aim of enabling multi-user inventory closing was to solve two performance related issues, these being:

Performance in general, and particularly when the Weighted average inventory model is used Very large fluctuations in the actual cost price average when physical value is included in the calculation
Expected Performance The precise level of performance that will be achieved at each individual customer installation cannot be calculated in advance because there are too many company and architecture-specific factors that can affect the result. In each individual situation, users should consider how the inventory closing parameters should be set in order to reach a sensible compromise between the ultimately correct cost value and the desired level of precision in inventory calculations. Running Recalculations and Closing with Less Precise Parameter Settings: Initial Recommendations The following are the initial recommendations for running recalculations and inventory closing:
If average cost is used as the inventory valuation principle, the parameter Minimum settle quantity percent should be set to approximately 10 percent, but not below 5 percent. A value below 5 percent can have a substantially negative effect on system performance. Inventory closing should not be performed during normal working hours. If needed, the inventory closing process can be interrupted and resumed again later.
The following sections describe the reasons for these recommendations in more detail. Closing and Recalculation The Closing and adjustment form is where users can initiate calculations:
17
Figure 15: Closing and adjustment form where calculations are initiated
When users click Close or Recalculation, the following expanded dialog appears (the dialog for recalculation has an additional section for selecting items):
Figure 16: Expanded Close inventory dialog
At the bottom of the dialog, under the Weighted avg. group, are two fields that are only relevant for average inventory models (the Weighted average or Weighted average date inventory models). The Minimum settle quantity percent field and the Minimum settle amount field minimize the number of settlements and therefore the risk of fragmented settlements, which can result in poor program performance. Together with the fields described in the next section, users can use the settings in these fields to make a compromise between performance and precision. Compromising Between Performance and Precision It is possible to compromise between program performance and precision results, by setting different values in the following fields: Maximum throughputs Minimum throughput adjustment The item-specific Minimum average quantity field, which has a fall back value in the global inventory parameter
Generally it is not recommended to set the Minimum throughput adjustment parameter below the value of 1. The Minimum settle amount field has a default value of 5. The lowest value that can be selected is calculated by rounding the default currency multiplied by 10. The value will need to be adjusted according to the local currency, average purchase prices, and quantities. If purchase prices are below 5, a smaller amount must be used. For
18
more information about Minimum throughput adjustment parameter, see the following section in this document: Minimum Throughput Adjustment. The following example outlines the potential issue with the use of the Average cost inventory model: If a company buys an item in month one for the price of 10 in quantities of 100, and subsequently in the same month sells the item again in a quantity of 50, then the records may appear as shown in the following tables when the inventory is closed for the first time: Closing the first time:
Type Nr Quantity Cost Settled quantity 50 -50 Open New settlement 50 Remainder
Purchase
100 -50
1000 -500
yes no
50
Sales order 2
After the first month all 100 units are sold:

Type Nr Quantity Cost Settled quantity 83.33 -50 66.67 -100 Open New settlement 33.33 Remainder
Purchase
100 -50 100 -100
1000 -500 1000 -1000
Yes No Yes No
16.67
Sales order 2 Purchase 3
66.67
33.33
Sales order 4
After the third month:

Type Nr Quantity Cost Settled quantity 94.44 -50 88.89 Open New settlement 11.11 Remainder
Purchase
100 -50 100
1000 -500 1000
Yes No Yes
5.56
22.22
11.11
-100 100 -100
-1000 1000 -1000
-100 66.67 -100
No Yes No 66.67 33.33
Sales order 6
After the fourth month:

Type Nr Quantity Cost Settled quantity 98.15 -50 96.30 -100 88.89 -100 66.67 -100 Open New settlement 3.71 Remainder
Purchase
100 -50 100 -100 100 -100 100 -100
1000 -500 1000 -1000 1000 -1000 1000 -1000
Yes No Yes No Yes No Yes No
1.85
7.41
3.70
22.22
11.11
66.67
33.34
Sales order 8
After the fifth month:

Type Nr Quantity Cost Settled quantity Open New settlement Remainder
19
Purchase
100 -50 100 -100 100 -100 100 -100 100
1000 -500 1000 -1000 1000 -1000 1000 -1000 1000 -1000
99.38 -50 98.77 -100 96.30 -100 88.89 -100 66.67 -100
Yes No Yes No Yes No Yes No Yes No
1.23
0.62
2.47
1.23
7.41
3.70
22.23
11.11
66.67
33.34
Sales order 10 -100
The pattern continues accordingly. All settlements are represented in the database with a settlement record. In this case, six settlement records will be created. For sales order number 10, six settlement records will therefore be created after five months, one for each purchase order that is included in the average. When all the purchase orders to a greater or lesser extent contribute towards the current average, then a little bit of each purchase order will be taken into the current sales order. The critical challenge here lies in the fact that the first purchase will in principle continue to contribute to the current average forever. This means that, as time goes by, more and more purchase orders are included in a settlement calculation and this can eventually result in a decrease in program performance. The multi-user inventory closing system has therefore been developed with two new setup options to limit the number of settlements. In the Minimum settle quantity percentage field, users can specify the minimum quantity that should be taken from each purchase order that is included in the average settlement, as a percentage of the current issue quantity. The value of the Minimum settle quantity percentage field is used in the same way as the Minimum average quantity parameter, except it is not corrected for all records, but is dependent on the quantity of issues. (Users can find the Minimum average quantity parameter by clicking Inventory management > Parameters and opening the Inventory parameters form or they can see the value individually specified on the Item form.) If the issue quantity is for one unit and the value in the Minimum settle quantity percentage field is set to 10 percent, then a quantity of at least of 0.1 from each purchase order must be included. On the other hand, if the sales order is for 1000 items, then a minimum quantity of 100 items must, if possible, be taken from each purchase order when the average is calculated for the current order. If the value returned by the percentage calculation is less than the minimum average quantity, then the minimum average quantity is used. The following form shows an example of average settlements where the Minimum settle quantity percentage field has been set to 10 percent of the issue quantity.
20
Figure 17: Settlements in the transaction with minimum settle quantity percentage set to 10 percent of issue quantity
As an alternative to setting percentages, users can specify a minimum settlement amount in the Minimum settle amount field. The logic is, for the most part, analogous to the minimum quantity, except that here an amount rather than a quantity is used. The form in Figure 18 shows the same inventory settlement where the minimum settlement amount is set to 15.
Figure 18: Settlements in the transaction with minimum amount set to 15
As can be seen, there is a large difference between the cost values of the sold items. This is, as mentioned earlier, why users should consider the best parameter setting for each situation, in order to reach a sensible compromise between the ultimately correct cost value and the desired level of precision in inventory calculations. If zero is specified in the Minimum settle quantity percent and Minimum settle amount fields, then the minimum average setup is ignored. This is not recommended however, especially if the Weighted average inventory model is used. Weighted Average Date Inventory Model As an extension of the multi-user inventory closing that was available in Microsoft Axapta 3.0 SP2 and onwards, changes were made to the way that items are closed when users select the Weighted average date inventory model. After Microsoft Axapta 3.0 SP2, item transfers, purely in terms of settlements, will no longer make circularity settlements. For example, assume the following three inventory records exist:
Date
1/1
Type
Purchase order
Nr
1
Quantity
100
Cost amount
1000
21
Date
2/1 2/1
Type
Pallet transport Pallet transport
Nr
2 2
Quantity
100 100
Cost amount
1000 1000
According to the inventory-closing model before the multi-user inventory closing, the pallet transport records of 100 were settled according to the average, with 50 on the purchase and 50 on the pallet transport itself. This would not be logical, which is why the functionality was changed so that multi-user inventory closing will settle all 100 items on the purchase order. This avoids a potential circularity issue, which could otherwise have had a negative effect on program performance. Because Microsoft Axapta 3.0 SP2 takes advantage of multi-user inventory closing, there will be differences in inventory closing results, compared to previous releases and service packs. This is because of the way that multi-user inventory closing transfers adjustments between the item level and warehouses. In Microsoft Axapta 3.0, SP1, inventory closing occurred, in principle, per inventory record, while in the inventory closing in Microsoft Axapta 3.0 SP2, this occurs summarily in order to improve program performance. For example, consider a production order for the item F1, which consists of the raw materials R1, R2, and R3, and imagine that it is as follows:
Item
R1 R2 R3 SUM
Adjustment
100.75 299.25 399.01 0.99
If adjustments from the raw materials should be transferred to the finished item F1, then the multi-user inventory closing method in Microsoft Axapta 3.0, SP2 will not transfer anything at all to the finished items level if the minimum throughput adjustment parameter has been set to 1.00. In the inventory closing method used by Microsoft Axapta 3.0, SP1 and earlier, all raw material adjustments were transferred to finished items, as long as each individual adjustment clearly exceeds the minimum throughput adjustment. For more information about the Weighted average date model see the section Different Average Cost Values Within the Same Period Using the Weighted Average Date Cost Model in this document.
Using More Clients to Enhance Overall Performance

If users select calculation help (by clicking Inventory management > Periodic > Closing and Adjustment > Calculation) then the following dialog appears:
Figure 19: Calculation help dialog
This means that if a user begins an inventory closing or recalculation of the inventory, then the current client helps to execute the update. If the user is operating with a three-tier installation then the execution is completed on the server. If the user is operating with a
22
rich client in a two-tier installation, then the job is carried out on the users local computer. In a three-tier solution, users must take care not to overload the AOS by starting too many clients. In this situation, it would be better to run the updating job on the current users computer as a rich client. The Stop calculation option can only be selected if the inventory is about to be closed or recalculated. This menu item allows a user to temporarily pause an in-progress inventory closing or recalculation. When the pause is first initiated, a certain period of time will pass before all clients and users actually stop. This is because the system must complete items currently being calculated when the pause was initiated. An inventory closing that has been stopped can be started again via the Calculation help dialog. This function is intended to help users stop operations that appear to be taking an unexpectedly long time. Users can also use this functionality to process an inventory closing in intervals, for example, every day after business hours. Load Balancing Customers should be aware that a certain number of jobs should be run in order to find a suitable number of clients needed to close the inventory in an acceptable time period. It is recommended that users proceed gradually to find the correct balance. For each new client that is assigned to close the inventory, the CPU load on the client computer, the AOS, and the database should be monitored carefully.
Handling BOM Levels

This section describes how to handle costing through BOM levels. Consider a BOM structure as shown in Figure 20:
Figure 20: Sample BOM structure
The item M1 is manufactured through the use of an operation and the two raw material components R1 and R2. The item M1 is then used in another operation, along with raw material component R3, resulting in the top level manufactured item called F1. The challenge with BOM levels is that users often do not know the cost price of some of the raw materials when they are consumed in production. It can be difficult to recalculate cost not only for the current item, but also to the next item level, as shown in the following example.
Date
1/1-2004 2/1-2004 3/1-2004 2/2-2004 3/2-2004
Item
R1 R2 M1 R3 F1
Estimated price
10
Known price
20
Adjustment
30 40 70
23
The cost price for raw material R1 is unknown when item M1 is produced. The cost price has been estimated at 10 (as shown in the preceding table), but the true cost is unknown until the invoice for R1 is received. The result is that the cost price for M1 is also estimated, and the same goes for F1. If half of the produced F1 items are sold immediately to a customer through a sales order, then item consumption must be estimated with the best guess to date. In this example, the cost price is estimated at 70. The remaining half of the produced item F1 would then enter the inventory at a value of 70 per unit. Inconsistencies can arise if the actual cost price turns out to be different than the estimated cost price. Imagine that the invoice for R1 arrives at a much later date, and the real or actual cost price for R1 is 100 instead of the estimated 10. A recalculation across all BOM levels must be performed, and the value of the produced items must be adjusted accordingly, as shown in the next table:
Date
1/1-2004 2/1-2004 3/1-2004 2/2-2004 3/2-2004
Item
R1 R2 M1 R3 F1
Estimated price
10
Known price
20
Adjustment
+90 +90
30 40 70
+90
The value or cost price of the remaining F1 items stored in the inventory must be reevaluated to 170, and item consumption for the sales order that was already posted must also be increased. Today, Microsoft Axapta handles this cross-level cost value adjustment.
Handling Transfers Between Warehouses

Another potential issue in costing relates to item transfers. Figure 21 shows an example where item R1 is first purchased to warehouse A, then moved to warehouses B and C, and then finally moved back to warehouse A.
Figure 21: Handling transfers between warehouses
The issues are similar to the BOM level example described earlier. The cost price for R1 must be adjusted through every warehouse if the cost price was not known when the first transfer occurred. The following example shows the transactions for a round trip transfer:
Date
1/1-2004 1/1-2004 1/1-2004 2/1-2004 2/1-2004 3/1-2004 3/1-2004 4/1-2004 4/1-2004
Type
Purchase 1 Transfer 1 Transfer 1 Transfer 2 Transfer 2 Transfer 3 Transfer 3 Transfer 4 Transfer 4
Item
R1 R1 R1 R1 R1 R1 R1 R1 R1
Warehouse
A A B B C C D D A
Qty
10 10 10 10 10 10 10 10 10
Price Adjustment
? 10 10 10 10 10 10 10 10
If it turns out that the real cost price for R1 is 100 instead of 10, inconsistencies with item values would be created because the purchased item would have already been moved to another warehouse. The value would be incorrect for warehouse B, unless the transfer transactions are adjusted accordingly. When the purchased item finally returns to the original warehouse A, the value must be adjusted and transferred through all warehouses as shown in the next table:
Date
1/1-2004 1/1-2004 1/1-2004 2/1-2004 2/1-2004 3/1-2004 3/1-2004 4/1-2004 4/1-2004
Type
Purchase 1 Transfer 1 Transfer 1 Transfer 2 Transfer 2 Transfer 3 Transfer 3 Transfer 4 Transfer 4
Item Warehouse Qty

R1 R1 R1 R1 R1 R1 R1 R1 R1 A A B B C C D D A 10 10 10 10 10 10 10 10 10
Price
100 10 10 10 10 10 10 10 10
Adjustment
90 +90 90 +90 90 +90 90 +90
It can be difficult to detect this round trip situation in advance. Microsoft Axapta has therefore always used the same strategy for both item transfers and BOM levels. The cost value must be moved around and adjusted on each reflected transaction. This principle can help ensure that the real cost or actual value of the actual inventory is correct. However, it can also be a difficult strategy to execute, as it requires full tracking information on each inventory transaction. Maintaining this tracking information and updating it further during cost value recalculations can be a resource-demanding task. Circularity From a technical viewpoint, one of the most challenging issues regarding item transfers is the concept of circularity. Since the inventory on-hand is allowed to go negative, both physically and financially, it is therefore possible to move items that do not actually exist from one warehouse to another. If that occurs, a circular costing reference may occur. The challenge can be explained through the following example.
Date
1/1-2004 1/1-2004 1/1-2004 1/1-2004 1/1-2004
Type
Purchase 1 Transfer 1 Transfer 1 Transfer 2 Transfer 2
Item Warehouse Qty

R1 R1 R1 R1 R1 A A B B A 1 10 10 10 10
Price
? 10 10 10 10
Adjustment
25
The physical on-hand inventory level as of January 1, 2004, is only 1, but it is possible to move a quantity of 10 from warehouse A to warehouse B, as negative physical inventory is allowed. The cost price is estimated at 10, and the value is transferred to warehouse B. The items are then moved back to warehouse A. If it turns out, upon receiving the purchase order invoice, that the actual cost price for the ordered quantity is 100 instead of 10, then the following warehouse A transactions will exist:
Date
1/1-2004 1/1-2004 1/1-2004
Order type
Purchase 1 Transfer 1 Transfer 2
Qty
1 10 10
Settled qty
Price
100 10 10
The recalculation function will try to correct the cost value, as it is obvious that the value of the transferred items on transfer order 1 is incorrect. From a technical perspective, two equal receipts exist. The recalculation will assume that the moved quantity comes from the purchase and from transfer order 2. A new price is calculated for the transferred items in the following way: Price = (1 x 100) + (9 x 10/10) = 190 /10 = 19 The transactions will be calculated as shown in the following table:
Date
1/1-2004 1/1-2004 1/1-2004
Order type
Qty
1 10 10
Settled qty
1 10 9
Price
100 19 10
The new price for the transferred items will then be adjusted on all reflected transactions across all warehouses, as shown in the next table:
Date
1/1-2004 1/1-2004 1/1-2004 1/1-2004 1/1-2004
Type
Purchase 1 Transfer 1 Transfer 1 Transfer 2 Transfer 2
Item
R1 R1 R1 R1 R1
Warehouse
A A B B A
Qty
1 10 10 10 10
Price
? 10 10 10 10
Adjustment
9 9 9 9
Because items loop in a circuit, a reevaluation of the transfer transactions on warehouse A must be performed. The first recalculation of cost prices on warehouse A is incorrect, and the cost price must be recalculated again.
Date
1/1-2004 1/1-2004 1/1-2004
Order type
Qty
1 10 10
Settled qty
1 10 9
Price
100 19 19
The revaluation is done according to the following calculation: Price = ((1 x 100) + (9 x 19))/10 = 271 /10 = 27.10 This new cost price is again transferred through all warehouses until it ends up at warehouse A, which results in a new revaluation being necessary.
26
This is how Microsoft Axapta handles loops or circularities in the costing process. The cost price proceeds toward a final and correct value. However, it can be difficult to know in advance the number of loops required before the correct value is achieved, which can cause the perception of poor program performance as multiple loops are calculated.
Quarantine Order Functionality

This section describes the functionality of quarantine orders seen from a costing perspective. The use of quarantine orders has the same functionality as two transfers. For example, if a quantity of 10 items is transferred from warehouse A to quarantine warehouse Q and back again at the end of the quarantine order, four transactions have been posted: 10 from warehouse (A) as an issue +10 to warehouse (Q) as a purchase 10 from warehouse (Q) as an issue +10 to warehouse (A) as a purchase
Warehouse (A) -10
Warehouse (Q) +10 -10 Transfer 1 Transfer 2
+10
Figure 22: Quarantine orders
Even though the transactions have the same Lot IDs, the posting will be treated as if it had been two separate transfers. This means that if the quarantine warehouse (Q) had received more than 10 of the specific item with a different cost price, the ending of the quarantine order of the 10 items can result in an issue with a different cost. This is because all transactions will be using the selected inventory model (for example, the Weighted average date model). During recalculation and closing, the program makes settlements based on the principle that the transactions are seen as different receipts and issues. There is no link between the receipt in Transfer 1 and the issue in Transfer 2.
On-hand and Physical Inventory and Financial Inventory Dimensions

This section describes the set up and use of Storage dimensions, from a costing perspective. It can be challenging for customers to get the correct overview of the costing issues between the physical and financial inventory, for example, for the on-hand information for an item, if only the Physical inventory field or only the Financial inventory field have been selected for the same dimension (that is, this situation does not occur when both of these fields are selected or cleared). We can use the following example of a dimension setup:
27
Figure 23: Included physical inventory, but not financial inventory
In the Storage dimensions setup illustrated in Figure 23, the Physical inventory field is selected for the Warehouse and Location dimensions, but the Financial inventory field is not selected on either of these dimensions From a costing perspective, when posting receipts and issues between, for example, different warehouses, the values in this case would only relate to the physical inventory per dimension. This is because the cost between the warehouses is seen as a summarized cost (and the Financial inventory has not been selected).
Figure 24: Financial and physical inventory cost
The on-hand inventory information in Microsoft Axapta is based on the inventory dimensions selected in the Dimensions display form. In this case, when users select the Warehouse and Location inventory dimensions, the Financial cost amount field in the Onhand form contains an amount that is not necessarily correct due to the fact that only the summarized amount can be trusted.
28
Figure 25: Dimensions display and on-hand
It is only when selecting the financial dimensions that the amount can be trusted.
Figure 26: On-hand with the same financial dimension display as in Fig 24
Of course, the physical inventory information can be used with the different dimension displays, but the connection between physical and financial inventory should only be made when using the same dimension display for physical inventory and financial inventory.
Impact of the Include Physical Value Field on Transaction Dates

Selecting the Include physical value check box in connection with inventory closing means that also only physically updated transactions are considered. This applies to both issues and receipts.
Figure 27: Include physical value
29
Users can select the Include physical value check box so that the program will calculate a better estimate of average cost price when posting issues. However, this means that also physically updated transactions (received and deducted) are settled when running an inventory closing. It is always the physical date on the inventory transactions that is used when running an inventory closing, regardless of whether physically updated transactions are included in the closing. This functionality can be confusing, especially when settlements are made using FIFO or LIFO. The financial date on the transactions has a lower priority. In theory, using FIFO means users want to count the transactions when they are physically updated, not financially updated. The physical transactions are included as described above for Microsoft Axapta 3.0, SP2 and later. In Microsoft Axapta 2.5 the functionality is different. For example, imagine the following scenario: On the January 1, 2005, items are packing slip updated for PO#1. For PO#2 the packing slip update is done on January 5, 2005, and invoiced on January 10, 2005. The invoice for PO#1 is made January 15, 2005.
Physical
Physical
Figure 28: PO#1 and PO#2
If Include physical is cleared and the inventory is closed on 12 January, then only PO#2 is included in the calculations. However, if Include physical is selected, then both purchase orders are included (this applies only in version 3.0 SP2 and later). In both scenarios the physical date is used when listing the receipts.
Marking in Microsoft Axapta 3.0

If users only need to mark and calculate true cost prices on a few specific orders, using inventory dimension reservation is not the most suitable solution. As the inventory dimension concept can be quite complex, a simple alternative, marking functionality, has been reintroduced in Microsoft Axapta 3.0. The marking functionality in Microsoft Axapta 3.0 allows purchase orders to point to individual sales orders independent of selected inventory dimensions. The marking functionality is not the same as in Microsoft Axapta 1.5. The most important technical difference is that a marked inventory transaction does not point exactly to another inventory transaction. The marking functionality in Microsoft Axapta 3.0 only marks item lots and can be regarded as a soft marking. If the marking is carried out across financial inventory dimensions, the marking is ignored in connection with inventory closing and recalculation. It is primarily the way that users set up the inventory dimensions of the financial inventory that decides what can be marked. A marking is only valid if the selected item lots have
30
identical values in the inventory dimensions that are included in the financial inventory. For example, if users operate with an item in connection with warehouses, then issues in warehouse A can only be marked on receipt in warehouse B if the warehouse dimension is not included in the financial inventory. On the other hand, if the warehouse dimension is included in the financial inventory, this will not be possible. Users must be aware that it is not possible to carry out manual markings if the item requirements have been transferred to picking on output orders or to picking list registration in the Sales order form or Production orders forms. Conditions for Marking When the inventory is closed or adjusted, item issues and item receipts are settled according to the marking, if the following three conditions are fulfilled: 1. Batch or serial numbers, which are included in the financial inventory, are not used (this limitation has been removed in version 3.0 SP3). 2. Marking has not been implemented across the inventory dimensions that are included in the financial inventory. 3. Both issues and receipts are financially updated up to and including the closing date. If condition 1 or 2 is not fulfilled, the program cancels the marking automatically and transactions will then be closed or adjusted, just as if the transactions had not been marked. If condition 3 is not fulfilled, the issue transactions are not settled in connection with the current closing but the marking is kept. Note that unsuccessful closing of marked transactions as a result of not fulfilling condition 3 can result in an on-hand inventory with a value but without a quantity. Further details of marking functionality are described in the technical documentation Marking provided on the Microsoft Axapta 3.0 installation CD.
Multi-User Inventory Closing Based on Number of Transactions

Using multiple clients to close inventory or recalculate can enhance program performance. However, because closing and recalculation are based on the number of items with transactions, there are no performance enhancements if only one item number exists or if one item number has all the inventory transactions. Furthermore, if the number of clients is similar to the number of items or items with inventory transactions, adding extra clients will not make any additional performance enhancement.
31
Figure 29: Calculation list showing only two items
If, as illustrated in Figure 29, only two items exist or only two items have inventory transactions, it is illogical to use more than two clients to close or recalculate the inventory.
Multi-User Inventory Closing and Cost Calculation

When inventory closing or recalculation is in progress using multiple clients, and the actual adjustments on the inventory transactions have to be calculated, the first client makes a calculation list. Multi-user inventory closing (MUIC) clients continue cost calculation of the next item in the calculation list within the first level. This list is a complete list of items that have to be calculated during closing or recalculation. During the calculation process, items that have to be recalculated or just calculated will continue to be added to this list the following reasons:

Items adjusted that appear as BOM lines will adjust the BOM item Looping between dimensions Items adjusted that appear as production lines will adjust the finished BOM item
32
Figure 30: Calculation list
For example, if item close005subit in the Figure 30 is a component of item Close001 and both are adjusted, item Close001 will be added to the calculation list for the second calculation level. First Loop in the Calculation List MUIC clients are not forced to wait until all clients have finished calculating with the current item, they only wait for the additional items that are inserted in the calculation list. The first loop is the initial calculation of the items in the calculation list on level one. Because the assisting clients do not wait for other clients to finish calculation of the current item in the first calculation level it means that one client can calculate one item while two other clients calculate 10 items, depending on the number of transaction on each item. Additional Loops in the Calculation List After the first loop, the additional loops in the calculation list involve the calculation of items in the calculation list on level two or above. The assisting clients have to wait for other clients if no more items exists on the current level. Only after one level has completed the clients begin on the next level. Spreading Inventory Transactions Over a Minimum of Items Due to the method (described in the previous section) that Microsoft Axapta uses to handle the calculation load when closing or recalculating, it is strongly recommended that users spread inventory transactions over a minimum of items. If users have all inventory transactions on one item, cost calculation will be made solely on one client. Methods to avoid having all inventory transactions on one item:
Try to eliminate the use of item configurations if the business revenue is based on one item. It is, from a closing performance perspective, preferable to have multiple items instead of a few items using configuration with all transactions. It is, however, not very common to have so few items that the number of closing clients is higher that the number of items with the majority of transactions. If all inventory transactions are to be made on one item because, for example, the business revenue is based on one item, it is recommended that users make more item numbers for the same item. To do this, users should split the inventory
33
transactions by having multiple item numbers for the physically identical item. For example, having one item for each salesperson, region, or area. The issue of spreading inventory transactions over a minimum of items does depend somewhat on the chosen cost model. The standard cost (that is, FIFO cost model and when standard cost is selected on the inventory model group) closes transactions much faster than with Weighted average cost model. This recommendation, to spread inventory transactions over a minimum of items, can be critical for program performance. Users should note that, if they have all inventory transactions on one item, it could result in a situation where it simply isnt possible to do inventory recalculation or closing.
Minimum Throughput Adjustment

The Minimum throughput adjustment field, which can be found in the Close inventory form, under Advanced, is an inventory closing parameter that is not only used in looping or circularity. The program also uses this parameter for settlements that have to be passed from one transaction to another, which is the case in transfers, production lines, BOM lines, crediting transactions, quarantine transactions, and WMS transports (pallet transports). Closing The following example illustrates the way that the program uses the Minimum throughputs adjustment parameter when transferring 10 items from one financial dimension to another (warehouse WH1 to warehouse WH2):
Transaction
1 2
Warehouse
WH1 WH2
Qty
10 10
Cost
$10.0 $10.0
Adjustment
Total
$10.0 $10.0
An adjustment to transaction 1 will have to be passed on to transaction 2:
Transaction
1 2
Warehouse
WH1 WH2
Qty
10 10
Cost
$10.0 $10.0
Adjustment
2 2
Total
$12.0 $12.0
If the adjustment is below the value of the Minimum throughput adjustment parameter, the adjustment will be posted as a profit/loss to the second transaction. In this example, if the Minimum throughput adjustment parameter was higher than two, the adjustment would not be passed to the receipt transaction but instead posted as a profit/loss. The business logic behind this functionality is actually two adjustments to the second transaction. First the adjustment passed from the original transaction, and then a profit/loss adjustment:
Transaction
1 2
Warehouse
WH1 WH2
Qty
10 10
Cost
$10.0 $10.0
Adjustment
2 +2 and2
Total
$12.0 $10.0
Recalculation The following example illustrates that the program manages recalculation differently from closing. If users carry out the same adjustment described in the previous example and then run a recalculation the result will be slightly different.
34
Transaction
1 2
Warehouse
WH1 WH2
Qty
10 10
Cost
$10.0 $10.0
Adjustment
2 2
Total
$12.0 $12.0
The adjustment should always be passed to the second transaction. However, the adjustment should be disregarded in further calculations if the adjustment is below the minimum throughput adjustment value. After a recalculation, an item may show an inventory value even though there is zero onhand. This should be corrected by an inventory closing which posts the difference as a profit/loss.
Different Average Cost Values Within the Same Period Using the Weighted Average Date Cost Model
The Weighted average date cost model in Microsoft Axapta means that item issues are valued at an average value, based on the items that make up the inventory value, which consists of open item receipts falling on a date before the item issue. Using this model means that the average cost is calculated as an average of the cost value based on receipts within the same financial dimension. The receipts are only included as long as they arent fully settled, so the average cost will fluctuate as the cost of the receipts changes. However, when the on-hand inventory reaches zero, the current average cost is reset even if it is in the middle of a month.
Transaction
1 (Issue) 2 (Receipt) 3 (Receipt) 4 (Issue) 5 (Receipt)
Qty
10 10 2 10 10
Avg. cost
$10.0 $10.0 $12.0 $12.0 $12.0
Date
1 Jan. 2004 2 Jan. 2004 5 Jan. 2004 6 Jan. 2004 7 Jan. 2004
In this example, the on-hand is zero between January 2, 2004, and January 5, 2004, so the average is reset in the middle of January. The following example illustrates how the average cost can vary a lot within the same period:
Item number
AVG RESET AVG RESET AVG RESET AVG RESET AVG RESET AVG RESET AVG RESET
Financial date
01-12-2004 02-12-2004 27-12-2004 27-12-2004 28-12-2004 28-12-2004 30-12-2004
Reference
Purchase order Purchase order Sales order Sales order Purchase order Purchase order Sales order
In/Out
Receipt Receipt Issue Issue Receipt Receipt Issue
Cost Avg. Quantity amount Cost

10 10 5 15 95 5 1 400 500 225 675 7500,25 500 80 40 45 45 45 78,95 80 80
Onhand
10 20 15 0 95 100 99
In this example, the on-hand is zero on January 27,2004, so the average is reset and two very different average costs are used: 45 and 80.This situation only applies when the Weighted average date cost model is being used.
35
Different Results of Recalculation and Inventory Closing

Running recalculation and inventory closing can produce different results, even though the parameter setup is the same. This is because the methods that the program uses for recalculation and closing are not the same. From a technical perspective, there are different methods because of the way Microsoft Axapta handles remainders in iteration loops (this is valid after installation of Red delivery or version 3.0 SP4). Example Illustrating the Different Results In this example, a transfer needs to be adjusted in one of the iterations by 2.00 and in the next iteration loop by 0.50. However, the precision parameter amount should be more than 1.00 before it is taken into account. The following shows how, in this specific example, inventory closing and recalculation can produce different results. Closing The method that Microsoft Axapta uses for inventory closing is to post the remainder and not take the 0.50 adjustment into account. Issue 100.00 +2.00 +0.50 Receipt 100.00
+2.50 0.50 This shows that the inventory adjustment of 2.00 needs to be matched to the finance posting with an adjusted settlement of the missing 0.50. Recalculation The method that Microsoft Axapta uses for recalculation is to use the remainder without taking the adjustment of the 0.50 into account, therefore making an extra iteration loop compared with the closing method. Issue 100.00 +2.00 +0.50 Receipt 100.00
+2.00 +0.50 The recalculation does not result in the program posting the remainder from the inventory and reusing the settlements at the next recalculation. This means that a new calculation is performed every time the recalculation is run and it gets more and more precise. Overall, this means that the result of the recalculation can be more precise than that of the closing. However, the result of a closing can be more precise if one or more recalculations have been run before a closing is run. The recalculation is not the final calculation, therefore the result can be a financial amount but no inventory. This difference will be removed when running the final calculation in the inventory closing.
Modified Date and Consistency Check

Users can run a consistency check of the inventory module in Microsoft Axapta on transactions that are modified after a selected date. This requires that the Modified date property has been set to Yes for the Inventory transactions table. If this property is set to No, all transaction will be checked. Microsoft Axapta development recommends that the Modified date field on the Inventory transactions table is enabled (set to Yes) in order to exclude some inventory transactions from the consistency check in order to improve performance. If a transaction record has
been checked once there is no reason it should be checked again later if it hasnt be modified. The consistency check recalculates the following fields: Value open, Financially closed, Settled quantity, Amount settled, and Adjustment fields. The following example is a description of how these fields that are important to inventory closing are affected by the consistency check. Value Open (VO) Field If the transaction is a packing slip, returned VO is set to No. If the amount and quantity are fully settled, VO is set to No. Financially Closed Field If the Value open field is set to No and there is no financially closed date, then the program corrects the financially closed date to the last settlement date. Inventory transaction is corrected according to the sum of the settlements Settled quantity field = Sum of all settlements quantity Amount settled field = Sum of all settlements amount Adjustment field = Sum of all settlement adjustments The following is a description of how to run the consistency check for inventory. For more information, see the Technical Information document Consistency check. In the Consistency check form, in the Module field, select Inventory management. In the Check/Fix field, select Check to check for warnings or select Correct errors to get the program to correct data if possible. In the From date field, select the required date. Microsoft Axapta will run the consistency check on transactions that are modified after the selected date. This field will only be used if the Modified date field is enabled on the individual tables in the Application Object Table.
Figure 31: Running a consistency check
37
Figure 32: Example of the InventTable
As shown in Figure 32, when running a consistency check, users are recommended to enable the ModifiedDate field in the Inventory transactions table and in other tables where appropriate. The consistency check will reopen inventory transactions if, for example, settlements are not created and the logic rules are broken. This could be the case after conversion of data from an old system. In this case only new transactions should be checked in order to avoid reopening the converted transactions by utilizing the modified date.
Readjusting Inventory Adjustment During Closing and Recalculation

When users are doing inventory adjustments, there are a few things that need to be considered. Microsoft Axapta offers the user two ways of doing inventory adjustments: 1. Transaction adjustments This option is used for adjusting selected receipts. For example, a purchase order can be adjusted if the cost has changed. This option will also be used if a selected batch has exceeded its expiry date. These receipts will never be affected by an adjustment during recalculation and closing, except when using standard cost on the model group. 2. On-hand adjustments This way of adjusting is used for an adjustment of the total on-hand inventory of selected items, for example, after the periodic counting or just before the end of a year. This adjustment option may result in adjustment of all open inventory receipt transactions, which includes transfers that could be readjusted during closing or recalculation (this should no longer be the case after the Red package or version 3.0 SP4).
38
In version 3.0 SP4 (or installations with the Red packaged installed), whenever the cost value of a receipt is to be adjusted, the program makes a check as to whether the receipt has been on-hand adjusted. If so, the receipt is actually adjusted then removed again. The removal will create a loss/profit posting. If the receipt has not been on-hand adjusted, the adjustment is made as a normal adjustment. In order to quickly find out if a receipt has been on-hand adjusted, there is a minor change to the way that Microsoft Axapta posts on-hand adjustments. Before Microsoft Axapta 3.0, SP4, with on-hand adjustments, the adjustment would be divided among all open transactions. If the adjustment is small or the number of open transactions is large, some open transactions might not be adjusted, as the adjustment would be zero and an adjustment of zero would not lead to the creation of adjustment transactions of zero. Now, in Microsoft Axapta 3.0, SP4, even an on-hand adjustment of zero on a transaction will lead to the creation of an on-hand adjustment transaction of zero. This, however, can result in a situation where, for example, item A is counted and valued to be exactly correct (no adjustment) and item B is adjusted to a lower cost than the existing one. This will mean that, during closing receipts, transactions can be readjusted for item A but not for item B. With the current functionality in the On-hand adjustment form, it is not possible to mark that the cost value is actually exactly correct. If users set the adjustment to zero, the program does not lock the cost value. This is an issue under consideration for Microsoft Axapta 4.0. Transaction Splitting This is standard, unchanged functionality that is part of Microsoft Axapta 3.0. When a receipt transaction is partly settled and users make an on-hand adjustment for this item, the transaction is split into two transactions, one open and one closed. This is illustrated by the following example: Two transactions on an item, a purchase and a sales order, will be split as follows:
Type
PO SO
Date Open
1/1 2/2
Qty.
10 4
Cost Settled Value Qty.

100 40
Settled Value
Adjustment
Value Open
Yes Yes
The inventory is closed at the end of February:
Type
PO SO
Date Open
1/1 2/2
Qty.
10 4

100 40 4 4
Settled Value
40 40
Adjustment
Value Open
Yes No
The item is on-hand adjusted with a value of 10 in March:
Type
PO PO SO
Date Open
1/1 1/1 2/2
Qty.
6 4 4

60 40 40 4 4
Settled Value
40 40
Adjustment
10
Value Open
Yes No No
Note that the purchase order (PO) is split and the fully settled transaction is closed on the last closing date.
The fact that a partly settled transaction is split during an on-hand adjustment can have a significant impact on the numbers of inventory transactions if the user is using one of the average cost models. Using an average cost model, the inventory closing parameters Minimum settle quantity percent and Minimum settle amount will, together with the general inventory parameter Minimum Average quantity, be important for the number of open and partly settled transactions which will be split during on-hand adjustment. However, using a non-average cost model almost eliminates transaction splitting. For example: Imagine that an item is purchased using 100 purchase orders with a quantity of 10 units and one sales order is invoiced with a quantity of 3 units. Using an average cost model, all 100 inventory transactions from the purchase orders can be split during on-hand adjustment. (The number of partly settled transactions depends on the inventory closing parameters mentioned previously, so it might be fewer than 100 transactions.) However, using a non-average cost model, FIFO, only the first transaction is split.
Running Inventory Value Reports

It is essential to run all inventory value reports the same day the inventory closing has run in order to get inventory values that are accurate. This applies when running with negative inventory where issue transactions are larger than receipt transactions. The correct cost price will not be available for the issue transons as the information is not present (there are not enough receipts). The following examples illustrate that the correct inventory value can only be obtained at the inventory close date. Example 1: 1. Issue 1 at a cost price of 100. 2. Receive 1 at a cost price of 80. 3. Run inventory closing. The inventory value reports will show an incorrect inventory value between the receipt and the closing of the inventory. At the inventory closing, the inventory value reports are correct.
Example 2: 1. Issue 2 at a cost price of 100. 2. Receive 1 at a cost price of 80.

3. Run inventory closing. This example shows that the inventory value is too high between the receipt and the inventory closing. After the closing, the inventory value report uses the cost price from the item master. This cost price is the best estimate to use for the inventory value report.
Closing Adjustment of 20 SO -2@100
Inventory value -1@-120
PO +1@80
Example 3: 1. Issue 2 at a cost price of 0. 2. Receive 1 at a cost price of 80. 3. Run inventory closing. This example shows that the inventory value report will use the cost price of 0 from the item master and will state a quantity of 1, starting from the receipt transaction and continuing till after the inventory closing. The inventory value report will only be correct after an additional receipt transaction of 1 and a new inventory closing. Then the inventory value report will be correct for the inventory closing date.
Closing Adjustment of 80 SO -2@0
PO +1@80
Error Messages When Using Multi-user Inventory Closing

When using MUIC (for example, with four clients running simultaneously) the clients can potentially stop intermittently and the error message "...Deadlock in table PRODTABLEJOUR..." appears. The following is a screenshot of this message. The error message: "The value 1 is not found in the map" is also shown.
41
To address this issue, customers system administrators must add one line in the InventCostItemDim\run before the first while loop: loopX = 0; as shown in the following:
else { this.updateSettleRefItem(inventCostList.ItemId); mapLoopTrans mapLoopDim loopX = new map(types::INTEGER,types::RECORD); = new map(types::INTEGER,types::RECORD); = 0;
queryRun = inventCostHelp.initQueryRunTrans(this.inventTable(inventCostList.ItemId)); while (queryRun.next()) { loopX++; mapLoopTrans.insert(loopX,queryRun.get(tableNum(InventTrans))); mapLoopDim.insert(loopX,queryRun.get(tableNum(InventDim))); } loopMax = loopX; loopX = 0; while (loopX < loopMax) { loopX++; this.updateItemDim(mapLoopTrans.lookup(loopX),mapLoopDim.lookup(loopX)); } }
Status of Known Issues (Red Delivery)

The section describes in more detail the known issues that are addressed in the Red delivery for Microsoft Axapta 3.0 from SP2 and later. Under Certain Circumstances Microsoft Axapta Makes a Double Recalculation Issue When returning quantities on an invoice purchase order, the returned quantity was marked and settled against the quantities already received. If yet another return was made on a receipt, the return could, under some circumstances, return quantities that had already been marked and settled as returned. This issue also existed when making multiple returns on sales credit notes by re-invoicing the quantity. They both fall within the same category: returning receipts.
42
At the same time, an issue existed when returning quantities on a sales credit note, where the credited quantity was marked against the invoiced quantity. When posting the return on the credit note, the returned quantity was still marked against the invoiced quantity leading to a discrepancy between the quantity marked from the credit note to the invoice, and the marking from the invoice to the credit note. Cause The issues arose because of a lack of checking on whether a quantity about to be returned had either already been marked as returned within the same lot, or whether it was marked as returning a different lot. The program did not allow for the situation where the quantity could be marked as returned already. Solution Both of the issues described have been addressed so that either a transaction that has already been returned will not be returned again, or the returned quantity marking will be cancelled. Serial Numbers and Weighted Average Issue When using the Weighted average or Weighted average date inventory models, a closing could potentially look like it had used FIFO instead. This was due to the assignment of serial numbers when large lot sizes were broken into many transactions with small quantities. This would potentially also be an issue for multiple batch numbers that had a lot with small quantities per batch. Cause The issue was caused because, when settling inventory receipts, Microsoft Axapta settled in creation order and with a minimum quantity of at least 0.01. A large lot which was split into multiple transactions would be settled first, and a settlement of a quantity on a transaction with a small quantity would be rounded up to the lowest possible quantity to settle: 0.01. So an issue transaction with a small quantity might be completely settled against only transactions from one lot, leading to a cost amount that was more similar to a FIFO principle calculation than Weighted average. Solution Instead of settling receipts in creation order, Microsoft Axapta now settles so that transactions from each financially open lot are considered equally. First the first transaction from each lot is settled, then the second transaction from each lot is settled, and so on. Inventory Closing and Recalculation with Incorrect Costs in Microsoft Axapta 3.0, SP3 Issue Incorrect issue transaction with a positive cost value could have caused looping in the inventory closing or inventory recalculation and may have led to a numeric value out of range error due to extremely high cost values. Cause An issue transaction should never contain a positive cost value. It should always be negative. Microsoft Axapta, when closing or recalculating tried to workaround this issue, but this unfortunately led to the addition of value instead of subtraction, leading to extremely high cost values and eventually a numeric value out of range error. Solution The workaround has been addressed so that cost values will not escalate. The positive cost value on the issue will also be corrected to a value of zero. Quarantine Order and Weighted Average DateLooping Issue Inventory transactions of the type Quarantine order related to the quarantine warehouse could, in some situations, remain unsettled and open after an inventory closing. The issue
43
could occur if the Weighted average date inventory model was selected. As a consequence, the quarantine warehouse could show a financial cost amount even though the on-hand was zero. Cause If the Weighted average date inventory model was selected then transactions of type Quarantine orders could never be settled against themselves. This should be possible for transactions related to the quarantine warehouse. Solution Transactions of type Quarantine order can now be settled against themselves. Incorrect Cost Adjustment Issue If a production had been costed, then recalculated where the production had been adjusted due to adjustments to the consumed raw material, then more items had been produced, and eventually the recalculation was cancelled, the production was left in a state where the cost value was not divided out equally per transaction. This was normally the case when the production was costed. If a new inventory recalculation or a closing was run, any adjustments to the production were calculated incorrectly as it was assumed that the cost value was divided equally among the produced items. This would lead to incorrect cost amounts on the production. Cause The issue was caused by the presumption that the cost value was always divided out equally among the produced items, when the production should be adjusted due to adjustment to the consumed raw material. Solution The adjustment from production line to production in the inventory closing has been changed so that adjustment to production will not only divide out the adjustment amount, but also make sure that the total cost value is divided equally per transaction. Huge Amounts After Closing Issue After an inventory closing, the cost amounts on productions were huge. Cause The issue was caused by the settlement transaction number, which had been set to manual. Therefore, the number sequence did not return any numbers, and the link between settlements on receipts and issues was missing. Adjustments on receipts, which should have been forwarded to the issues, were therefore incorrect as the adjustment was forwarded to incorrect issues, which eventually led to huge cost amounts on the issues. Solution The number sequence should not be allowed to be manual. Before closing, a check is made that a number sequence exists and that the number sequence is not set to manual. In order to catch any other issues, the closing will return an error message at run time if the number sequence does not return any number. Latest Cost Price With Quarantine Orders Issue The cost price on the item was incorrectly updated when a quarantine order had ended. Cause If the Latest cost price parameter was selected on the item, then the cost price was always updated when a receipt was financially updated. This was the case regardless of the type of transaction.
44
Solution Inventory transactions of the type Quarantine orders will never update the item cost price. Multiple Inventory Recalculations Cause Incorrect Costs Issue If inventory recalculations or closings were performed on a date prior to an existing recalculation, the new recalculation or closing might, in some circumstances, have generated incorrect cost amounts. In addition, the inventory costs would most likely have been incorrect if reports were created on the date when the existing recalculation was run. Cause The reasons for this issue was that the existing recalculation made the same adjustments as the new recalculation or closing run afterwards, but with a date prior to the existing recalculation. The adjustments would therefore be doubled. Solution It is no longer allowed to run an inventory recalculation or closing with a date prior to an existing recalculation. The existing recalculation has to be cancelled first. It is therefore only possible to run a recalculation or closing on a date after or on the same date as an existing recalculation. Before recalculating or closing, Microsoft Axapta will therefore give users the chance to cancel all recalculations dated after the current execution date. After an inventory closing, Microsoft Axapta will also give users the chance to run a new recalculation on the present days date. Additionally, it is also only possible to cancel recalculations in the reverse order to that in which they were executed, in order to help ensure that no recalculations are run prior to an existing recalculation. For more information, see the flow chart in Figure 33 that shows the new closing and recalculation process.
Figure 33: Closing/recalculation process flow
Conclusion
This document provides a detailed description of the inventory closing process in Microsoft Axapta 3.0 and its associated service packs. It also explains the steps that Microsoft Axapta development has taken and expects to take in the future to address the inventory closing-related issues that have been reported. For further information, refer to the flow chart in Figure 34 as a guide to addressing inventory-closing issues. In this flow chart, there are links to relevant sections in this document. In order to get back to the flow chart after following a link, press CTRL+END.
45
References
Technical Information Microsoft Axapta Multi-user Inventory Closing Technical Information Recalculation: Simulated Inventory Closing
About Microsoft Business Solutions

Microsoft Business Solutions, a division of Microsoft, offers a wide range of integrated, end-to-end business applications and services designed to help small, midmarket, and corporate businesses become more connected with users, employees, partners, and suppliers. Microsoft Business Solutions' applications optimize strategic business processes across financial management, analytics, human resources management, project management, user relationship management, field service management, supply chain management, e-commerce, manufacturing, and retail management. The applications are designed to provide insight to help users achieve business success. More information about Microsoft Business Solutions can be found at http://www.microsoft.com/BusinessSolutions/
About Microsoft Business SolutionsAxapta

Microsoft Axapta is business management solution created specifically to help mediumsized businesses quickly seize opportunity and improve their competitive advantage. It offers rapid implementation and scalability whether a user is one location, has multiple sites, or is conducting business across borders. With multicurrency and multilanguage features, Microsoft Axapta supports companies expanding operations internationally.
2005 Microsoft Corporation. All rights reserved. Microsoft and Axapta are either trademarks or registered trademarks of Microsoft Corporation or Microsoft Business Solutions ApS or their affiliates in the United States and/or other countries. Microsoft Business Solutions ApS is a subsidiary of Microsoft Corporation. The names of actual companies and products mentioned herein may be the trademarks of their respective owners. The information contained in this document represents the current view of Microsoft Corporation on the issues discussed as of the date of publication. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information presented after the date of publication. This document is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS DOCUMENT. Complying with all applicable copyright laws is the responsibility of the user. Without limiting the rights under copyright, no part of this document may be reproduced, stored in or introduced into a retrieval system, or transmitted in any form or by any means (electronic, mechanical, photocopying, recording, or otherwise), or for any purpose, without the express written permission of Microsoft Corporation. Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering subject matter in this document. Except as expressly provided in any written license agreement from Microsoft, the furnishing of this document does not give you any license to these patents, trademarks, copyrights, or other intellectual property.
46
Help
Help Help
Help
Help
Help
Help
Help
Help
Help
Figure 34: Inventory closing setup flow chart

Ax30 Inventory Closing Whitepaper 2onded

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Ax30 Inventory Closing Whitepaper 2onded

Încărcat de

Drepturi de autor:

Formate disponibile

Microsoft Axapta Inventory Closing White Paper

CONFIDENTIAL DRAFT INTERNAL USE ONLY

Inventory Closing-Related Issues in Microsoft Axapta

Microsoft Axapta Inventory Closing White Paper

How to Detect Issues in Inventory Closing

Potential Triggers of Inventory Closing Issues

Microsoft Axapta Inventory Closing White Paper

Microsoft Axapta Inventory Closing White Paper

Inventory Closing Red Delivery

Microsoft Axapta Inventory Closing White Paper

Figure 1: Report to check for receipts with incorrect cost price

Microsoft Axapta Inventory Closing White Paper

Inventory Closing Periodic Closing and Recalculation

Incorrect inventory value

Figure 2: Periodic closing and recalculation

03-06-2004 Transfer 3 03-06-2004 Transfer 3

-100 100 10 -100 100 -100

-100 100 100 -100 100 -100

Inventory Closing Yellow Delivery

Inventory Closing Green Delivery

Microsoft Axapta Inventory Closing White Paper

Other Inventory Closing-related Issues and Recommendations

Pre-closing Data Report

Microsoft Axapta Inventory Closing White Paper

Figure 3: Pre-closing data report, purchase lines

Microsoft Axapta Inventory Closing White Paper

Figure 4: Production orders reported as finished

Figure 5: Pre-closing data report, production with open subproduction

Partial Production Order Costing

Microsoft Axapta Inventory Closing White Paper

Figure 6: Create the production order of five units

Microsoft Axapta Inventory Closing White Paper

Figure 7: Estimated cost calculation

Figure 8: Start of the production order

Microsoft Axapta Inventory Closing White Paper

Figure 9: Report two units finished

Figure 10: Costing of the two units

Microsoft Axapta Inventory Closing White Paper

Figure 11: Transaction for the item

Figure 12: After finally costing the production

Microsoft Axapta Inventory Closing White Paper

Figure 13: After closing the inventory

Beginning the Inventory Closing Process Unintentionally

Inventory Closing Technical Documentation

Microsoft Axapta Inventory Closing White Paper

LIFO (Last In First Out) LIFO date

Weighted average date

LIFO in Microsoft Axapta

Figure 14: Order of settlements in Axapta LIFO

Microsoft Axapta Inventory Closing White Paper

Balancing Performance with Accuracy When Closing or Recalculating

Microsoft Axapta Inventory Closing White Paper

Figure 16: Expanded Close inventory dialog

Microsoft Axapta Inventory Closing White Paper

After the first month all 100 units are sold:

100 -50 100 -100

1000 -500 1000 -1000

Sales order 2 Purchase 3

After the third month:

100 -50 100

1000 -500 1000

Sales order 2 Purchase 3

Sales order 4 Purchase 5