Shrinking Value Entry

Malajlo

I searched on forum, but no one did it yet.

One of our customers have a lot of records in T:32 and T:5802. I'd like to "reopen" item entries on new year since posting cost in G/L takes to much time.

So, what do you think about my idea:
- on sales side, orders should be invoiced
- on purchase side, all orders are invoiced as much as possible (that is the main problem)
- posted cost to G/L
- all open entries are transferred to new "internal" purchase order
- all open entries not invoiced yet are transferred to second "internal" p. order
- item entries without finished cost posting are not included in journal batch
- Item entry, Value entry, Item app entry are deleted (dimension entries etc also)
- purchase order is posted (recieve) only
- all remaining invoices from vendors can be posted using type=Charge item if there is any differencies in posted amount and recieved amount. Otherwise invoice is posted directly on G/L (or... amount is posted as Charge item and credit memo as Charge item is posted as "internal")

Any comments? Better way to do it? Did I miss anything?

Alex_Chow

Modifying and deleting ledger entries really bad ideas....

Is SQL being used currently as the database? SQL DB can handle large data sets better than NAV db.

bbrown

Why are you thinking of doing this? Is there a particular reason? Are you having performance issues? How many entries is "a lot"?

To put things in perspective, one client I work with has around 30 million Value Entry records in the database (one company).

Malajlo

Table No. Table Name No. of Records Record Size Size (KB) Optimization
32 Item Ledger Entry 296013 814 235176 94,1
5802 Value Entry 731857 1.903 1360136 95,5

I suspect following issue when i ran R:"Adjust Cost - Item Entries". This company uses Lansteiner retail and there is a lot of postings.
Unfortunately, purchase invoices are posted very late (I don't know why they need so much time... Lazyness?).
Therefore adjusting costs runs thru much more entries tha usual.

They are using native database and there is not so much entires that NAV could not handle.
NAV version is 4.0, server uses 350Mb cache. I should consider upgrading RAM.

If I comapre to i.e. our database (both databases are in use for almost the same time), T:32 is 2 times bigger and T:5802 5 times bigger. That's why I suspect "late" invoicing.

kapamarou

How much free space is there in the database?

Alex_Chow

There are a couple of ways to increase the speed of ACIE, however, all of the enhancements to ACIE to performance are in version 5. In version 5, you can run your ACIE by inventory periods so you're not running for the entire batche very time.

Nonetheless, always look at code/key optimization and hardware first before removing data.

Malajlo

Database has 63% free space. Tables are optimized.

I'll check speed on test databese with more memory allocated.