Documenten: Meer dan 35 artikelen in een document maakt het onwerkbaar

Het systeem wordt erg traag bij documenten met meer dan 15 artikelen.
Hoe meer artikelen er bij komen, hoe trager het wordt.
Bij meer dan 35 artikelen loopt de reactie tijd op naar 5 minuten per artikel.
Als groothandel is dit een "klein" document, dus de werkbaarheid komt erg in het gedring.

En zijn dat dan documenten waarop kortingen worden toegepast op artikelen? Of eenvoudige documenten met artkelen zonder poespas?

In de ene administratie zijn het artikelen met kortingen, en dat zijn bv. 486550 kortingen in de DiscountProduct tabel.
In de andere geval artikelen met varianten

Mogelijk heeft dit iets te makne met het algoritme dat voor de doclines de taxcategory bepaalt.

Ik heb een 1.0.2.162 klaargezet. Hierin is het mechanisme van btwgroep gewijzigd:

Voorheen werd continu de btw groep achterhaald obv docline, debiteur, product en producttype.

Nu wordt dit 1x gedaan waarbij het direct bij de docline wordt opgeslagen. Daardoor hoeft niet steeds de database bevraagd te worden.

Nadeel is wel dat 'afgeleid' niet meer werkt omdat de gevonden btwgroep vervolgens bij de docline wordt opgeslagen. (Hier komt later weer een tool voor zodat je eenvoudig alle btw groepen opnieuw kunt laten bepalen.

Ik verneem graag of dit een performance verbetering oplevert.

bgg wijzig ik het weer terug,

Het laden van een document gaat (op de server zelf) ogenschijnlijk heel veel sneller.
Morgen ochtend kunnen er verdere testen gedaan worden met toevoegen van artikelen en aanpassen van aantallen vanaf de werkplek.

Ik weet niet zeker of het met deze wijziging te maken heeft, maar ik constateer nu de volgende issues:
1) Het openen van een document welke door een andere gebruiker gemaakt is geeft deze fout meldingen:
Source: NopFinance.Plugins.Finance.Documents
Stacktrace:
   bij NopFinance.Plugins.Finance.Documents.Winforms.DocumentLinesHook.CommonLineEditorControl.<CommonLineEditorControl_Load>b__51_19(Object item)
   bij BrightIdeasSoftware.ObjectListView.MakeSubItem(Object rowObject, OLVColumn column)
   bij BrightIdeasSoftware.ObjectListView.FillInValues(OLVListItem lvi, Object rowObject)
   bij BrightIdeasSoftware.VirtualObjectListView.MakeListViewItem(Int32 itemIndex)
   bij BrightIdeasSoftware.TreeListView.MakeListViewItem(Int32 itemIndex)
   bij BrightIdeasSoftware.VirtualObjectListView.HandleRetrieveVirtualItem(Object sender, RetrieveVirtualItemEventArgs e)
   bij System.Windows.Forms.ListView.OnRetrieveVirtualItem(RetrieveVirtualItemEventArgs e)
   bij System.Windows.Forms.ListView.WmReflectNotify(Message& m)
   bij System.Windows.Forms.ListView.WndProc(Message& m)
   bij System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)
Message:
De objectverwijzing is niet op een exemplaar van een object ingesteld.
Inner source:

Inner stacktrace:

Inner message:


Source: System.Windows.Forms
Stacktrace:
   bij System.Windows.Forms.ListView.ListViewNativeItemCollection.get_Item(Int32 displayIndex)
   bij System.Windows.Forms.ListView.ListViewItemCollection.get_Item(Int32 index)
   bij BrightIdeasSoftware.ObjectListView.GetItem(Int32 index)
   bij BrightIdeasSoftware.ObjectListView.HandleReflectNotify(Message& m)
   bij BrightIdeasSoftware.ObjectListView.WndProc(Message& m)
   bij System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)
Message:
De objectverwijzing is niet op een exemplaar van een object ingesteld.
Inner source:

Inner stacktrace:

Inner message:


2) De korting berekening gaat nu mis.
Standaard prijs is 89.28, klant heeft vaste prijs van 68,- dat is een korting van 23.84%
Echter de document regel geeft 76.16% korting
En bij 2 artikelen 38.08% korting
En bij 3 artikelen 25.39% korting
En bij 4 artikelen 19.04% korting
Dus de berekening van de korting gaat niet goed.

3) De korting kan niet verwijderd worden zodat je de juiste erin kan zetten

In dat geval verwijder ik in 1.0.2.164 de aanpassingen op het kortingalgoritme.

In dat geval verwijder ik in 1.0.2.164 de aanpassingen op het kortingalgoritme.

Ik begrijp ook dat de aanpassingen tbv snelheid en btwgroepen ook niet uitmaken. Ik zal ook die weer verwijderen.

Ik zie dat als je een korting geeft van bijv 10 euro, de 10 euro van de totaalprijs afgaat ipv de eenheidsprijs