Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations IamaSherpa on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Changed OE values are not correct in GL

Status
Not open for further replies.
Jan 20, 2003
291
US
We are seeing a problem in the GL Trial Balance report where some of entries appear to be reversed (debit & credit). In looking at the data for the particular OE, all appears correct except the distributions are somehow reversed. This appears to be random and for us, apparently only applies to credits.

Through testing, we have determined that when a user enters the price as a positive number instead of a negative (for a credit), then later changes it to a negative (during the same session), it is only the positive or first value entered that appears on the TB report.

This explains how the OE information appears correct as the change is accepted in OE.

Is it possible that the information entered into that field does not get updated in the GL on subsequent changes?

I did not find anything in the infomine.
 
You are supposed to enter credit memos as a positive number, and Macola will process this as a credit. Why would anyone want to change this to a negative number?

Also, are you saying that on a multiple line credit memo only the first record appears on the TB, or only the first record is incorrect?

I tested this in 76300a with no problems.

Software Sales, Training, Implementation and Support for Exact Macola, eSynergy, and Crystal Reports
 
We enter credit memos as a normal OE and do not use the Macola credit memo as it affects inventory in an undesirable way for us.

The entry error is by line and the number of lines makes no difference. It appears that the first time you enter data in the field and tab out of it, that is the value that goes to GL. Any other changes to that field on that line are apparently ignored and not updated in the GL.

We are using 7.6.100a on SQL 2000
 
If you use C type orders for credits, you get the option of returning the inventory to stock or not when you process a credit. Since you are creating positive quantity transactions (I assume you aren't doing negative quantity AND negative price, which would probably really confuse macola since a negative times a negative creates a positive) with negative prices, you would have a larger problem in inventory because you would be creating issues from inventory at a negative price. If you really don't want to use macola as designed for credits, I suggest that you look at the data in the oeordlin_sql after you enter one of these transactions and find out what it is doing mathematically. You may need to delete out the offending line item & re-enter it for macola to update properly rather than assume that a change to a price alone will change the necessary information in the file. Also, do you confirm pick or ship, which also impacts the processing and timing of GL entries? And, do you have the problem with sales/AR as well as inventory/COGS?
 
When entering credits, the qty ordered field becomes the qty credited and then there's another field for qty returned. Everything is entered as a positive value. You would typically enter a qty credited and leave the qty returned as 0. This will create a distribution for sales and AR but not do anything to inventory and COGS.


Kevin Scheeler
 
We are entering credit memos, the problem comes in when we are entering the restock charge. Here in order to charge the restock fee to the customer on a credit memo we are entering negative values. It appears that if we enter it as a positive value and then go pack and put in a negative value it is not changing the values that drop to the general ledger.

The problems that I have found are effecting COG/Inventory not Sales/AR.
 
OK, now I see why you are changing this to a negative value.

It restocking charge setup as an item number? If so just give it a std cost of zero and there will me no COGS/Inventory effect.

I will do some more testing just to see how this is handled.

Software Sales, Training, Implementation and Support for Exact Macola, eSynergy, and Crystal Reports
 
Yes, the restock is a inventory item with a zero cost. However, the cost is changed during entry to a negative number. So when they are doing a C memo, they enter a negative price value and cost value and a positive quantity value.
 
Don't change the cost. Just change the price so it will "charge" them back. It then should only hit AR and Sales.



Kevin Scheeler
 
Internally, I'm not sure if they want to do that.

There is a need to capture a value here other than zero. It affects commissions and overhead expenses.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top