ICHIST TransType = 12 (Tranfer From)

[iwells]

Hi,

I'm trying to rebuild transactions from ICHIST and I'm noticing I have a large amount of data in TRANSTYPE = 12 that has negative QUANTITY and positive HOMEEXTCST and I expect that typically these should both be negative.

To give you an idea I'm querying as follows:

select COUNT(ICHIST.TRANSTYPE) from ICHIST where TRANSTYPE = 12 AND HOMEEXTCST < 0 AND QUANTITY < 0
select COUNT(ICHIST.TRANSTYPE) from ICHIST where TRANSTYPE = 12 AND HOMEEXTCST > 0 AND QUANTITY < 0

The first query returns 4000 records and the second 2000 records. When I look at documents that are the same, say TFR00001, the cost is positive for both TRANSTYPE 12 and 13, but the quantities are negative for 12 and positive for 13.

I've run a data integrity check and it finds no issues. What further boggles my mind is the date in which the issues appears to "correct" itself and is fixed at a specific fiscal year and period. What even further boggles my mind is that on the same server in the same Accpac installation (5.6A) there are 2 other companies that have the same issue, but their "correction" fiscal year and period are all different from each other but also have the same issue. I thought maybe there was a known issue with accpac that was corrected with a version of PU, but all these companies would always be on the same version and PU.

We have many other accpac installations that came from the same version where the issue does not exist or is less than 0.01% of the transactions have this issue, but we have 4 installations that show almost 40% of the transfers of the overall transfers have this situation occurring.

Is there a valid reason for this I'm not understanding as someone prior to me believed that in prior version you had to force the amount for TRANTYPE = 12 to a negative value and that was the database functionality?

 

[ettienne]

TRANSTYPE 13 Integer Transaction Type E A List:20 entries

1 = Receipt
2 = Receipt Adjustment
3 = Receipt Return
4 = Shipment
5 = Shipment Return
6 = Adjustment Quantity Increase
7 = Adjustment Quantity Decrease
8 = Adjustment Cost Increase
9 = Adjustment Cost Decrease
10 = Adjustment Both Increase
11 = Adjustment Both Decrease
12 = Stock Transfer From
13 = Stock Transfer To
14 = Master Item Assembly
15 = Component Item Assembly
16 = Invoice
17 = Credit Note
18 = Debit Note
19 = Shipment Adjustment
20 = Internal Usage


Sage 300 ERP Certified Consultant

http://www.adssglobal.net

 

[ettienne]

You need to get a copy of the AOM:

https://support.na.sage.com/selfser...nisa.apps.common.BaseViewedDocsListHelperImpl

Sage 300 ERP Certified Consultant

http://www.adssglobal.net

 

[ettienne]

Flip flopped qty/costs are a symptom of bad inventory costs caused by negative inventory or bad adjustments done by users.

Sage 300 ERP Certified Consultant

http://www.adssglobal.net

 

[iwells]

Hmm ... when i look at transactions i have the following

Document = TRF00001

when transtype = 12 quantity is negative and cost is positive
same document, corresponding transtype = 13 quantity is positive and cost is positive

on the same transfer for both the 12 and 13 for a large number of transactions the cost is positive on both, while the quantity is negative and positive respectively

 

[iwells]

I thought the same thing and I looked at the item and there are 4 receipted in to history on this one item, next transfer this occurs and there are no other transactions before it

 

[ettienne]

Bad costs in IC....

Sage 300 ERP Certified Consultant

http://www.adssglobal.net

 

[iwells]

I uploaded an example just to show you ... I'm still digging, but i have plenty of examples like this.

 

[iwells]

Database dump/load in progress just to see

 

[Jay Converse]

Database dump/load is a complete waste of time.

 

[ettienne]

I've seen this thousands of times... caused by users mainly.
Dump/load will do nothing except take up your time.

Sage 300 ERP Certified Consultant

http://www.adssglobal.net

 

[ettienne]

Remember that costing is done by location.

Sage 300 ERP Certified Consultant

http://www.adssglobal.net

 

[iwells]

ettienne, how can a user cause this?

I'm looking at a transfer that has this issue, no additional costs or anything have been entered.

 

[ettienne]

Look at the historical transactions for the item, somewhere someone screwed it up.

Sage 300 ERP Certified Consultant

http://www.adssglobal.net

 

[iwells]

I'd agree with you if it weren't for the obvious dates when the issue started and stopped ... and the fact that when I look at the users its the same user still processing the inventory transactions at those branches.

 

[ettienne]

Let us know what it is once you figure it out.

Sage 300 ERP Certified Consultant

http://www.adssglobal.net

 

[iwells]

Will do ... it's also that occurs in different countries with different users. The issue really seemed to stop around 2012, that' why I wondered if there was a known data issue with those 2 transtypes that was corrected in later versions. I'm wondering if we had a screen modification in use or an import template perhaps that caused it.