Goodexplaination_Inventoryclosing

7/23/2019 Goodexplaination_Inventoryclosing

1/30

Whats this all about ?From my personal experience of discussions with consultants and developers, implementing DynamicsAX, issues related to costing and an inventory closing became one of main pain-points of an

implementation process. Peoples tends to treat an inventory closing as a ind of blac box, which,depending from phase of the moon, can produces di!erent result and or re"uire di!erent time to runfor a same dataset. #o my opinion, it is caused by costing information being scattered across variousparts of the documentation. $n addition, some peculiarities of costing are not described at all andshould be learned in a hard way with trial and error approach or by learning of X%% code of aninventory costing.

$n this article $ am trying to provide reasonably detailed description of an inventory closing and also $am discussing some other costing related issues.

#his document is intended for more or less experienced consultants, who already new a generalarchitecture of the #rade module and also have some &successful or unsuccessful' experience in usageof an inventory closing.Almost two years has passed since original version of the article was published. Axapta made

considerable progress during these two years &DAX ())* was released, which introduced some radicalimprovements in costing area'. +esides, $ want to describe some subtle details which have beenomited from the rst version of the article. All additions to the original article are mared out in italics.

Why does an inventory closing isnecessary ?#he main tas of an inventory closing is to calculate the actual cost price of an inventory issue. DAXwors with inventory costs in the following way n instant of an inventory issue posting, system doesnot tries to calculate an exact issue cost price according with the inventory model. $nstead of this,

system uses some estimated value for the issue cost price, which loos lie a good approximation forthe actual cost price. o be discussed in the$nstant estimated cost pricesection'. #hen, during theinventory closing, the actual issue cost price is calculated with respect to inventory model settings.After that, system calculates the di!erence between the initial &estimated' issue cost price and thetrue issue cost price, then system writes this down into inventory transactions and inventoryad/ustments. #hen 0 12 postings for these ad/ustments are created. 3hy this approach has beenchosen4 $n a general, during a posting of an initial inventory issue, system might not have allinformation re"uired to calculate a true cost price. For example, if negative inventory is turned on, wecan post issues before corresponding receipts5 $n the 3eighted Average model, it is impossible tocalculate an issue cost price before all the receipts for a period has been posted5 For F$F62$F models,the receipts might be posted out of chronological order and so on.

3hen $ was woring as a DAX developer, from time to time newbie consultants were trying to tal meinto customi7ing Axapta to allow an Accountant to manually enter an issue cost price into inventorydocuments. #hen Axapta was proposed not to touch inventory transactions having manual cost priceduring an inventory closing. Although this approach loos technically viable from the developer8s pointof view, it 9#:;12< con=icts with the very idea of the Axapta8s costing system. A true issue cost price9>A22 always be calculated during an inventory closing. An on-the-=y cost calculation or even more 0a manual costing are impossible on principle.

After actual issue cost prices for a period has been calculated, system disables creation of the newnancial inventory transactions in this period. $t loos "uite reasonable, because a new transactioncreation could brea the order of issue to receipt settlements thus resulting in incorrect issue costs. $fwe only want to calculate preliminary issue costs for the current inventory transactions snapshot, wewould rather use an inventory recalculation procedure instead of the complete inventory closing
http://fedotenko.info/?page_id=31#Instant_estimated_cost_of_issue.http://fedotenko.info/?page_id=31#Instant_estimated_cost_of_issue.http://fedotenko.info/?page_id=31#Instant_estimated_cost_of_issue.


2/30

9o 0 $nventory closing procedure consists from the following steps

?. $ssue to receipt settlement. @alculation of a initial cost of issues.

(. @ost propagation via inventory movements graph

. Posting of ad/ustments into 12

2et8s loo closer on every of these steps

Receipt-to-issue settlementA calculation of an actual cost price in Axapta is always performed from the settlement betweenreceipts and issues. For F$F and 2$F principles this approach loos "uite natural. 9ay, 3e purchased( pieces for ?)BC: apiece, then pieces for ?BC: a piece. #o calculate the cost price for the issue of pieces we must settle it to the rst receipt of ( pieces with the total value of ()BC:, then with onethird of the second receipt with the total value of ?BC:,thus resulting in the issue8s cost price ofBC:. During the settlement procedure, a receipt8s contribution to the issue cost price is calculated

as a balance of the receipt transaction on the date of the settlement multiplied to the ratio betweenthe settlement8s "uantity and the total "uantity from the receipt. f course 0 the result is roundedaccording to rounding rules from the currency table.

$ will not describe in details the mechanics of the F$F model8s settlement, for it is a straightforwardprocess. #he only thing that is worth to mention is that the system does not chec consistencybetween the issue and receipt dates. 9ay 0 we booed an issue of the item on the Eth of month and areceipt of the same item on the ?Eth of month &suppose 0 there are no other movements for the givenitem'. $n this case, system would settle the given issue to the given receipt without any warnings,which is contrary to mere common sense. $ will loo closer on reasons and negative conse"uences ofhaving negative inventory in sections 3hy does negative inventory appears4and @ost propagation.

$t would be more correct to call 2$F and 2$F on date8 models a 2$2 model &2ast $n 2ast ut'. $t is aind of direct opposite to the F$F model. 9ystem runs through the list of unsettled issues beginning

from the last one, and settles them to the last unsettled receipt &ordered by the date of course'. AG2$F on dateH model di!ers from the 2$F in the aspect of nding an appropriate receipt for the givenissue. #his model settles an issue to the last receipt that have been received +BF:B date of theissue. 9ay, we purchased some item on the ?st, Eth and ?th days of the month and this item was soldon, say, ?)th and ?Ith of the month. From the strict 2$F point of view, the issue from the ?Ith shouldbe settled to the issue from the ?th. &+ecause 2$F suggest the last receipts bound to be written-o!rst'. +ut the whole idea seems to be a little weird, for we are trying to issue the item long before itwas actually received. 9o it seems that developers have implemented two similar models to satisfyboth accounting and common sense approaches to the 2$F principle.

When I was studiyng a DAX2009 source code, it turned out, that actually, usage of the LILO principle, Ihad descried earlier, had een a !ore progra!!ing error than an actual intention. It see!s that ade"eloper #ust copied the piece of code fro! the $I$O !ethod and sustituted the reverse %eywordfor oth issue and receipt selection state!ents. &hat resulted in the LILO principle I'"e descried

ao"e, that is ( latest issues was eing settled with latest receipts, then earlier issues with earlierreceipts and so on. &he funny thing is that this error was introduced in at least "ersion ).0sp2*su!!er 200)+ and was -ed only years later ( in year 200/ It see!s that the LI$O principle is not

"ery popular for in"entory "aluation all around the world.
http://fedotenko.info/?page_id=31#Why_does_negative_inventory_occur_from_time_to_time_http://fedotenko.info/?page_id=31#Why_does_negative_inventory_occur_from_time_to_time_http://fedotenko.info/?page_id=31#Cost_propagationhttp://fedotenko.info/?page_id=31#Why_does_negative_inventory_occur_from_time_to_time_http://fedotenko.info/?page_id=31#Cost_propagation


3/30

;ow 0 2et8s have a loo at 3eighted average8 and 3eighted average on date8 principles. $n any oldtime, before Axapta .)sp( was released, run of an inventory closing procedure for these principlesled to creation of an every-receipt-to-every-issue settlement. 9o, $f we had a two unsettled receiptsfrom the previous period, J receipts on the current period and, say ) issues in the current period, thisled to the settlement of I receipts to ) issues, thus producing () settlements and J) settlementrecords &For each settlement is stored as two records of invent9ettlement table'. $t is easy to guessthat such explosive growth of the invent settlement table also led to signicant degradation in

inventory closing8s performance. #hat8s why the more lite approach to weighted average costing wasimplemented in version .)sp(. $n that version, thresholds for "uantity or amount of the settlementwere introduced. :oughly speaing, while nding an appropriate receipts to settle with a given issue,system begins with receipts having a highest unsettled "uantity and tries to settle at least thethreshold value. $f the unsettled "uantity for issue or receipt is below the threshold value, systemsettles it regardless of the threshold value. #he threshold value may be specied in the following ways

?. Kinimal percent of of receipt "uantity may be specied in the inventory closing parameters. $nthis case 0 the system tries to settle at least ; percents of a given receipt in each settlement.

(. $n the eld GKinimum Average 9ettleH of the inventory table for the given item.

. $n the eld GKinimum Average 9ettleH of the inventory parameters table. #his parameters ise!ective only for items which do not have the specic value in the eld from the previous step.

Finally 0 there is also an indirect way to specify a "uantity to be settled. $t is possible to specify aminimum amount to be settled in inventory closing parameters. $n this case, the system tries tocreate settlements which settle a receipt to an issue for at least specied monetary amount, thuslimiting a "uantity to be settled.

#hus, under regular conditions &purchase prices do not considerable vary during a reporting period5number of issues is signicantly higher than number of receipts' results of this averaging algorithmwould not di!ers considerably from a true average cost calculated, roughly speaing, in Bxcel. +utsuppose we are purchasing (- batches of item with thousands of pieces in them, and we are sellingseveral thousands of batches with (- item in each. Cnexpectedly we are purchasing some strangebatch with E pieces on double of the regular price. $n this case, those unlucy issues, that were to besettled to this receipt, would have a cost price which is deviates signicantly from true period8saverage.

After the original article was written, a radical change to the weighted a"erage cost calculationalgorith! has een introduced. If costing procedure nds that we ha"e only O1 unsettled receipt,then all issues are settled to this receipt and e"erything is wor%ing as usual. 3ut if there are 456ALunsettled *open+ receipts, then a co!pletely di7erent algorith! is used8

. A du!!y in"entory transfer is created for a gi"en ite! id and a gi"en co!ination of nancialin"entory di!ensions. &hat is ( &he in"entory transfer operation appears, which is processedy in"entory closing as a regular in"entory transfer, ut it does not actually change thein"entory di!ension: an in"entDi!Id eld "alue is the sa!e on oth issue and receiptin"entory transactions of the transfer.

2. All open receipts in a period are settled to the issue transaction of the transfer

). All open issues in a period are settled to the receipt transaction of the transfer.

&hus actually the receipt of this transfer has a total cost of all open receipts of the period. &hen ( thiscost is propagated to e"ery actual in"entory issue of the period y the ratio etween the ;uantity in agi"en issue and a total su!!ed


4/30

*actually ( se"eral receipts sharing the sa!e nancial date ( should we ha"e the!+ and the issue fro!the pre"ious transfer to the new du!!y transfer.

I ha"e not personally tested the perfor!ance of algorith! descried. 3ut ta%ing so!e generalconsiderations, it loo%s li%e an in"entory closing for =Weighted a"erage' would wor% withappro-i!ately the sa!e perfor!ance as $I$O, and =Weighted a"erage on date' would ta%e around)0 of $I$O in"entory closing ti!e.

$ want to especially emphasi7e again that for a settlement cost8s calculation, the system uses thebalance of inventory transaction on the date of the settlement. 9o if we purchased a merchandi7e on?Eth, then allocated some additional marup into the receipt8s cost price on (Eth, than for aninventory closing on ()th, only the initial purchase cost price, cleared from later marups would betaen into account.

Cost propagation9o 0 #he receipt-to-issue settlement is done. #he true cost price is calculated. 3hy does it need someextra steps for a cost propagation 4

$magine the following picture

An item was purchased on the ?st of Lan with the cost price of ())) BC:

n the Eh of Lan it was transferred to a neighboring warehouse. $t is obvious that the estimatedinstant issue cost price as well as the receipt cost price for the transfer is ())) BC:

n the ?)th of Lan the item was sold from the neighboring warehouse. #he estimated instantissue cost price is ()))BC:

n the ()th of Lan some transportation costs of )) BC: was ac"uired into the initial receiptcost price &via marup allocation functionality'.

An inventory closing model for the item is F$F

$f we are closing inventory for date of the ?th of Lanuary then system settles the issue &to theneighboring warehouse' from the Eth of Lan to the original receipt and calculates the actual cost priceof the issue to be ()) BC:. $t is obvious that we should somehow change the receipt cost price for thetransfer to the neighboring warehouse and, correspondingly, change the issue cost price for the salesorder from the ?) of Lan, to ()) BC: too.

#his tas is implemented in the following way

n the every update of an issue inventory transaction during an inventory closing, the system checswhatever a lined receipt for it exists 4 &2ined receipts exist for issues of inventory transfer /ournals,

"uarantine orders, transfer orders, production orders, +K Lournals and dummy transfers made foraverage costing'. $f this is a case, then the ad/ustment amount is written into the G2ot levelad/ustmentsH &$nvent@ost2ist#rans' table, together with the lot id of the lined receipt and someadditional info.

#hen on a stage of cost propagation, the system reads this information, ad/usts cost price forcorresponding receipts, then ad/usts cost price for issues settled to this receipts. 9hould ad/ustedissues have a lined receipts, then cost propagation is repeated.


5/30

#hus, basically 0 a cost propagation process is iterative be the nature. #hrough usage of an inventorysettlement table, the system builds a cost movement graph which traces cost movements from aninitial purchase to a nal sale.

>ow to dene a number of iterations re"uired for the inventory closing 4 $t is a complex issue. $n atheory, the number of iterations re"uired is calculated as a maximum number of inventory transfers fora given item id plus a maximum nesting level for +Ks with the given item, plus a number of transfers

via "uarantine order and so on. $n a reality, the number of iterations re"uired mostly depends onpresence or absence of loops in a cost movement graph. $f these loops are absent, then an inventoryclosing re"uires E-M-?)-?E-() iterations to be nished. $f these loops are present, then the number ofiterations re"uired is scarcely predictable.

3hy do loops occur in a cost movement graph 4

$magine the following picture

?. n the ?st day of the month one piece of item was purchased for ()) BC: into the warehousewh? &Purch?'

(. n the ()th day of the month another four pieces was purchased for (E) BC: a piece into the

warehouse wh? &Purch('

. #hen a transfer of ( pieces from wh? to wh( was posted &post factum' on the Eth day of themonth. rsf?'

. #hen this two pieces was transferred bac to wh? on the Jth day of the month. rsf('

E. All ve pieces was sold on the (Eth day of the month from wh? &sale?'

J. #hen on the (Mth day of the month extra costs was ac"uired into the cost price of the originalpurchase via marup allocation.

M. A 3arehouse inventory dimension is =agged as a nancial inventory dimension.

I. 3e about to close an inventory for the ?th day of the month.

+efore an inventory is closed, the inventory transactions has the following costs and "uantities

Document Date Quantity Cost Price Warehouse

Purch? )?.)?.())M ? ()) ?

#rsf? )E.)?.())M -( -I) ?

#rsf? )E.)?.())M ( I) (

#rsf( )J.)?.())M -( -I) (

#rsf( )J.)?.())M ( I) ?

Purch( ().)?.())M ?))) ?

9ale? (E.)?.())M -E -?()) ?

After the settlement phase &with F$F principle', we have the following picture

Issue Receipt Settlement

Co Qt rigi Pri !d"ustm Cod Qt rigi Pri !d"ustm Qt !mou !d"ustm


6/30

de ynal

CostPrice

ce ent e ynal

CostPrice

ce ent y nt ent

#rsf?

-( -I) (() )Purch?

? ()) ()) ) ? ()) -)

#rsf( ( I) () ) ? () )

9ale?

-E -?()) () 0)? () )

Purch(

?))) (E) ) ?))) )

#rsf(

-( -I) () ) #rsf? ( I) () ) ( I) )

#ae a notice that we are having a loop in our cost movement graph the issue from the secondtransfer is settled to the receipt of the rst transfer. #hen, the receipt of the second transfer isdependant on the issue of the rst transfer. 2et8s have a loo on what will happen on next iterations. $will specify an accumulated ad/ustment for the given issue6receipt in the ad/ustment eld of the receiptor issue part of the table. Bvery new table below corresponds to another iteration of the inventory

closing.

$teration ?


Code

Qty

riginal

CostPrice

Price

!d"ustment

Code

Qty

riginal

CostPrice

Price

!d"ustment

Qty

!mount

!d"ustment

#rsf

?

-( -I) (() )Purch?

? ()) ()) ) ? ()) -)

#rsf( ( I) () ) ? () )

9ale?

-E -?()) () -)? () )

Purch(

?))) (E) ) ?))) )

#rsf(

-( -I)220

40 #rsf? ( I)220

-40 ( 440 -40

$teration (


Code

Qty

riginalCostPrice

Price

!d"ustment

Code

Qty

riginalCostPrice

Price

!d"ustment

Qty

!mount

!d"ustment

#rsf?

-( -I)210

60

Purch?

? ()) ()) ) ? ()) -)

#rsf( ( I) 220

-40 ? 220 -20

9al -E -?()) 24 -20 ? 220 -20


7/30

e? 4Purch(

?))) (E) ) ?))) )

#rsf(

-( -I) (EE -) #rsf? ( I) (EE ) ( E?) )

$teration


Code

Qty

riginal

CostPrice

Price

!d"ustment

Code

Qty

riginal

CostPrice

Price

!d"ustment

Qty

!mount

!d"ustment

#rsf?

-( -I) (?) J)Purch?

? ()) ()) ) ? ()) -)

#rsf( ( I) (() -)? (() -()

9ale?

-E -?()) ( -()

? (() -()

Purch(

?))) (E) ) ?))) )

#rsf(

-( -I)210

60 #rsf? ( I)210

-60 2 420 -60

$teration


Co

de

Qt

y

riginal

CostPrice

Pri

ce

!d"ustm

ent

Cod

e

Qt

y

riginal

CostPrice

Pri

ce

!d"ustm

ent

Qt

y

!mou

nt

!d"ustm

ent

#rsf?

-( -I)205

70

Purch?

? ( ()) ) ? ()) -)

#rsf( ( I)210

-60? 210 -30

9ale?

-E -?())242

-10

? 210 -30

Purch(

?))) (E) ) ?))) )

#rsf(

-( -I) (?) J) #rsf? ( I) (?) -J) ( () -J)

$teration E


Code

Qty

riginal

CostPrice

Price

!d"ustment

Code

Qty

riginal

CostPrice

Price

!d"ustment

Qty

!mount

!d"ustment

#rsf -( -I) ()E M) Purc ? ()) ()) ) ? ()) -)


8/30

?h?

#rsf( ( I) (?) -J)? (?) -)

9ale?

-E -?()) (( -?)? (?) -)

Purch(

?))) (E) ) ?))) )

#rsf(

-( -I) 205

70 #rsf? ( I) 205

-70 2 410 -70

$teration J


Code

Qty

riginal

CostPrice

Price

!d"ustment

Code

Qty

riginal

CostPrice

Price

!d"ustment

Qty

!mount

!d"ustment

#rsf?

-( -I) 202,5

75

Purch? ? ()) ()) ) ? ()) -)

#rsf( ( I)205

-70? 205 -35

9ale?

-E -?()) 239 5? 205 -35

Purch(

?))) (E) ) ?))) )

#rsf(

-( -I) ()E M) #rsf? ( I) ()E -M) ( ?) -M)

And so onN $f we had not have the issue with the transfer of the item before actual the purchase ofthe item, then the inventory closing would nish in two iterations. $n our example, the actual inventoryclosing will tae around E-?) iterations. Furthermore, 3e can estimate that the issue cost price for the

sales order will not achieve the correct value of ?()) BC: and a di!erence will be written-o! fromtransfer transactions as a rounding error.

9o, should we have a negative inventory case for one of the time-points in a period of an inventoryclosing, this would lead to considerable increase in the number of iterations re"uired for the inventoryclosing and to deviation of the calculated inventory cost from the actual cost.

+esides that, 3e should remember that for the weighted average model, as a most general principle,every issue is settled to every receipt. #hus, loops in a cost movement graph are natural for theweighted average model and happens even if inventory have not went negative in a period beingclosed.As of "ersion 2009 it is still true. During an in"entory closing e"ery receipt is still eing settledto e"ery issue. "en if now it is !ade "ia a du!!y transfer, not "ia a direct settle!ent, it does notchange econo!ical !eaning of a weighed a"erage in"entory closing.

I should !ention also, that a cost propagation does not propagate costs through in"entorytransactions which went through an =in"entory on


9/30

?. GKaximum throughputsH. #his is exactly the eld which holds the maximum number ofiterations allowed. $f during cost propagation, an inventory closing procedure has reached theiteration with the number e"ual to the number specied in this eld, then the next ad/ustment&which came from the last iteration in invent@ost2ist#rans table' would not be propagated tothe corresponding issue transaction, but instead will be written-o! to a rounding 12 accountimmediately after being applied to the appropriate inventory receipt.

(. GKinimum throughput ad/ustmentH. $f value of an ad/ustment for the single transaction, whichcame from the previous iteration, is below the threshold specied in this eld, then thisad/ustment is not propagated to the corresponding inventory issue, but is written-o! to arounding 12 account immediately. $ want to emphasi7e that this parameter stops costpropagation only for those cost =ows8 which falls under this threshold. B.g. if we have ad/ustments from the previous iteration, say, (,?) and I) eurocents, and the value of theKinimum throughput threshold is set to E eurocents, then only the rst of ad/ustments will bewritten-o! to a rounding account &and the cost =ow8 will be stopped e!ectively'. :emainingad/ustments will be taen into the following iteration, and corresponding cost =ows won8t bestopped.

Procedure for writing-o! ad/ustments is described in more details in the section Gn writing-o!rounding errors and ad/ustments during cost propagationG.

&here is so!e odd feature of in"entory propagation which often cause user's confusion. &here is arather typical user's ;uestion8 @I had already closed in"entory transaction, ut it was so!ehow!odied during the in"entory closing. Why B &he answer to this ;uestion consists fro! two points8

?. An in"entory transaction should fulll to following conditions to e !ar%ed as closed8 A;uantity in the transaction should e e;ual to A settled ;uantity in thetransaction*in"ent&rans.;tyCCin"ent&rans.settledty+: A cost price in transaction should ee;ual to a settled cost price in thetransaction*in"ent&rans.costA!ountEostedFin"ent&rans.costA!ountAd#ust!entCCin"ent&rans.costA!ount4ettled+ *&o e asolutely precise ( they should not e e;ual. Actually ( adi7erence etween the "alues !ust e less then so!e dened delta+.&hus, if cost of a closedin"entory receipt was ad#usted so!ehow *!ay e we #ust ha"e !anually ad#usted it through afor!, or a cost price was changed during a cost propagation+, then this transaction is ound toe open i!!ediately.

(. "en efore a receipt


10/30

$inally ( to close the the!e I want to !ention that Dyna!ics AX 2009 introduced the e-tra step forcost propagation ( an ad#ust!ent and calculation of indirect e-penses for production orders. I willdescrie this later in the section @Gost rea%down and indirect costs@.

#$ postings creationFirst, $ want to mention, that 12 postings are created by an inventory closing only if the 2edger eldhas been checed in $@8s parameters. Personally 0 $ see no point in un-checing this eld, because atime re"uired for creation of 12 postings is insignicant, comparing to other steps of an inventoryclosing.In "ersion 2009 this eld is hidden fro! the para!eters for! and is always chec%ed.

n previous stages of inventory closing, the system has generated and lled the lines of the inventorysettlement table &invent9ettlement', which, besides settled "uantities, settled amounts andad/ustments, contains information re"uired to create 12 postings from ad/ustments performed a 12inventory account, a 12 o!set account, posting for inventory and o!set 12 accounts. 9o, 12 postingcreation procedure loos pretty simple. $t /ust sums-up and group amounts from invent settlement byparticular accounting parameters. #herefore, there is no necessity in some routine that would reconcile12 postings of an inventory closing to inventory transaction data. $f the inventory closing hasgenerated 12 transactions with some odd account numbers or dimensions, try to nd this dimensions

and accounts in the settlement table. #hen, from this table, one can drill-down to original inventorytransactions and chec them for suspicious data.

Furthermore, 12 postings creation depends from the particular inventory closing parameter, calledG9pecicationH. #his parameter allows to group 12 postings not only by accounting parameters &12accounts,Dimensions, 12 Postings', but also on item$d or item group of the item being ad/usted.

138 Jow does the syste! %nows that for transactions which did not generates ?L postings, thein"entory ad#ust!ent also should not e posted into ?L during the in"entory closing During theposting of the originating in"entory transaction, the syste! stores into the in"ent&ransEosting talethe infor!ation on the in"entory account, the o7set account, the di!ension and, !ore i!portant,whate"er the ?L posting has een created for this transaction*isEosted+. I want to !ention thataccount and di!ension infor!ation is always stored, e"en if transaction has not een posted to ?L.&hen, during the receipt


11/30

@lient &$ mean 0 Dynamics AX reach client process', which originally have started inventory closing, willbe referred as a Gmaster clientH. Bvery other client will be referred as a Ghelper clientH. Lust to remind0 >elper client is started by clic to the @alculation-O@alculation >elp menu in he inventory closingform, whilethe unnished inventory closing is selected in the grid.

3hen the inventory closing procedure is started on the master client, it writes the user-speciedparameters into the $nventory @losing table &invent@losing' to allow them to be fetched from helper

clients. #hen, master client writes the list of inventory items, which have open transactions, into@alculation 2ist table &invent@ost2ist'. #hen, master client, as well as helper clients, begin to performthe receipt-to-issue settlement procedure for items from this table &the routine described in :eceipt-to-issue settlementsection'. #his stage considered to be 7ero iteration. As $8ve already mentioned in @ostpropagation section, during a settlement process, the system creates records in $nvent@ost2ist#ranstable, which will be used as an input data to cost propagation iterations. $t is worth to mention that ifsome inventory item has been referenced from invent@ost2ist#rans table, reference to the sameinventory item is inserted into the invent@ost2ist table. #his is necessary for a coordination of worbetween multiple inventory closing clients during a cost propagation process.

#he similar algorithm is also used on every cost propagation iteration. Bvery client runs throughinvent@ost2ist records and for every inventory item referenced, it performs an iteration of the costpropagation, fetching ad/ustment data, which has came from the previous iteration, from theinvent@ost2ist#rans table.

#he elementary unit of wor for both settlement and cost propagation steps is an inventory item.9ettlements creation6iteration of cost propagation for an inventory item is always performed from oneclient.

Posting of $@ results to 1eneral 2edger is performed from the master client only.

$f @alculation-OPause @alculation menu item is cliced during an inventory closing, then the systemwill suspend the procedure. #he inventory closing session may be resumed little bit later on, byclicing to @alculation-O@alculation >elp. $n this case, the rst client which has /oined the suspendedclosing session would became a master client.

$f you are using more than (- worstations in a KC$@, it is worth to chec utili7ation of D+ and A9

server8s resources.


12/30

0 eld with the opposite meaning. :oughly 9peaing 0Kaximum ;umber of $terations minus ;umber of iteration

InventCost$ist*rans

)ield Description$tem$d $tem number to be processed by cost propagation

$nvent#rans$d;umber of receipt inventory lot to be ad/usted initeration of cost propagation

$nvent#rans$d:eturn

;umber of returned inventory lot. Csed if on sales orderreturn &or more generally on any return' number ofreturned lot &inventory issue lot which is being returned'has been specied. #his is special case, becausead/ustment value is ignored by cost propagation routine.$nstead 0 :eturning receipt lot cost price is set to the fullcost price of issue inventory lot being returned &with

reverse sign indeed'

QoucherPhysical

$s used only for "uarantine order and for the returns. $snecessary only to refer to originating inventorytransaction, which is a precursor for ht currenttransaction.

QoucherQoucher number for given $@ session. $s used to looupparameter data from invent@losing table by helperclients

;umf$teration

;umber of current cost propagation iteration. $s used forcoordination between KC$@ clients. $t prevents theattempt of certain client to proceed with the nextiteration, while the most of client still process the currentiteration.

Ad/stment Ad/ustment value itself.

A receipt-to-issue settlement stage considered to be the stage number 7ero. $nvent@ost2ist#rans tabledoes not contain records for this stage

In "ersion 2009 technical infrastructure for HIG has een changed signicantly. $irst of all, this iscaused y the transition to the new atch ser"er technology. Although this topic is ;uite interesting yitself and deser"es a separate article, I will riePy enu!erate ideas ehind the new atch ser"ertechnology8

?. In DAX 2009, atch tas% co!plying to the new atch ser"er infrastructure, are perfor!ed onthe AO4 ser"er, not on a dedicated wor%station with the regular A-apta's reach client. &his was!ade not in intention to sa"e custo!er's QR00 for a dedicated co!puter, ut to support anen"iron!ent for paralleliation of co!putational intensi"e tas%s. It is clear, that in !id


13/30

ase of an old client


14/30

only for ?) eurocents with every couple of iterations 0 it is /ust about time to try to understand 0whatever we have some issues with this inventory lot or not 4Kost probably, the reason for suchbehavior is that inventory went negative for the given item in some point of time of the period beingclosed.

$f you are a perfectionist or value of this hanging ad/ustment is rather high &say 0 J))) for thecompany with monthly revenue of J))))))', then one should write down the ids of lots being

ad/usted, stop the ongoing inventory closing, cancel it and begin to sort out the lots in "uestion. $f youhave found some cases of negative inventory, then you have to accurately reverse these transactions,mar reversed transactions to reversing ones &or use returned lot number mechanism' and attempt torun another inventory closing for the same period. &Discussion about the mars and returned lotmechanism follows in the Gn reversalsH section'.

$f you nd that the hanging ad/ustment value is inconsiderable comparing to the period8s turnover&say 0 E) for the company with the monthly revenue of E)))))))', you can /ust ad/ust &in the tablebrowser' the value of Kin#ransferQalue of the appropriate record in the $nvent@losing table. #his isexactly the eld which is used to store the value of the GKinimum #hroughput Ad/ustmentH inventoryclosing parameter. $f you specify the value which is higher then any of remaining ad/ustments beingpropagated, then on the next iteration, all remaining ad/ustments would be written-o! to to a rounding12 account and the cost propagation stage would nish. Csage of this techni"ue would notcompromise overall precision of company8s nancial statements, although it will denitely lead to

somewhat inconsistent @196Karginal prot values for particular sale orders. 9o 0 the basic principleof this techni"ue is the following

?. n the start up of inventory closing we specify some reasonably low value for GKinimum#hroughput Ad/ustmentH eld &say ?BC: or even ).E)BC:'

(. After inventory closing has been run for some ()-)) iterations, we change the value tosomething considerably high &say ?))BC:'.

As a result 0 inventory is closed with high precision for correct8 inventory transactions and withtolerable precision for incorrect8 ones.

#hat is why it is so important for estimated issue cost not to vary to much from true issue cost. $f the

cost propagation graph has loops and a propagation ad/ustment is being decreased too slowly, thenevery euro of the di!erence might cost and extra E-?) iterations of an inventory closing.

+esides that, $ advise you to develop some inventory checing functionality which would run throughopen inventory transactions and warn a user if inventory went negative. $f you were to run thisfunctionality before inventory closing, you would not wait for ()-) iterations to nd suspiciousinventory transactions. $ saw several implementation of this functionality developed by di!erentpartners. $ do not now, why Kicrosoft still has not developed it. $n version .) some primitive form ofan inventory checing was introduced &@lose procedure-O?.@hec open "uantities in $nventory @losingform', but it is worthless because it checs only a inventory on-hand "uantity for the date of inventoryclosing and do not chec it for every date of period being closed.

Finally, $t is worth to mention that for some businesses, negative inventory is a "uite regular case. B.1.if some company is selling merchandi7e on-the-=y8, instantly upon arrival, it is "uite natural to sell it

and invoice it, several days before purchase invoice is arrived and booed. $n this case the only way toimprove $@ performance is usage of Kin#ransferQalue nudging techni"ue $8ve described already. 9ure,$n this case @19 and Karginal prot for separate sales would be denitely inconsistent, but for thesetype of businesses, a cost analysis for separate sales order is usually pointless.

Inventory recalculation
http://fedotenko.info/?page_id=31#Inventory_operation_reversal_(return)http://fedotenko.info/?page_id=31#Inventory_operation_reversal_(return)


15/30

Dynamics AX supports not only inventory closing procedure, which calculates a nal issue cost pricefor every open inventory transaction of a period &blocing the period for further posting of inventorytransaction', but also an inventory recalculation procedure. #his procedure di!ers from the aninventory closing in the following way

?. :eceipt-to-issue settlement is performed in-memory8, that is 0 no settlement records arewritten to the inventory settlement table.

(. $f a cost price need to be ad/usted, an ad/ustment record is written to the inventory settlementtable. #his record has the ad/ustment value lled-in, but settlement "ty and settlement amountelds are left empty.

. As a conse"uence of rst two points 0 the system performs in-memory8 receipt-to-issuesettlement before BQB:< iteration of cost propagation. $t loos "uite logical, for if we do nothave settlement data stored in a database, we have to rebuild one every time, /ust to nowwhat issue must be corrected for the cost propagated to the given receipt.

. :ecalculation may be entertained for the single item or item group. #he only thing that needsto be remembered is that if given item have been issued for the +K /ournal or productionorder, it might result in ad/ustment of an other item8s transactions, because in this case cost is

propagated to other inventory items.

E. During inventory recalculation, system does not write-o! rounding.

$f we thin about the rd point more deeply, we can draw a conclusion that an inventory recalculationis A23A


16/30

posted with the sa!e class *sa!e piece of code+. In "ersion 2009 this logic was split intoseparate classes to post a cancellation and to post regular operation. In "ersion 2009in"entory closing procedure was o"erloaded with logic to perfor! a "ariation posting *for newstandard cost !echanis!+ and a indirect cost posting. &hus result in separation of posting andre"erse posting logic

It is also worth to !ention that an IG cancellation procedure is used as well to cancel an in"entory onow to establish the lin from issuing sub-lot and receiving sub-lot 4 Andwhat, in most general case, this sub-lot is 4 3hat is a most natural, easy comprehendible, atomic unitof cost 4


17/30

#his case might also be an example of an attempt to resolve the business issue with an $#-approach. $fwe loo into situation closer, we would run into a re"uirement con=ict From one side, somebody &mostprobable 0 peoples from accountancy6nances' insists on the per-batch costing. Probably, it impliesthat batch numbers are used to eep trac of something &maybe 0 vendor of the item, may be somespecial discounted price from vendor, may be it is used to eep trac the to-stoc6on-order status ofan item etc'. From other side 0 some other departments do not care at all about a batch number andtrying to mae the system to substitute these batch numbers for them. $n this case 0 there are two

possible solutions for the problem

?. $nsist on a batch number to be specied by a user. #he pro/ect sponsor should mae a 9BQB:BBXP2A;A#$; to end users about meaning of batch numbers for the company.

(. $f there is no some implied info associated with batch numbers, $t might be useful to push theaccountancy into usage of the F$F costing and discontinuation of the batch number usage. $fa batch number is used ;2< to trac the exact source of an issue cost price, then it might bemuch more useful to /ust run an $@ with F$F model and develop some report which wouldshow the originating purchase transaction for every issue transaction from settlement data.

Inventory settlements and ho, to

,or/ ,ith them#his section is dedicated to the inventory settlements table &invent9ettlement'. 9trictly speaing,usage of word G9ettlementH in the name of this table is misleading, because this table is used not onlyto store receipt-to-issue settlement information, but also for eeping a trac of ad/ustment made forgiven inventory transaction. Although for issue inventory transactions, an ad/ustment is alwayscalculated from settlement data, for receipt transactions an ad/ustment may be made completelyindependent from the settlement. Also, if an ad/ustment of an issue cost price is made during aninventory recalculation, then the settlement would be made in memory8 and the settlement recordwould actually eep only the ad/ustment value, but not the settlement data. 2et8s have a more closerloo at the table8s elds

)ield Description

#rans:ec$d:eference to the :ec$d of the inventory transactionbeing settled6ad/usted

$nvent#rans$d $nventory lot being settled6ad/usted

$tem$d$tem number of the inventory lot beingsettled6ad/usted

$tem1roup$d$tem group of the inventory log beingsettled6ad/usted

#ransDate Date of settlement6ad/ustment

Qoucher

Qoucher of the settlement6ad/ustment. Kight be used

to drill-down to originating inventory closing6marupposting6etc

9ettle#rans$d

9urrogate ey. Actually 0 /ust gradually increasedcounter. Qalue of this eld is used to fetch receipt-to-issue settlement info. Actually 0 settlement is storedas #3 settlement records 0 one for the issue andone for the receipt. #his #3 records will share thesame 9etle#rans$d


18/30

Rty9ettled9ettled "uantity. $f given record was created as anad/ustment &not the settlement', this eld is blan.

@ostAmunt9ettled9ettled amount.$f given record was created as anad/ustment &not the settlement', this eld is blan

@ostAmountAd/ustment

Ad/ustment amount. Field is always not blan for

ad/ustment records. For settlement records this eldis has some value only if settlement has resulted inad/ustment.

+alance9heetAccount $nventory account for the ad/ustment.

perationsAccount !set account for ad/ustment

+alance9heetPosting12 posting type for inventory side8s 12 posting ofad/ustment

perationsPosting12 posting type for o!set side8s 12 posting ofad/ustment

DimensionDimension to be used during posting of the

ad/ustment@anceled $s #rue if given settlement was cancelled

9ettleKodel9ettlement Kodel. :oughly speaing 0 is somethinglie inventory model

Posted#rue if this record was processed by settlement 12posting procedure.

9ettle#ype 9ettlement #ype

#he :eceipt-to-issue settlement created by inventory closing, is stored in this table as a two records 0one for the issue and one for the receipt. #hese two records share the same 9ettle#rans$d.

For ad/ustments 0 this table contain only one record per ad/ustment.

Fields related to 12 posting are lled with information from the inventory posting table&$nvent#ransPosting' lined to the inventory transaction being ad/usted. $f there no record ininvent#ransPosting has been found by some reason, then the system fetches the inventory accountfrom the inventory issue6receipt settings of the inventory posting setup and o!set account 0 from theinventory prot6loss settings of the inventory posting setup. $ should mention also, that theinvent#ransPosting record is lled during the nancial update of the inventory transaction and dataremains in this table even if a source inventory document &sales order6inventory /ournal6productionorder' has been deleted.

$t is worth to mention, that an ad/ustment to an inventory transaction not always leads to creation of12 postings. 9ay 0 $f ad/ustment for a "uarantine order transaction was made, this should not lead to12 posting creation, because the originating "uarantine order has been posted without 12 postings

creation. #he system eeps trac of whatever the original document was posted into 12 in isPostedeld. $f this eld was set to false during originating inventory document posting, then system does notll account elds in the inventory9ettlement table and these records are ignored by the 12 postingcreation subsystem. 9o, if you are reconciling the inventory settlements to 12, you can safely ignorerecords with blan account and posting elds. $t is also worth to mention that the Posted eld in theinvent9ettlement table does not related to actual posting of the record into the 1eneral 2edger. #hiseld is /ust a =ag, which is used to mar records processed by the 12 posting creation routine.


19/30

! little bit on inventorytransactions$t is worth to have a closer loo to that elds of inventory transactions, that are related somehow tocost and inventory closing

)ield Description

@ostAmountPostedriginal receipt cost price for receipt transactions5Bstimated issue cost price for issue transactions.

@ostAmountAd/ustment

Ad/ustment value. Kust be always e"ual to the sum ofad/ustment from invent9ettlement records connected tothis invntory transaction

@ostAmount9ettled@ost amount settled during $@. For closed inventorytransactions 0 is e"ual to

@ostAmountPosted%@ostAmountAd/ustmentRty Ruantity in inventory units &not purchase or sales units'

Rty9ettled Ruantity settled during $@.

@ostAmountPhysical.

@ost price for physical operations. &B.1 0 pacing slipposting'. For receipt transactions, $t is usually e"ual tothe price fro purchase order line5 For issue transactions0 to the estimated issue cost price. Attempt to use thevalue of this eld for any substantial reports is probablysign of bad design. #his eld only meant for the :C1>evaluation of potential cost prices of non-invoicedinventory transactions.

@ostAmount9tdQalue of the standard cost used on posting. &$i-edreceipt cost ( in DAX2009+.$s set to 7ero, if standardcost &-ed receipt cost+ is not used for given item.

@ostAmountperations

@ost amount posted to operations &not-inventory'account. Actually 0 only lled-in for purchasetransactions of service items.

Qaluepen

@losed6pen tag for an inventory transaction.#ransaction is mared as closed if@ostAmount9ettledSS@ostAmountPosted%@ostAmountAd/ustment and abs&"ty-"ty9ettled'T).)))))))?

Date@losed 3hen transaction is being mared as closed, systemsets this eld to the date of the last settlement madefor the transaction.

Inventory operation reversal'return(


20/30

#here are two completely di!erent mechanisms to create returns

#o return inventory issue, the Greturned lot numberH mechanism must be used. #his returnedlot number may be specied in, for example, a sales order line or an inventory /ournal line.#hen, this lot number is being copied to an inventory transaction &into invent#rans$d:eturneld'. During an inventory closing, for the transactions with this eld set, system nds anoriginating &being returned' inventory transaction, fetches the original issue cost amount from

it, and set cost price of receipt &return' to this value with the sign reversed.

#o return inventory receipts, the Gmared inventoryH mechanism is used. #his mechanism willbe described in more details in the rest of the section.

9o 0 #he system allows to mar inventory receipts and inventory issues to each other. $t means, thatthe value of an inventory lot number &value of invent#rans$d' of the rst party is written to theinvent:efrans$d eld of the second party and vice versa. During an inventory closing or an inventoryrecalculation, such lined transactions go out of the regular settlement and cost propagation routine.$nstead of that, these transactions are settled directly to each other regardless of the inventory model.@onse"uently 0 the issue cost price become exactly the same as receipt cost price of mared receipt. $tis also worth to mention, that both during a maring and during an inventory closing6recalculation ofmared transactions, the system also checs the consistency of nancial inventory dimensionsbetween the transactions. #hat is 0 $f you set the batch number as a nancial inventory dimension, anissue and receipt with di!erent batch numbers would not be allowed to be mared to each other. Bvenif somehow &e.g. by direct write to invent#rans from developed code' this transaction become mared,the system will clear this maring during an inventory closing and /ust settle this transactions with theregular routine.

#ransactions may be mared both before a nancial update and after a nancial update. $t is notallowed to mar an open transaction to a closed one, because during an inventory closing6recalculationthis closed transactions are ignored, thus voiding the very idea of maring.

Cnfortunately, besides cost calculation, maring in Dynamics AX is also used for some other purposes

?. n reservation in ordered, maring allows to lin this reserved issue transaction toa particularreceipt transaction in GrderedH status. #hen 0 on physical update to this receipt transaction,

exactly this lined issue transaction would be updated to G:eservedH status. 9o 0 3e canassociate our G:eserve in orderedH to some specic estimated receipt.

(. $n K:P, maring is used to store the information about covered6covering re"uirements.:oughly speaing, if two inventory transactions are mared, then corresponding records in ;et:e"uirements &re"#rans' would be considered as covered6covering. :espectively, if we arerming planned order created from ;et :e"uirement, then receipt inventory transactionscreated would have mared to covered issue inventory transactions.

$t is worth to remember about these mechanisms, because often marings created from reservation orK:P planning, results in broen inventory costs. $f too much of inventory transactions have beenomitted from the regular costing routine because of marings, costing would e!ectively run in the per-batch costing mode, thus ignoring an inventory model settings for an item.

Writing o0 rounding errors andad"ustments during costpropagation


21/30

@onsider the following situation 3e purchased pieces of a merchandi7e for ?)BC:. #hen every piecehas been sold &in separate sales orders'. 9ay, we had not had any operations other than the purchaseand sales. After an inventory closing, the purchase cost is distributed evenly between issuetransactions, thus resulting in the issue cost price of .BC: per transaction. :eceipt transaction ismuch more interesting case. From one side, the settled "uantity is pcs &3hole receipt is issued andsettled5 :eceipt must be closed'. From the other side 0 #he settled amount is *.**BC:, thus meaningthat the receipt still can not be mared as closed, for the receipt cost price has open balance of

).)?BC:. $n such a situation, the system will /ust revaluate the receipt, writing-o! remaining monetarybalance to the receipt o!set account a prot and loss account from inventory posting setup. &$t is worthto mention that a receipt o!set account for the purchases is a purchase consumption account frominventory posting setup'. #hat is, after an inventory closing, our receipt invent#rans will have originalthe cost price of ?)BC: in costAmountPosted eld and -).)? of the rounding error incostAmountAd/ustment eld, and transaction will be mared as closed.

$f the inventory closing is about to stop cost propagation &either because maximum number ofiterations has been exceed, or minimum throughput ad/ustment has been achieved' it uses the sameapproach. Uind of 0 3e received some ad/ustment from the previous iteration, we ad/usted the receipt.;ow we normally would apply this ad/ustment to settled issue transactions. +ut we won8t do it,because we are due to nish cost propagation. 9o 0 #o avoid misbalance between the receipt and thesettled issue, we /ust revaluating the receipt to the value of ad/ustment. ;ow, when we nally do nothave an ad/ustment to propagate we can safely remove this cost =ow from further iterationsN

Cpdate After very initial version of this article was published, $ looed into rounding mechanism ofversion .) and found the following picture $n version .)sp? method init$nvent9ettlement ofinvent@ost$temDim class, has new parameter added &VerrorAd/ustment'. #his parameter is set to true ifthis method is called from the createBrrorAd/ustment method, which, in turn, is implementing thisrounding errors mechanism. $t turned out, that service pac ? introduced changes to the handling ofrounding errors $f the parameter mentioned is set to true, then the system uses the prot and lossaccount from the inventory posting settings as an o!set account for an ad/ustment, not an o!setaccount from the $nvent#ransPosting of the receipt transaction as usual. +efore this change, allrounding errors were not, actually, written-o! to dedicated 12 account, but was hanging indenitely onthe o!set account of the original receipt. $f you still use any version older than .)sp?, $ recommendyou to bacport this change to your version. Furthermore, $ consider idea of writing o! rounding errorsto a P62 account as somewhat dubious. $t would be much more convenient for an end-of-periodreconciliation, to write-o! rounding errors to some dedicated 12 account, and then close this accountto either prots or loss accounts during an end-of-period balance reformation. #o achieve the re"uirede!ect, you need to modify method inventAd/errorAcountperation&'. $ would use variation accountfrom standard cost setup for this purpose. $f we actually use a standard cost mechanism for someitems, then this is very account intended for all receipt cost variations5 $f we do not use standard cost,we can /ust adopt this existing settings eld for our own logic. $f this scheme ts you,


22/30

costAmountAd/ustment eld'. #hus, after an initial nancial update of inventory receipt, the eld@ostAmountPosted will contain the original purchase cost, the eld costAmout9td 0 the standard costvalue and the eld costAmountAd/ustment will contain the variation between the standard cost valueand the purchase cost.

DAX2009 supports a co!pletely new way of wor% with a standard cost price. &he !odel, I descriehere, is rena!ed to @$i-ed 6eceipt GostB.

Inventory c$osin" %or serviceite&s$ should mae some preliminary point, that Dynamics AX has ambiguous model for setting up servicepurchase6sales

?. #here is a special inventory item type G9ervice $temH. ;o records in inventory on-hand table&invent9um' are created for items of this type5 #hese items can not be reserved5 1enerally 0the system prohibits all operations which can not be performed for a non-stocable item.

(. #here is a chec box GPost nancial inventoryH in an inventory model setup. $f this chec box isuncheced &which is as case for ** of service items',then on a nancial update of an item8spurchase, the cost is booed to a cost account &Purchase consumption account' instead of aninventory account as usual. &+y the way 0 the cost amount is in this case is written to thecostAmountperations eld of instead of the costAmountPosted eld'. n any inventoryoperation other than a nancial update of purchase, no 12 posting is created at all.

An inventory closing for service items is simply meaningless. Actually, an inventory closing isnecessary to calculate exact amount of costs transferred from inventory accounts to cost &@19particularly' accounts. $f we already have booed some item8s purchase expenses directly to costaccounts, what is the point in performing an inventory closing for this item 4 3hy should we spendtime and resources for the inventory settlement if we aren8t going to calculate an issue cost price fromthis settlement4 #hat8s why, starting from version .)sp?, service items was excluded from the regular

inventory closing routine. For all service item transactions, an inventory closing /ust sets transaction8ssettled "ty to total "ty, closes transaction, and creates the special settlement for this transaction,which has a Gservice item settlementH model in 9ettlementKodel eld.

$t is worth to remember about this new feature if you are upgrading from previous version and youhave checed the GPost nancial inventoryH checbox for service items in the old version8simplementation.

Why does negative inventoryoccur .rom time to time ?Probably everybody &even a fresh newbie' nows that Axapta has a mode, which allows to sell someinventory item before a corresponding purchase was posted &;egative physical inventory and;egative nancial inventory checboxes in inventory model'.Although, from time to time this mode isturned on &e.g. for service items', generally this mode is turned o! for the most of inventory items.#hat8s why newbie consultants become so confused, when they nd that, despite a turned-o! negativeinventory mode, inventory, somehow, went negative for some time periods.


23/30

$t is caused by the fact, that during physical or nancial update of an inventory transaction, Axaptachecs only @C::B;# inventory on hand. And if some merchandi7e arrived yesterday and we updatingthe issue on date before yesterday, then the system allows us to do it.

3hy it was designed that way 4 $n one of my pro/ects, $ redesigned and redeveloped the negativeinventory chec for nancial update of inventory transactions. $ had to write the code that checs aninventory "uantity for the date of the issue, and then runs through all inventory operations for the

given item and combination of inventory dimensions AF#B: the date of operation, to chec inventoryto become negative. $f an inventory issue was made on the current date, then this chec wasperformed only slightly slower then regular chec. +ut if operation was performed on the date, whichwas some ()-) days from the current 0 a delay was "uite noticeable, around %)-E) to time of aregular inventory update. Koreover, this chec also produced a lot of locs for inventory on-hand data.+ut when $ tried to develop the similar chec for a physical update of inventory transaction, $ ran intothe much more serious problem. $t was not clear for me- >ow should $ implement the chec for aphysical update of an inventory transaction in :eserved status. $t might happen, that a sales managerreserved some merchandi7e #DA


24/30

trillions+. 4o ( 3e ad"ised against usage of this feature if you ha"e a "ersionSser"ice pac% releasedefore su!!er of 200R.

$f during instant average calculation it turns out that inventory on hand does not have an item in"uestion, the system uses the price from inventory table &item details-Oprice discount-Obase price-Oprice' instead of an instant average. #he same value is used for items with a standard cost model.*6ena!ed to $i-ed 6eceipt Erice !odel in DAX2009+.

$f system calculates the cost price for a mared issue inventory transaction, it actually calculates thecost price of the mared receipt transaction, and then uses it with reversed sign. #his approachdecreases an estimated6actual cost price variation for mared transactions.

2dd postings3 on purchasereturnFrom newbie consultants $ "uite often hear the complaint about odd 12 postings8 on invoicing of thepurchase return. 9omething lie 0 G3hy $8ve got D Inventory C !ccounts Payable 45667&Ron

invoicing a purchase, and D !ccounts Payable C Inventory 45667&R8 D ther 79penses CInventory :667&Ron invoicing the purchase return4H

>ere is the reason for the case 3e must post the return amount &?))BC:' to Accounts Payableaccount. From the other side, if inventory maring is not the case, both estimated and true issue costprices might di!ers from the return amount. &$n our case 0 estimated cost is ?()) BC:'. DAX tries toresolve the problem with the following approach

?. :eturn amount &return price multiplied by the "uantity' is posted to Debit of Accounts payable

(. Bstimated issue cost price is posted to @redit of $nventory

. Qariation from return amount and estimated issue cost price is posted to @onsumption account

&specied as a Purchase consumption account in inventory posting setup'.

$n an end of accounting period, after inventory has been closed, this consumption account containsind of Financial :esult for Purchase :eturnsH. B.1 $f we managed to return an outdated merchandi7eto a supplier with the return prices being higher than cost price, then @onsumption account wouldhave negative balance &Prot'. $f it is not a case 0 then it would have positive balance &2oss'. $n the endof accounting period this account would be closed to ther 1ains6ther 2osses account.

Koreover, if after posting of returns, we have mared them to the transactions being returned, andreturn prices had not been di!erent from original purchase prices, then after inventory closing, wewould have the 7ero balance on the consumption account, because ad/ustments made during the $@would reverse the postings to the consumption account.

Physically updated inventorytransactions in ICAlthough $ have not written this before, but usually only nancially updated inventory transactions areprocessed by an inventory closing. &$ mean 0 inventory transactions in 9old or Purchased statuses,turned into these statuses during an invoice posting, inventory /ournal posting and so on'. $t is "uitereasonable, because during a physical update, an actual cost price of receipt is not nown, a physical


25/30

issue transaction can be returned without being invoiced and so on. #hat is why, before Axapta .)sp(,physically updated inventory transactions were completely ignored by an $@ process.

+ut starting from Axapta .)sp(, physical inventory transactions are included into an inventory closingprocess, but only as a second-class citi7ens. $@ tae physically updated transactions into account ;2ere is amain di!erences in costing process for these transactions

?. #hese transactions are not being rmly settled during inventory closing. $ mean 0 #hey aresettled between each other and with regular &nancially updated' transactions but only inmemory. ;o regular settlement record is made in $nvent9ettlement if one of the settledtransactions is physically updated.

(. An ad/ustment might be made for the settled physical issue transaction. #his ad/ustment isadded directly to the costAmountPhysical eld &not to the costAmountAd/ustment as fornancial transactions'. #he $nvent9ettlement record for this ad/ustment has the specialsettlement model 0 Physical Qalue

. n the nancial update of physical inventory transactions ad/usted by $@, ADLC9#BD amount isbeing reversed.

. $nventory transactions is included into inventory closing, deciding from a physical update date,not nancial one. 9o 0 $f you have a transaction, which was physical updated on ?.)* andnancially updated on ).?), then this transaction would be included into $@ for 9eptember.

$8ve met "uite dubious results of attempt to use this mode on actual implementations. First of all 0usually nobody cares about the date of physical update &pacing slip update'. $ witnessed the cases,where inventory transaction was updated with nancial date, which was earlier than physical date.Uind of 0 Kerchandise was processed by accountancy about ?) days before it has actually arrived towarehouse. #he second 0 $f by some reason purchase pacing slip has not been invoiced before end ofperiod, then "uite regular sales invoice will be sipped from regular costing and settlement in thecurrent reporting period, but, later on, it will be unexpectedly settled to some out-of-order receipttransaction. All the accountants would be very suspicious, why the August sale was settled to the

December8s purchase.

#his feature is not bad or good by itself. $t can be turned on without any problems, but


26/30

Jonestly spea%ing, I ha"e not actually used new features in a real i!ple!entation, so !ostinfor!ation was gathered fro! the XFF source code analysis. It is ;uite possile that I ha"e !ista%enin so!e details. &reat this article as a concepts guide, not as a detailed user guide.

3efore proceed any further, I want to !ention that old standard costing !echanis!s are still in placeand can e turned on y chec%ing @$i-ed receipt cost priceB chec%o- in In"entory Hodel groupssetup. 1ew standard cost functionality is turned on y specifying the @4tandard costB "alue in the

@In"entory HodelB eld of In"entory Hodel groups setup.

)pport %or stan!ar! cost va$e *istory

DAX2009 has the history of standard cost "alues i!ple!ented. &o loo% at or change the "alue of thestandard cost for an ite!, the Erice utton in the in"entory details for! should e pressed. &here aretwo tas on the for! appeared8 &he left contains planned, ut still not acti"e prices *ite!Erice4i!tale+. &he right ta contains the already acti"ated standard cost "alues *Ite!Erice tale+. It is notpossile to enter a "alue into the right ta directly. $irst, the new price should e entered intoite!Erice4i! tale, and only after that, it !ight e acti"ated y pressing the particular utton. $or a3OH in"entory ite! direct editing of cost prices is disaled e"en in the si!ulation ta. We will discussreason for that in the ne-t topic, which will discuss standard cost "ariations.

I a! glad to !ention that acti"ation procedure not only changes the "alue of standard cost in thehistory tale, ut also reva$ates in"entory on hand to the new cost "alue. Horeo"er, it is worth to listfollowing facts on the new standard cost !echanis!8

?. In case of post


27/30

E. A !anual in"ent on


28/30

rounding !echanis! for standard cost "ariations. *If this were not e a case, a!ounts fro! ?Lpostings wound not !atch data fro! "ariations tale *in"entGost&rans5ariance+. *Elease, !ention thedi7erence etween this rounding "ariance and rounding postings fro! in"ent on


29/30

"ariation %indFcost group co!ination, the syste! uses data fro! this tale to dene actual ?Laccounts to e used during posting.

$inally, to co!plete the discussion on "ariations and standard costing, we should discuss a standardfor! used to analye standard cost transactions *In"entory Hanage!ent


30/30

iteration so!e production issue transactions has een updated, the syste! proceeds *inin"entGostIte!Di!.updateIndirectGosts*+ !ethod+ with the indirect costs recalculation. If theseindirect costs actually were updated, then the syste! updates prodIndirect&rans data and push theindirect costs a!ount into the cost propagation routine. Also the standard in"entory settle!entposting routine was updated to support posting of newly created prodIndirect&rans records.

During an 3OHSEroduction order calculation, the syste! also creates calculation result lines with

indirect costs. And since calculation data are used for standard cost "ariation calculation, it !eans thata "ariation !ight also occurre fro! a di7erence in indirect costs

1ow ( Why do I consider this feature as unnished. It is o"ious that any !ore or less co!ple-production and production costing sche!e would re;uire to support di7erent costing sheets fordi7erent in"entory ite!s. If we would loo% closer on Dyna!ics AX internals, we nd that actually thesyste! has so!e prototype support for e-istence of se"eral costing sheets in parallel. 3ut it is only aprototype as of now. I suppose the !ore full

Documents

Goodexplaination_Inventoryclosing