Ik snap het nog wel hoor,
De posts zijnde de "topics" kun je gewoon sorteren op kolom header.

De reply's = tread worden oudste eerst getoont, en dat zou handiger op nieuwste eerst kunnen
Immers in het toevoeg/edit scherm toon je ze ook zo gesorteerd

mvg

MK

Het veld "grondstoffen aanwezig" is bij de bijzigfunctie een tick-box en bij de toevoegfunctie een J/N veld.

Gelukkig voor Peter,
Anders mist hij al die input om zijn pakket te verbeteren... 

Hier werken we ermee.
Nog een puntje is de beperkte verslaglegging, daar willen we met Heart mogelijk in de nabije toekomst nog wat aan gaan doen (als ik mijn portomonee kan vinden)
2 punten die bij ons nog open staan:
1 - export naar excel ivm oveleg afdelingen + performance analyse
2 - koppelen van externe documenten (foto's en zo)

Verder werkt het op zich goed, ook omdat je de order naar een klacht-verkoop-order kunt promoten en dus ook op die wijze een klacht binnen heart kunt afhandelen.

Toch een tegenpunt:
Mijn mensen vinden de Windows versie wel veel langzamer werken en gebruiken (nog steeds) DOS als ze veel moeten invoeren.

In een tread niet

Als ik logisch nadenk zou ik graag gebruikers boven groep zetten, immers je regelt iets op groepniveau en daarna wil je voor bv 1 persoon een uizondering maken.
Middels de groepen zou je dus de basis moeten opgeven en dan per user verder verfijnen..

sorry je hebt gelijk, mijn vraag is onvolledig.
De posts kun je inderdaad netjes sorteren, maar ik bedoelde eigenlijk de treads.
Deze komen chronologisch in beeld ipv nieuwste eerst

mk

Vooral bij lange treads zijn toch meestal de 2 nieuwste het meest interessant, Het zou handig zijn als die op pagina 1 komen en niet op de tig-ste pagina

Het doel van deze functie is dat het af en toe gebeurde dat batch A op voorraad stond maar dat we labels van de klant kregen aangeleverd met batch B erop, en dan krijg je dus deze oplossing...

PS Menno, het doel van deze functie was hier eigenlijk een beetje vergeten. 

Op zich lijkt me dit heel valide.
Echter zou het dan eigenlijk op een "hoger niveau" voor alle prijzen bijgehouden moeten worden (even de accountant versie erop loslaten... )

Dat betekent dat je een redelijk uitgebreide tabel krijgt, en de vraag is hoe je die opbouwd.

Als je bv kijkt naar hoe het edit register artikelen werkt is dat niet ideaal opgebouwd. een systeem op basis van record welke naar bv excel kunnen op basis van een paar parameters (bv periode, user of verzin maar wat) is dan ideaal voor verslaglegging.

Maar dat geldt eigenlijk voor alle primaire stambestanden:
- artikel
- relatie
- debiteur
- crediteur
- prijzen
- ...

De vraag is hoe ver je wilt gaan met het loggen van dit soort zaken.
Een accountant zal n.l. altijd zeggen 100%

Het gevolg is echter wel dat als je nu in de database kijkt de 2 kernbestanden van Heart LOVM en ADBO zijn.
Deze groeien zeer snel t.o.v. de andere bestanden omdat dat de logistieke en financiele flow registratie is. Door allemaal mutatiebestanden toe te voegen word Heart wel steeds veeleisender mbt de hoeveelheid data.
(Dat is trouwens sinds de inzet van computers alleen maar een trend die zichzelf versterkt)
Bij AD zit er zo'n 1,3 GB aan data in de ADPF directory (1999 tot nu) waarvan ADBO 0.5 GB inneemt.
Als je dus ook op veel van de "logistieke" tabellen mutatiebestanden aan gaat maken zal Heart dus veel sneller groeien en moet je daar ook rekening mee houden mbt de inzet van data opslag en backup.

Daarnaast natuurlijk nog het financiele plaatje dat Heart voor al die functies mutatiebestanden moet maken en de programmatuur moet aanpassen.

Het is nog veel leuker, want veel "andere" variabelen werken ook in een etiket, dus als je iets niet kunt vinden kun je altijd nog een variabele uit een andere sectie proberen. vaak zal die gebruikt kunnen worden, gewoon een kwestie van proberen.

Ik kijk meestal naar de inhoud en test dan welke van de variabelen mogelijk in aanmerking komen. Dan gewoon printen en zien wat er van komt...

En als het echt niet gevonden kan worden even Richard vragen, want er zijn nog enkele variabelen die soms niet in de lijst te vinden zijn, maar wel aanwezig zijn en werken =)
Maar om de een of andere reden worden ze dan niet getriggerd bij variabelen raadplegen.

wel even opletten:
de inhoud wordt pas gevuld na het printen van minimaal label, anders kan die kolom leeg zijn!
bv net na een TBC

Beste Menno,

Volgens mij gaat jouw verhaal alleen maar goed bij mengrecepten met soortgelijke stoffen.
Als ik echter bv een neutralisatie recept hebt met natronloog 50% en vervang die door natronloog 33%, en het systeem gaat volgens jouw verhaal de boel corrigeren , heb ik volgens mij geen neutraal eindproduct meer !!

Of worden alle andere grondstoffen dan ook naar rato mee-gehusseld....

Zoals Peter vroeg: nieuwe tread