Microsoft Axapta Inventory Closing White Paper

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 Solutions–Axapta ..................................................................... 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.
Microsoft Axapta Inventory Closing White Paper 1

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 deliveries—Red, 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 R2 R3 R4 R5 R6 R7 R8
Day 0 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.

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.
Ware- Physical & Reference Receipt Qty Cost Lot Physical Financial Adjust- Profit & Settled Cost Cost financial
house Financial - amount ID Cost Cost ment Loss, quantity 2 updated
date Issue amount amount posted loops purchase
amount (Qty 10 Cost
100/pcs.)
MW 03-06-2004 Transfer 3 Sold -10 -190 00076 -100 -100 -90 100 -10 -190 -1000
GW 03-06-2004 Transfer 3 Purchased 10 190 00076 100 100 90 -100 10 190 1000
MW 03-06-2004 Purchase 18 Purchased 1 100 00075 10 100 1 100 1000
GW 03-06-2004 Transfer 4 Sold -10 -190 00077 -100 -100 -90 100 -10 -190 -1000
MW 03-06-2004 Transfer 4 Purchased 10 100 00077 100 100 -100 10 100 1000
MW 03-06-2004 Sales 17 Sold -1 -10 00078 -100 -100 90 100 -1 -10 -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
can’t be changed on an item—a 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 program’s security setup in order to limit the ability of others to
change configurations related to inventory closing. By default, users and administrators
can’t 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.

• 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 doesn’t 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.

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.

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.

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.

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 Definition

FIFO Item issues are always balanced against the first items received in
(First In First Out) inventory, based on the date of the inventory transaction.

LIFO Item issues are always balanced against the items received last in
(Last In First Out) inventory, based on the date of the inventory transaction.
LIFO date 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.
Weighted average 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.
Weighted average date 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.
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.

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:

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

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 Open New settle- Remainder

quantity ment
Purchase 1 100 1000 50 yes 50 50

Sales order 2 -50 -500 -50 no
After the first month all 100 units are sold:

quantity ment
Purchase 1 100 1000 83.33 Yes 33.33 16.67

Sales order 2 -50 -500 -50 No
Purchase 3 100 1000 66.67 Yes 66.67 33.33
Sales order 4 -100 -1000 -100 No
After the third month:

quantity ment
Purchase 1 100 1000 94.44 Yes 11.11 5.56

Purchase 3 100 1000 88.89 Yes 22.22 11.11
Sales order 4 -100 -1000 -100 No

Purchase 5 100 1000 66.67 Yes 66.67 33.33
Sales order 6 -100 -1000 -100 No
After the fourth month:

quantity ment
Purchase 1 100 1000 98.15 Yes 3.71 1.85

Purchase 3 100 1000 96.30 Yes 7.41 3.70
Sales order 4 -100 -1000 -100 No
Purchase 5 100 1000 88.89 Yes 22.22 11.11
Sales order 6 -100 -1000 -100 No
Purchase 7 100 1000 66.67 Yes 66.67 33.34
Sales order 8 -100 -1000 -100 No
After the fifth month:

quantity ment

Purchase 1 100 1000 99.38 Yes 1.23 0.62
Purchase 3 100 1000 98.77 Yes 2.47 1.23
Sales order 4 -100 -1000 -100 No
Purchase 5 100 1000 96.30 Yes 7.41 3.70
Sales order 6 -100 -1000 -100 No
Purchase 7 100 1000 88.89 Yes 22.23 11.11
Sales order 8 -100 -1000 -100 No
Purchase 9 100 1000 66.67 Yes 66.67 33.34
Sales order 10 -100 -1000 -100 No
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.

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 Type Nr Quantity Cost amount

1/1 Purchase order 1 100 1000

Date Type Nr Quantity Cost amount
2/1 Pallet transport 2 –100 –1000
2/1 Pallet transport 2 100 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 Adjustment
R1 100.75
R2 299.25
R3 –399.01
SUM 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

rich client in a two-tier installation, then the job is carried out on the user’s 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 user’s
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 Item Estimated price Known price Adjustment

1/1-2004 R1 10
2/1-2004 R2 20
3/1-2004 M1 30
2/2-2004 R3 40
3/2-2004 F1 70

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 Item Estimated price Known price Adjustment

1/1-2004 R1 10 +90
2/1-2004 R2 20
3/1-2004 M1 30 +90
2/2-2004 R3 40
3/2-2004 F1 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 Type Item Warehouse Qty Price Adjustment
1/1-2004 Purchase 1 R1 A 10 ?
1/1-2004 Transfer 1 R1 A –10 10
1/1-2004 Transfer 1 R1 B 10 10
2/1-2004 Transfer 2 R1 B –10 10
2/1-2004 Transfer 2 R1 C 10 10
3/1-2004 Transfer 3 R1 C –10 10
3/1-2004 Transfer 3 R1 D 10 10
4/1-2004 Transfer 4 R1 D –10 10
4/1-2004 Transfer 4 R1 A 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:

1/1-2004 Purchase 1 R1 A 10 100
1/1-2004 Transfer 1 R1 A –10 10 –90
1/1-2004 Transfer 1 R1 B 10 10 +90
2/1-2004 Transfer 2 R1 B –10 10 –90
2/1-2004 Transfer 2 R1 C 10 10 +90
3/1-2004 Transfer 3 R1 C –10 10 –90
3/1-2004 Transfer 3 R1 D 10 10 +90
4/1-2004 Transfer 4 R1 D –10 10 –90
4/1-2004 Transfer 4 R1 A 10 10 +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.

1/1-2004 Purchase 1 R1 A 1 ?
1/1-2004 Transfer 1 R1 A –10 10
1/1-2004 Transfer 1 R1 B 10 10
1/1-2004 Transfer 2 R1 B –10 10
1/1-2004 Transfer 2 R1 A 10 10

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 Order type Qty Settled qty Price

1/1-2004 Purchase 1 1 100
1/1-2004 Transfer 1 –10 10
1/1-2004 Transfer 2 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:

1/1-2004 Purchase 1 1 1 100
1/1-2004 Transfer 1 –10 –10 19
1/1-2004 Transfer 2 10 9 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:

1/1-2004 Purchase 1 R1 A 1 ?
1/1-2004 Transfer 1 R1 A –10 10 9
1/1-2004 Transfer 1 R1 B 10 10 9
1/1-2004 Transfer 2 R1 B –10 10 9
1/1-2004 Transfer 2 R1 A 10 10 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.

1/1-2004 Purchase 1 1 1 100
1/1-2004 Transfer 1 –10 –10 19
1/1-2004 Transfer 2 10 9 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.

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 Warehouse
(A) (Q)
-10 Transfer 1
+10
-10 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:

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 On-
hand form contains an amount that is not necessarily correct due to the fact that only the
summarized amount can be trusted.

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

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

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.

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

Figure 30: Calculation list
For example, if item close005–subit 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

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 isn’t 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 Warehouse Qty Cost Adjustment Total

1 WH1 –10 $–10.0 $–10.0
2 WH2 10 $10.0 $10.0
An adjustment to transaction 1 will have to be passed on to transaction 2:

1 WH1 –10 $–10.0 –2 $–12.0
2 WH2 10 $10.0 2 $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:

1 WH1 –10 $–10.0 –2 $–12.0
2 WH2 10 $10.0 +2 and–2 $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.

1 WH1 –10 $–10.0 –2 $–12.0
2 WH2 10 $10.0 2 $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 on-
hand. 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 aren’t 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 Qty Avg. cost Date

1 (Issue) –10 $10.0 1 Jan. 2004
2 (Receipt) 10 $10.0 2 Jan. 2004
3 (Receipt) 2 $12.0 5 Jan. 2004
4 (Issue) –10 $12.0 6 Jan. 2004
5 (Receipt) 10 $12.0 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 Financial Cost Avg. On-

number date Reference In/Out Quantity amount Cost hand
AVG RESET 01-12-2004 Purchase order Receipt 10 400 40 10
AVG RESET 27-12-2004 Sales order Issue –5 –225 45 15
AVG RESET 28-12-2004 Purchase order Receipt 95 7500,25 78,95 95
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.

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 Receipt
100.00 100.00
+2.00
+0.50
+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 Receipt
100.00 100.00
+2.00
+0.50
+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 hasn’t 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

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).

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 Date Qty. Cost Settled Settled Adjustment Value

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

PO 1/1 10 100 4 40 Yes
SO 2/2 –4 –40 –4 –40 No
The item is on-hand adjusted with a value of 10 in March:

PO 1/1 6 60 10 Yes
PO 1/1 4 40 4 40 No
SO 2/2 –4 –40 –4 –40 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:

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 Inventory value -1@-100
PO +1@80
Example 3:
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
Inventory value -1@-0 Inventory value -1@-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.

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 = new map(types::INTEGER,types::RECORD);

mapLoopDim = new map(types::INTEGER,types::RECORD);
loopX = 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.

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 Date—Looping
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

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.

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 day’s 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.

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 Solutions–Axapta

Microsoft Axapta is business management solution created specifically to help medium-
sized 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.

Help
Help
Help
Help
Help Help Help Help Help Help
Figure 34: Inventory closing setup flow chart

Microsoft Axapta Inventory Closing White Paper

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Microsoft Axapta Inventory Closing White Paper

Uploaded by

Copyright:

Available Formats

Microsoft Axapta Inventory Closing

Version: Second edition

Inventory Closing-Related Issues in Microsoft Axapta .........................................................1

Other Inventory Closing-related Issues and Recommendations ..........................................8

Inventory Closing Technical Documentation ..................................................................... 15

Status of Known Issues (Red Delivery) ............................................................................. 42

About Microsoft Business Solutions .................................................................................. 46

About Microsoft Business Solutions–Axapta ..................................................................... 46

Inventory Closing-Related Issues in Microsoft

Microsoft Axapta Inventory Closing White Paper 1

Potential Triggers of Inventory Closing Issues

Microsoft Axapta Inventory Closing White Paper 2

Microsoft Axapta Inventory Closing White Paper 3

Inventory Closing Red Delivery

Microsoft Axapta Inventory Closing White Paper 4

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

Microsoft Axapta Inventory Closing White Paper 5

Periodic Closing and Recalculation

Incorrect inventory value

Inventory is recalculated monthly R1 – R8 and closing is done today dated at R6.

Figure 2: Periodic closing and recalculation

Reduce Looping to a Maximum of Five (Recommendation 10)

The Maximum throughput parameter determines the maximum number of calculations. If

Microsoft Axapta Inventory Closing White Paper 6

Inventory Closing Yellow Delivery

Inventory Closing Green Delivery

Microsoft Axapta Inventory Closing White Paper 7

Other Inventory Closing-related Issues and

Simplifying Inventory Closing in Future Versions of Microsoft

Pre-closing Data Report

Microsoft Axapta Inventory Closing White Paper 8

Figure 3: Pre-closing data report, purchase lines

Microsoft Axapta Inventory Closing White Paper 9

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

Partial Production Order Costing

Microsoft Axapta Inventory Closing White Paper 10

An Example of Partial Production Order Costing

Figure 6: Create the production order of five units

Microsoft Axapta Inventory Closing White Paper 11

Figure 8: Start of the production order

Microsoft Axapta Inventory Closing White Paper 12

Figure 10: Costing of the two units

Microsoft Axapta Inventory Closing White Paper 13

Figure 12: After finally costing the production

Microsoft Axapta Inventory Closing White Paper 14

Beginning the Inventory Closing Process Unintentionally

Inventory Closing Technical Documentation

Performance Considerations in Inventory Closing

Inventory model Definition

Microsoft Axapta Inventory Closing White Paper 15

LIFO in Microsoft Axapta

Figure 14: Order of settlements in Axapta LIFO

Microsoft Axapta Inventory Closing White Paper 16

Microsoft Axapta Inventory Closing White Paper 17

Figure 16: Expanded Close inventory dialog

Microsoft Axapta Inventory Closing White Paper 18

Type Nr Quantity Cost Settled Open New settle- Remainder

Purchase 1 100 1000 50 yes 50 50

After the first month all 100 units are sold:

Type Nr Quantity Cost Settled Open New settle- Remainder

Purchase 1 100 1000 83.33 Yes 33.33 16.67

After the third month:

Type Nr Quantity Cost Settled Open New settle- Remainder