Sage 100

Does anyone know WHY the IX CONV BB transaction in inventory is created? Many of them have 0 quantity, but an extended cost (postive or negative). Is this documented anywhere??

IM Transaction Types are in Help Text under: Transaction Types IX Transactions Purged Transactions: Sum of all the purged transactions, so you supposedly tie out beginning/activity/ending

I know what the standard definition is of all of the IM transactions and where to find them. What I am posting here has nothing to do with Detailed Purged transactions. It is the ""CONV BB"" IX transaction --- why does this get created? It is the very first transaction for this customer and converting to 4.40 created this. They have never purged any detail.

What's the date of the transaction? Is it on the last day of the prior year? I had a customer who had the same thing - some for huge quantities! There is no posting to the GL but it was difficult to explain WHY they were there to the customer.

Isn't that the one created when converting and there is a difference between the transaction detail and the whse detail?

Yes, I believe it is.

Yes it is the last date of the prior year ... they went live in June and that IX CONV BB transaction is there for 12/31 of the prior year. Yes, I too, am trying to explain to the end user why these transactions exist and where they came from. When I ran a report of all of these IX CONV BB transactions it totaled up to -5,847,394.39 ... that's a mighty big number!!

I know! I basically told them they are from the conversion to business framework so that going forward, the IM data is correct. Assured them it did NOT hit the GL and to ignore any of the CONV BB transactions when looking at inventory transactions. (Good thing he is one of my better clients and trusts me a great deal!)

@RobertWood you mean the Inventory Balancing Utility? I thought that only had to do with Quantity differences between IM_ItemWarehouse and IM_ItemTransactionHistory. I have a lot of these transactions with NO quantities too ... just extended cost amounts. HELP Sage why don't you have this documented for us? DId you think none of our customers would wonder what the heck these are??

That is what I was thinking they were. Not sure why they would be zero quantities with costs.

Documentation isn't Sage's strong suit.

I think the amounts are to reconcile to the current valuation, not just quantities. Could be wrong but that was my take. Have you ever run a detailed transaction report and had ending quantities of zero but a dollar amount? I have!

OH, yes, I sure have had Zero quantity with extended cost ... but in commenting back to you these transactions do affect the ability to reconcile to GL because if you run a valuation report (not a dated one), all of the transactions are taken into consideration to give you the ending valuation quantity and dollar balance. I tested this by creating my own Crystal Report for one item that had an IX CONV BB Zero quantity but -42,266.96 Extended Cost and the grand total on my CReport equaled the standard MAS valuation report. That means that the goofy 0 quantity negative extended cost transaction is used for giving you the value of your inventory which is supposed to tie to GL ... help this is driving me crazy. Help Sage please don't make me sacrifice a support case for this...

I will be calling Sage to get an explanation of how and why the CONVBB transaction is created and will post the explanation when I get it. Wish me luck!

Jane what version are you converting from and too?

I am actually trying to piece together some facts that already took place with this customer. I don't know what version they were on before they converted to 4.40 ... their upgrade took place prior to me.

Good luck! You'll need it.

This is what I bet happened. From Sage What's New 4.40 document - The 4.40 architecture creates a relationship between the Item Transaction History table and the period posting and summary history tables. All period posting and summary history tables will now have corresponding detail transaction records. The benefit of the new architecture is that the period posting tables, summary history tables, and detail transactions tables will always be synchronized and if the period end dates are changed, the tables can be recalculated to synchronize the data. During conversion, transaction records are reconciled with period posting and summary history tables. If the detail records do not match the summary history or period posting tables, the conversion process will now create missing detail records to force the synchronization. So if they have imported into the period or summary history files for reporting purposes this is the mess we are going to get .... based on what this doc says...

Trying to keep summary, history and transaction tables synchronized in a system that merely shares a file over SMB protocol is corruption and reconciliation hell just waiting to happen. This product so needs commit/rollback.

Thank you @DianeRuth for this documentation ... I thought I seen something documented about it way back when but in my searches couldn't find anything. This is the ticket!