Heart-Profit ERP

Goedenavond,

Afgelopen weekend heb ik in de Test-omgeving relatie-id BAMAPE omgezet naar BAMZWO.
Bij controle van de databases kom ik BAMAPE in aardig wat databases tegen.
Kunnen jullie controleren waar er problemen zijn en welke evt geen kwaad kunnen?
(Uiteraard niet doorgevoerd in Produktie).

Hieronder schermafdrukken van de Textsearch-acties waar ik BAMAPE nog ben tegengekomen.
De databases zijn:
ADBO > lijkt alleen tekst te zijn?
ADOB > lijkt alleen tekst?
LOKP > tekstveld, handmatig aanpassen
LOUW > user-variabelen, zelf aanpassen
LOVM > lijkt alleen tekst te zijn?
LOOF > alleen tekst?

Als ik het goed zie gaat het bij bovenstaande 5 databases om tekst-velden die geen problemen opleveren of die ik zelf kan aanpassen?
De volgende databases zijn lastiger, hiervan heb ik de schermafdrukken voor het onderscheid in het volgende bericht gezet:
LOIO
LOMG
LOOA
LORZ
LOVB
LOVR
PKAU
PKKD
PKKO
PMML

Kunnen jullie controleren welke databases niet goed omgezet worden?
Bij voorbaat dank!

De lastige databases:

de laatste 3:

I.d.d. alles m.u.v. LOUW is tekst.
Ik kan alleen niet bedoordelen of jij LOUW zelf kunt aanpassen, maar, ervanuitgaande dat je het zelf schrijft, het zal.

"Faktuur komt van" had omgenummerd moeten worden.
We moeten uitzoeken waarom dat niet gebeurd is.


Management Defaults. Betreft "Statistiekselekties", waarvan we niet automatisch zullen kunnen herkennen dat bijv. een selektie bij letter F op een Debiteur slaat.
Zelf aanpassen :-(

Offerteregels, alwaar je een Relatie-id invult in een veld "Selektiekriterium".
Ook hier zegt niets dat een Selektiekriterium hetzelfde is als een Relatie.
Kan niet op een algemene wijze worden opgelost.

Relatie-/Zoeksleutels. Een lastige.
Een zoeksleutel hoeft geen Relatie-id te zijn, maar kan wel.
Wij kunnen deze op zich herkennen, en zullen hier iets voor moeten inbouwen.

Betreft Debiteur-/Afleveradres. Had ook omgenummerd moeten worden.
Moeten we ook uitzoeken.

Lijkt erop dat je deze ook als Selektiekriterium of i.d. hebt gebruikt.

Nb: Merk op dat het Selektiekriterium o.a. dient om een behoefte uniek te kunnen maken, en er is hooguit behoefte als de orderregel nog niet geleverd is. Is de regel eenmaal geleverd, doe je w.s. niets meer met dit veld.

Hebben allen met Kontakten te maken, waar een Relatie-id gebruikt wordt als Kontakt of Projekt-id.
Zouden als het goed is ook omgenummerd moeten worden.
Moeten we ook even uitzoeken.

:17c:

Wat betref LOUW - ik heb ze opgezocht maar deze kan ik toch zelf niet aanpassen helaas, zie schermafdrukken.

Dat vermoedde ik al, maar omdat al schreef dat je het kon aanpassen.

Hoe dan ook, ook deze had in theorie gewoon omgenummerd moeten kunnen worden, dus moeten wij ook even naar kijken waarom dat niet gebeurd is.

Van dit punt is de oorzaak inmiddels achterhaald; probleem is ook al opgelost.
Zie http://ha1.heartprofit.nl/profit/index.php?topic=26636.0

Ook deze opgelost, zie Releasenote http://ha1.heartprofit.nl/profit/index.php?topic=26641.0

Ook opgelost. Naast het omnummeren van de Relatie waar de Zoeksleutels aan hangen, wordt nu ook de 1e Zoeksleutel omgenummerd (het Relatie-Id). Zie http://ha1.heartprofit.nl/profit/index.php?topic=26643.0

Deze kan ik niet fout laten gaan. Misschien had LOVB eerst nog gereorganiseerd moeten worden ?

Ik heb hier nog even naar gekeken - eerst LOVB gereorganiseerd in de Test-omgeving.
Daarna een query gemaakt op LOVB, hier vind ik nog waardes BAMAPE (zie 1e schermafdruk).
In Profit vind ik deze zo snel niet terug, maar misschien heb je her wat aan?

Nee. dat zegt pas wat als je ná het reorganiseren eerst nog weer een Sleutelwijziging hebt opgestart;
en, ervanuitgaande dat BAMAPE al is omgenummerd naar BAMZWO, zegt dat niets.

Je zou wel BAMZWO weer kunnen omnummeren naar BAMAPE, om daarna weer BAMAPE naar BAMZWO om te nummeren.
Dan zou tabel LOVB weer opnieuw gedaan moeten worden.

Nb:
Overigens een compliment voor de wijze waarop je de Sleutelwijziging hebt voorbereid, en de schermprintjes m.b.t. waar je de voorkomens nog gevonden hebt. Helpt enorm bij de beoordeling van de situaties. :goodjob:

Ok, dit kan ik proberen.
Ben wel geneigd af te wachten tot alle tabellen met 'foute' waardes zijn bekeken en daarna opnieuw te testen of ik nog waardes tegenkom.

Bedankt - laat ik zeggen dat ik door schade en schande wijzer geworden ben:
ik wil niet weer de fout maken te lichtzinnig met sleutelwijzigingen om te springen  :smile:

Aan de andere puntjes wordt gewerkt. Als deze allen klaar zijn, stuur ik de aanpassing (indien mogelijk) over. Daarna kun je alles in 1x opnieuw proberen.

Oh mooi, dat is handig - wacht ik dat even af :smile:

Opgelost. Zie http://ha1.heartprofit.nl/profit/index.php?topic=26644.0

Opgelost d.m.v. een aanpassing in de Databasestruktuur (is al uitgevoerd op jullie systeem; PMML was toevallig beschikbaar).

Kontakten en Kontaktdeelnemers. In deze twee tabellen heb ik geen probleem aangetroffen, en bij mij wordt BAMAPE gewoon omgenummerd naar BAMZWO.

Misschien ook deze 2 tabellen even reorganiseren alvorens e.e.a. opnieuw te proberen ?

Daarmee ben ik aan het einde gekomen van de lijst met tabellen.

De Change-Key programmatuur zit grotendeels in de Systeemprocedure, en daar er dit maal aardig wat gewijzigd is in SY, durf ik niet zomaar een nieuwe Systeemprocedure op jullie systeem te zetten (horen dan vast ook wel Classes e.d. bij). Een Upgrade dus !

Ik vermoed niet dat er SY tabellen zijn aangepast, dus grote kans dat je die Upgrade gewoon in jullie Testomgeving kunt uitvoeren terwijl de mensen in produktie aan het werk zijn.

Zo, daar ben je nog behoorlijk snel doorheen gegaan, super!
Ik heb nog vragen mbt de volgende tabellen:

Zitten deze zgn. Statistiekselekties allemaal onder menu 8 Management Informatie? Dus als waarde ergens ingevuld in 1 van de (vele) overzichten, zoals onder menu 8-3-2-5?

Ik weet zo niet waar de waarde 'BAMAPE'  gevuld is.
Volgens mij niet bij statistieken of overzichten die we de laatste tijd nog gedraaid hebben.
Kan ik dit gewoon laten zitten en, mocht ik of Dinand hem tegenkomen, de BAMAPE dan alsnog wijzigen in BAMZWO?


Begrijp ik het goed dat het igv LOAA LOOA en LOVR waarschijnlijk selektiekriteria betreft die op zich kunnen blijven staan (want historie) en bij nieuwe orders er BAMZWO zal komen te staan?
Ik zie in de Test-omgeving dat selektie-kriterium automatisch wordt gevuld in de verkooporderregel/offerteregel met de debiteur-id waar de order/offerte voor gemaakt wordt (logisch).
Ik heb Hoofd administratie, verkoop en klantenservice gevraagd of ze hier iets mee doen en/of zelf invullen, maar dat doen ze niet.

Dus het kan geen kwaad hier verder niks mee te doen?


Voor wat betreft de update - wat is het handigst om te doen:
1. Update Test-omgeving, de changekey voor BAMAPE nog een keer draaien en vervolgens kijken of de wijzigingen nu goed gaan.
2. Eerst update aanvragen, testen en doorvoeren in Produktie en daarna nogmaals changekey BAMAPE testen.

LOMG wordt (naast CRM) ook gebruikt om bij het opvragen van een Statistiek te onthouden wat de gebruikte selektie is geweest;
betekent dat iemand ooit als laatste een overzicht op BAMAPE gedraaid heeft. Kan dan geen kwaad, want de eerst volgende keer dat hij zo'n overzicht opvraagt, komt het systeem standaard met een selektie op BAMAPE, en dan vul je gewoon een andere Debiteur in.

Ik weet dat een een bedrijfsparameter is waarmee je bij een Verkooporder het Selektiekriterium kunt laten vullen met het Debiteur id. Dan zou je niets hoeven te doen, en wordt dat voor de nieuwe orders vanzelf met BAMZWO gevuld. Maar... dat een Selektiekriterium op Afleveradres ??? Misschien is ze daar dan wel hard ingevuld, en wordt dié naar de order gekopieerd. In dat geval moet je dus wél wat doet, immers wordt de orderregel niet gevuld met het (omgenummerde) Debiteur-id, maar met een (niet omgenummerd) Selektiekriterium die je bij een Afleveradres hebt ingevuld. Even kontroleren-/testen dus.

Ik zou kiezen voor #1, en pas daarna de handel overzetten naar Produktie.
Misschien konstateren we toch dat een tabel als LOVB alsnog niet wordt omgenummerd, ondanks dat ze gereorganiseerd is, en dan moeten we toch even verder zoeken.
Zo heb ik bijv. ook gekonstateerd dat er naar BAMAPE óók een Relatie BAMAPE01 bestaat. Nu heb ik daar al mee getest, maar toch...

Kontroleer eerst in test of alles werkt, zo ja, dan kan het over naar produktie, zo nee, dan moeten we misschien eerst in test nog iets verder kijken.

Dank je, duidelijk. Dit vormt op zich geen probleem dus.

Domme typefout, LOAA moet de genoemde LOOA zijn - dus gaat om offerteregels, niet om afleveradres.
LOAA bevat de waarde BAMAPE niet, dus dat gaat gelukkig goed.

Ik zoek dan ook op "BAMAPE ". Is dit juist?

Ok, dan ga ik het proberen via methode #1.
Kun je binnenkort een update klaarzetten?

Dan ga ik 1 dezer dagen de Produktie-bestanden opnieuw kopieren naar de Test-omgeving,
de update uitvoeren in Test en BAMAPE opnieuw omzetten naar BAMZWO.
:17c:

Upgrade staat voor je klaar op de website.

Dank je - ga ik komend weekend installeren en de changekey testen.
Ik laat weten wat de resultaten zijn :smile:

Ik heb de update in de Test-omgeving geinstalleerd.
Vervolgens changekey BAMAPE > BAMZWO uitgevoerd.
Helaas loopt deze vast, het lijkt erop dat hij bij tabel PKKO foutloopt.

Ook opnieuw opstarten en PKKO reorganiseren en opnieuw proberen helpt niet - opnieuw een vastloper.
Zie schermafdrukken.

Voordat ik de changekey heb uitgevoerd heb ik eerst de bestanden ADWR, LOVB, PKKD  en PKKO apart gereorganiseerd.

Ik heb nogmaals een poging gedaan:
alle bestanden gereorganiseerd en de sleutelwijzigingen nogmaals geprobeerd door te voeren.
Helaas loopt hij opnieuw vast. Ditmaal data v/d foutmelding in schermafdruk.
:17c:

De "File already exists" kan alleen maar uit een rename opdracht komen. Zodra je kontaktverslagen met de DHTML editor registreert, zullen deze verslagen op het netwerk in de \FOX\PK\PKTF\PKKX\<editor>\<weeknr> directory worden geplaatst. Aldaar moeten deze gerenamed worden. Ik moet even kontroleren wat er precies fout is gegaan, maar mogelijk is het veroorzaakt omdat je eerst "alles" naar test gekopieerd hebt, en toen al een deel gerenamed is bij de vorige sleutelwijziging, nu weer alles gekopieerd is, en ook de eerder gerenamede versie er nu al staat.

Ik kom hier op terug.

Deze is nu ook opgelost. Zoals verwacht: zie http://ha1.heartprofit.nl/profit/index.php?topic=26704.0

Ik heb de sleutelwijziging al even op jullie systeem gedraaid, en deze gaat nu goed.

Merk op dat je deze nog niet naar Produktie hebt overgezet !

Dat klopt - ivm het kunnen oplossen van de problemen in dit topic heb ik niks met de Test-omgeving (of de update) gedaan.

Wat is wijsheid - kan/mag ik nu bij deze een nieuwe update aanvragen en deze installeren in de Test-omgeving?
Dan zal ik die testen en overzetten naar produktie.
Daarna kan ik nogmaals proberen de sleutelwijziging van BAMAPE opnieuw te testen.

Zolang je niet over de ADS versie beschikt, kun je gewoon een volgende upgrade in test uitvoeren, en het geheel daarna overzetten naar produktie.
Dus ? Upgrade klaarzetten ?

Kun je een upgrade klaarzetten, inclusief de aanpassingen van de voorgaande upgrade?
Dan kan ik de produktie-bestanden een keer opnieuw naar Test-omgeving kopieren, zodat de sleutelwijzigingen van BAMAPE die nu nog in Test staan worden overschreven.
Zo heb ik weer een 'frisse' Test-omgeving om in te testen.

Upgrade staat voor je klaar op de website.

Dank je - dan zet ik deze week produktie-bestanden over naar Test en ga zsm de update installeren & testen.

Na het overzetten v/d update zal ik ook een nieuwe poging wagen vwb sleutelwijziging BAMAPE>BAMZWO.

Voordat ik de update installeer wil ik graag de produktie-bestanden naar de Test-omgeving kopieren zodat ik goede, up-to-date bestanden in de Test heb staan (in de Test staat ook nog de mislukte sleutelwijziging BAMAPE>BAMZWO).

Nu ik de update heb gedownload zie ik dat hij kleiner is dan de vorige update BS150319.EXE
De vorige update is niet getest en doorgevoerd in Produktie.
Ik vermoed dus dat de nieuwe update BS150428.EXE niet de aanpassingen van BS150319 bevat.

Hoe moet ik dit aanpakken - kopier Produktie>Test, uitvoeren BS150319 en daarna uitvoeren BS150428?
Of moet er een nieuwe update gecompileerd worden?
(de laatste update die WEL is doorgevoerd is dus BS150123).

Als we het hebben over "Produktie naar Test kopieren" dan hebben we het alleen over het kopieren van de database !
Nooit over programmatuur, daar moet je van af blijven.

Dus, database kopieren naar test, dan een database upgrade doen (om de structure van produktie in test gelijk te maken aan de versie zoals ze daar hoort te zijn), en dan de upgrade uitvoeren.

Kopieren Produktie > Test doe ik mbv volgende macro:


Daarna doe ik nog:
- inloggen Profit Produktie, "9-5-9-1-2 Kopieren Parameters Produktie- naar Test”
- vervolgens menu 9–9–8–1, F1 (uitvoeren upgrade in Test-omgeving)


Klopt deze werkwijze dan wel?

Verder telefonisch afgehandeld.

De zoek-tool die ik gebruik is hier te vinden:

https://www.mythicsoft.com/agentransack