Heart-Profit ERP

We willen graag bij een offerte een veld 'Aangenomen'in kunnen vullen. Bv een vinkje om aan te geven dat de offerte is aangenomen, of dropdown "Aangenomen J/N".
Graag willen we dit veld ook terugzien in raadpleegscherm 3-7-1-5 LOOFGDRA, na de kolom "Open".
En dan gesorteerd op Open, vervolgens op Aangenomen, daarna op Geldig-tot etc.

Voor ons is dit een belangrijke status van de offerte: ofwel er is nog geen reactie op gekomen, ofwel hij is aangenomen (er komt een vervolgactie, bv binnenkort naar de klant om over de offerte te praten).

Kan dit? Zoja voor hoeveel?

Moet kunnen voor een 3 uur.

3 uur is akkoord.
Aangenomen middels vinkje heeft de voorkeur (en dan standaard niet aangevinkt)
en in kolom weergeven als Aangenomen 'J' danwel 'N'. Als dat kan.

Ik hoor het graag wanneer het klaar is, bij voorbaat dank :smile:
:13c:

Komt voor elkaar !

Hallo Pascal,

e.e.a. is gereed, vereist echter wel een upgrade.

Ok, bedankt, snelle service  :smile:
Ik zal binnenkort een update aanvragen.

Is het ook mogelijk alleen deze aanpassing in de Test-omgeving te zetten?

Ja ...

Zouden we heel blij mee zijn, als dat voor deze keer mag :smile:
:13c:

Upgrade staat klaar, alleen uitvoeren in de Test-omgeving dan.

Dank je.

We hebben de aanpassing bekeken in Test, ziet er goed uit en werkt.
Waar we nu tegenaan lopen is dat we deze kolom 'Aangenomen' ook graag in de overige raadpleegschermen terugzien onder 3-7-1-x

Igv 3-7-1-3/4/6 graag meteen na kolom Open.
Igv 3-7-1-1/2 is de plek minder belangrijk (als het maar niet te gek ver naar rechts is waardoor het uit beeld verdwijnt).

Is dit mogelijk en zoja wat kost dit?

3 keer 2,5 uur.


2 keer 0,75 uur.

Plus 1,25 uur voor het onderzoeken welke funkties aanpassingen behoeven gezien de aan te passen indexen (welk onderzoeken dus al is gebeurd :eek:)

Ik heb het besproken, het is akkoord mits de kolommen op de gewenste plek komen:


en igv 3-7-1-1 en 3-7-1-2 op de plek zoals aangegeven (zie schermafdrukken hieronder)

:13c:

OK Pascal.

Wanneer dit klaar is, kan ik dan een nieuwe update aanvragen, zodat ook de overige aanpassingen meekomen?
Dan kan ik de boel in 1x testen en ben ik meteen bij :smile:

Er staat nog een update in Test trouwens, deze is nog niet overgezet. Liefst zet ik er een nieuwe update overheen zodat we in 1x de boel kunnen testen en overzetten naar de Produktie-omgeving.
:13c:

Alweer ok. Moet je niet intussen die upgrade die er nu staat stiekem alsnog uitvoeren want dan loopt het echt fout.

Nee, de huidige update blijf ik vanaf en zet ik niet over naar Produktie, ik wacht op een update van jullie kant en die zet ik opnieuw in de Testomgeving.

Pascal,

e.e.a. is gereed, zeg maar wanneer je een Upgrade wilt hebben.

O heel mooi, als het vandaag kan zet ik hem komend weekend in de Test-omgeving.
Bij voorbaat dank!

PS: dit is een update incl. de aanpassingen van de vorige?
Want dan kopieer ik opnieuw de produktie-gegevens naar Test waardoor de vorige update komt te vervallen. En daarna zet ik de nieuwe in de Test.
In produktie is de laatste aanpassing die met volgnummer 24664:
05-Oct-12   13:06:43   Faktuur wordt als PRFILE.PDF gemaild ipv als Faktuur xxxxx.PDF

Standaard heb je in Profit Test- en Produktiebestanden.
Via een batchfile kun je Produktiebestanden naar de Testbestanden kopieren, opdat je in de Testbestanden aktuelere data hebt (kopie van je live database) om mee te testen.

Als je, zoals jullie, Profit-Base-Test hebt, heb je niet alleen Test- en Produktiebestanden, maar ook Test- en Produktieprogrammatuur.

Een upgrade van ons voer je dan uit in Test (Testbestanden + Testprogrammatuur), en zodra je akkoord bent met alle aanpassingen bepaal je dat je de Upgrade van Test- wilt overzetten naar Produktie (Produktiebestanden + Produktieprogrammatuur). Op zich mag je best meerdere Upgrades in Test uitvoeren alvorens je bepaalt e.e.a. over te zetten naar Produktie.

Nb: Onze Upgrades bevatten nooit de gegevens van een vorige Upgrade.
Hooguit komt het voor dat iemand een Upgrade aanvraagt, wij er een klaarzetten, maar de klant besluit de Upgrade niet uit te voeren. Zulke situaties moeten aan ons gemeld worden (wij gaan ervanuit dat als wij een Upgrade klaarzetten, deze ook wordt uitgevoerd), omdat wij dat de Upgrade in ons versiebeheer "terugdraaien", waarna de eerst volgende te genereren Upgrade je systeem zal updaten t/m de versie waarop de nieuwe upgrade wordt klaargezet.

Zodra je Upgrades pending hebt in de Testomgeving (dus, nog niet overgezet naar Produktie), heb je in de Testomgeving nieuwere programmatuur, maar ook nieuwere tabellen (of velden in tabellen). Als je op zo'n moment de Produktiebestanden over de Testbestanden heen kopieert overschrijf je alle tabellen met een oude versie, die niet de nieuwe velden bevat die bij de Upgrade in Test waren toegevoegd (klinkt wel logisch, niet?).
E.d. kopie mag dus alleen plaatsvinden als je daarna verplicht een Database Upgrade in de Testomgeving uitvoert;
deze vergelijkt opnieuw alle tabellen zoals die (dan) in de Testomgeving staan met hoe ze moeten zijn conform de laatst uitgevoerde Upgrade, en zal de structures waar nodig aanpassen.

Nog even een stapje verder... (ondertussen had ik het wel nog algemener op kunnen zetten en er een usefull topic van kunnen maken):

Na twee "bedrijfsparameter tabellen van ieder 254 velden" vol te hebben gekregen, zijn we bedrijfsparameters in een Systeembestand gaan registreren, met een indikator of de parameter voor de Produktie- danwel voor de Test-bestanden geldt. Als je alle DBF'fen van xxPF naar xxTF kopieert, kopieer je dus niet deze gegevens (parameters/instellingen) mee. Een kopie van Produktie- naar Test dient dus ook altijd te worden gevolgd door een kopie van deze parameters (zie Hoofdmenu,9,5,9,1,2).

Let op:
Het gebeurt niet vaak, maar toch zijn er af en toe ook "konversies" aan de orde bij een Upgrade. Wat er in zo'n konversie staat kan verschillen. Feit is dat als jij een bestand van produktie- naar test kopieert terwijl dat bestand aan een konversie onderhavig was, dan weet het systeem niet dat de konversie opnieuw moet worden uitgevoerd, en loopt e.e.a. alsnog de soep in.

Ik zal e.e.a. even duidelijk proberen te maken met een voorbeeld: Stel dat wij bij een Artikel een veldje "Aktief J/N" erbij maken, en vinden dat deze in de index van het Artikel moet worden opgenomen (Bedrijf + Aktief J/N + Artikelnummer). De Upgrade voegt het veldje toe aan de tabel, en een konversie is nodig om bij alle huidige records een "Aktief = 'J'" op te nemen.
Kopieer jij nu opnieuw het Artikelbestand uit de Produktieomgeving, dan is het veldje 'Aktief J/N' weer weg.
Voer de Database Upgrade uit, dan wordt het veldje 'Aktief J/N' weer opgenomen.
Hiermee is de intiële waarde echter "spatie" en geen J of N, terwijl er niets is wat opnieuw de konversie die deze vult getriggerd wordt.

Nb: Heb je geen Upgrade pending dan speelt dit probleem niet, immers, dan zal de Upgrade ook die konversie in de Produktiebestanden hebben uitgevoerd, en staat daar al een gevuld J/N veldje.

Resumer; omdat je zelf niet zult weten óf er konversies aan de orde zijn geweest bij je pending Upgrades, kun je zelf niet bepalen of het kwaad kan Produktie- naar Test te kopieren i.g.v. pending Upgrades. Altijd even vragen dus.

In dit geval zijn er geen konversies geweest, en dus zou je de Produktiebestanden- naar Test kunnen kopiëren mits je aanvullend een Database Upgrade doet in de Testbestanden.

Nb: Als laatste nog even een kleine toevoeging dat we Systeembestanden niet gescheiden hebben voor Test- en Produktie. Een "laatste Releasenote" waar je in Produktie naar staat te kijken zal dus dezelfde zijn als die je in Test ziet, terwijl die Releasenote i.g.v. een pending upgrade dus nog niet aktief hoeft te zijn in Produktie.

Pascal,

Upgrade staat voor je klaar.

Ok, ik zal in mijn upgrade-procedure opnemen dat na het kopieren van de Produktie-bestanden naar de Test-omgeving altijd "9-5-9-1-2 Kopieren Parameters Produktie- naar Test" vanuit de Produktie-omgeving uitgevoerd moet worden (dit dus allemaal voordat de upgrade in Test wordt gezet). Dan gaat dat in elk geval altijd goed.

Ik zal nu de eerder aangevraagde upgrade in de Test-omgeving laten staan en de nieuwe upgrade eraan toevoegen. Ik heb nl even gekeken hoe oud de gegevens in de Test-omgeving zijn en dat valt mee.
Ik kies in dit geval dus voor de oplossing die je eerder noemde:

Ik zal er in principe altijd voor kiezen de upgrade eerst volledig te testen en over te zetten naar Produktie voordat ik een volgende upgrade aanvraag. Maar nu weet ik wel hoe ermee om te gaan, mocht een aanvullende upgrade nodig zijn, dank daarvoor.

Is het trouwens een idee deze uitleg aan de Useful Topics toe te voegen? Hier zou ik nl als eerste zoeken wanneer ik even niet weet hoe met een upgrade om te gaan.

Ik ben de aanpassing aan het testen en zie dat in geval van menu 3-7-1-1 de kolommen 'Referentie' en 'Besteld door / bij' leeg zijn.
De inhoud lijkt een kolom naar links te zijn opgeschoven, zie schermafdruk.
Ook na reorganiseren TBC en F2 Grid Verversen verandert het niet.
:13c:

Hallo Pascal,

e.e.a. is opgelost en staat inmiddels bij je op het systeem.

Ik zie het, bedankt.