Average Cost and General Ledger

Roadking

Member
Hi List,

I've investigated this to no end. JDE has cannot provide any assistance to the level of investigation that has already been performed. Perhaps there is someone here that can help me out.

We are on OneWorld Xe, Update 5, with Distribution and H/R baseline ESU's installed. Our platform is AS/400, NT, Citirix Server. We are using DSI for all of our warehouse transactions. We use the following modules:

Address Book
G/L
A/R
A/P
Fixed Assets
Inventory
Sales
Purchasing
Advanced Warehouse

We use branch plant processing, and use three way matching for our PO receipts. Landed Cost is turned on. Average Cost is turned on to update online.

We use receipts routing with two stages - the last stage updates inventory. 95% of receipts are in foreign currency and converted to domestic. Our inventory is valued in base currency.

Our costing method is Average Cost at the Branch Plant level. Our inventory (F41021) is relieved at pack confirm based on UDC 40/IU being populated with all of our Sales Document Types.

We have set UDC 40/AV to include only the following to update average cost since average cost should only be updated on incoming transactions.

ND3N4113 DSI Inventory Transfers
ND3N4114 DSI Inventory Issues/Adj.
ND3N4309 DSI Receipt Routing
ND3N4312 DSI PO Receipts
P4112 Inventory Issues
P4113 Inventory Transfers
P4114 Inventory Adjustments
P4312 Purchase Order Receipts
P43214 Reverse Purchase Order Receipt
P43250 Receipt Routing Movement
P43291 Landed Cost Selection



Here's the issue:

1. All transactions from the F4111 and the F0911 match on a daily basis according to the R41543 Item Ledger/Account Integrity Report.

2. All transactions posted on any specific G/L date in the Cardex (F4111) can be identified in the G/L when the Inventory Journal Report (R41550) is compared to the Invnentory account in the G/L (F0911). In effect duplicating the integrity report above.

3. We post all picked/packed/shipped sales orders through invoicing and end of day, post all of the inventory G/L batches.

4. The Inventory Valuation Report (R41590) is run using the average cost bucket (02) to determine the value of inventory.

5. The F0902 balance is then compared to the Inventory Valuation in number 4 above. These two blanaces do not agree.

6. We perform this reconciliation throughout the day and each time the difference between the two balances grows. On a daily basis, the NET change in the variance continues to grow and represents a SIGNIFICANT amount of cost.

Basically, my best guess is that something is happening to our average cost in the F4105 and not creating Journal Entries in the G/L. OR something is happening to the F4105 balances and should NOT be occurring. I have a feeling that DSI transactions might be affecting the F4105 values, however I have not been able to identify any JDE programs or DSI scripts incorrectly updating the F4105 through any of the audit fields in any of the inventory files.

I hope I've provided enough information. Any help or comments would be appreciated.

Thanks
Marco
[email protected]
 
Hello

Some Queries

1. Do you allow your stocks to go negative
2. Are all the zero balance adjustments AAIs pointing to the correct inventory account?.
3. Do you have sales returns coming in? Do they all come back at the current cost?
4. Most of your receipts are in foreign currency, this will lead to small differences.
5. Since you are comparing with F0902, check whether all the batches are posted.
6. Check the average cost and transactions generated after every receipt reversals. Receipt reversals can make your stock go negative without you knowing it since you will correct the LCC or the PO and get the receipt in again, this will mess up 4105 cost and Item ledger and G/L will tie up.

Just let me know answers to above, i will get back to you on my experiences.

Regards
 
In response to the posted questions:

1. Stock is not allowed to go negative.
2. Zero balance adjustments AAI are set up.
3. Sales returns come back at the current cost.
4. F/X creates small rounding errors, however the differences are quite large - not rounding.
5. All G/L batches are posted when referencing the F0902 balances.
6. Reciept reversal is rarley used...perhaps 4 times in the last year.
 
1. In XE update 5 there used to be an issue when you receive foreign POs as domestic. There was an issue on currency decimals.
2. when you run sales update, do you update the sales orders with the most recent cost?
3. how do you take back returns, are they fresh orders or orders from history, if you are taking it from history then check the cost in the return orders.
4. when your costimg method is weighted average, i always felt that on line inventory update caused issues. Just check out commit failed errors.
 
Marco,

The other report that you need to include in your reconciliations is the
R41544 - Item Balance to Item Ledger Integrity. This calculates the value of
stock and compares it with the sum of your Cardex at
Item/Branch/Location/Lot level. Although there are some problems with this
report depending on your Costing Level (i.e. Branch Level Average Cost
Valuations vs. Location Level Transaction values) it will highlight the
Items causing this imbalance and qualify whether some of the issues reported
in your replies are effecting you.

If you scan the KG for document ODS-01-0057 you can get more information on
this report and the set-up required (i.e. As-Of Processing).

Hope this helps.

Craig Potter

mber=47780
+ - - - - - - - - - - - - - - - - - - - - - - - -+
This is the JDEList One World / Xe(r) and World Applications mailing
list/forum.
Archives and information on how to SUBSCRIBE, and
UNSUBSCRIBE can be found on the JDEList Forum at
http://www.JDEList.com

JDEList is not affiliated with JDEdwards(r)

+ - - - - - - - - - - - - - - - - - - - - - - - -+



Craig Potte
 
Responses to questions:

1. I will have to investigate this, however I was hoping that the Distribution Basleine ESU would have brought most applications up to date.
2. Cost Update is not run at EOD with Sales Update since the most current cost was retrieved from the F4105 at the time of pack confirm (P4205) in conjunction with the 40/IU being set up with sales document types.
3 Credits are not retrieved from history.
4 We have not reported any commit fail errors in the past several months. Our system is stable.
 
Re: RE: Average Cost and General Ledger

Hi Craig,

I have investigated this report and it does not appear to work with average cost. JDE does not recommend using this report if average cost is being used.

We are currently not using AS OF reporting with the cardex and probably won't unti this issue is resolved.
 
I am sorry if I am not being very helpful.

1. If you can do a item wise check and check out differences happening specific items.

2. Yeah , you are right I also remember to have had problems with the report Craig had mentioned.

3. Are the G/L Date in the transactions ok? Check this , there is always an issue on differences between transaction date and G/L Date.

4. Check whether the cost is getting updated from the purchase price variance on the invoice match.

5 Is your landed cost set up ok. I think there is set up to say whether to include in cost calculation or not. Check out the effective date also.

6. I will suggest that you might need to go back to the drawing board and get a CRP done on a copy of the production and find out which transaction is affecting the cost.

Regards
 
I am also experiencing problems with average cost and believe it has everything to do with the fact that it is updated on line. I've already heard that switching to calculate the average cost in batch solves a lot of issues.

On the KG document ODS-02-0028 discusses Weighted Average Cost.

They also mention that you have to set up Alternative Languages for UDC 40/AV if not all of your users use the system language in their set-up. This was a reason why our weighted average cost got sour.

Hope this helps.

Regarding R41544, the standard report doesn't run for GL-period 1 because it has a problem with the century. I placed a call but haven't had any response. Our consultants have proved the error in the code so I hope it gets fixed soon, otherwise we will have to wait till february before the report runs again.
 
Back
Top