Heart-Profit ERP

Ik heb in onze Test-omgeving de volgende sleutelwijzigingen uitgevoerd:
LORE_RID, MATKAM gewijzigd in SPRLOO
LOAR_AID, BT30305ZWKVE gewijzigd in BT30305ZWKVK

Wanneer ik via de tekst-search controleer of de oude waardes nog voorkomen kom ik MATKAM nog tegen in de volgende databases:

\FOX\LO\LOTF\LOZX.DBF rubriek APTX_KEY (samengestelde sleutel)
\FOX\LO\LOTF\LOVR.DBF rubriek PRKRIT
\FOX\LO\LOTF\LORZ.DBF rubriek LORZ_SLT

De waarde BT30305ZWKVE kom ik nog tegen in database:

\FOX\LO\LOTF\LOUW.DBF rubriek LOUW_KEY (samengestelde sleutel)

Zie schermafdrukken hieronder.
Kunnen jullie hier eens naar kijken?

Al iets meer bekend?
Ik zie nog geen rondje draaien.

Kijk aub anders eerst naar de BT30305ZWKVE, waar de waarde maar in 1 tabel terugkomt - dan kan ik hier vast mee verder.

Misschien wel te moeilijk uitleggen, maar eigenlijk kwamen we (tot heden) zelf niet goed op een antwoord. Kleine poging :

Je Selektiekriterium is niet terecht, ook al zal je zelf wel denken van wel. :smile:
Feitelijk betreft dit Produktie Kriterium, wat helemaal niet meer terecht kan zijn.

De Zoeksleurel (LORZ_SLT) : min of meer hetzelfde verhaal, maar nog iets moeilijker re verantwoorden (door ons). Maar toch.

... Wat niet wegneemt dat je met bovenstaande best problemen zal hebben ...

De User Variabelen (beter : Waarden (LOUW_KEY)), is wel terecht lijkt ons, maar is redelijk idioot moeilijk om op te lossen. Hebben we gewoon nooit aan gedacht (in kombinatie met ChangeKey). Er is in deze nog wel meer ook.

Tot zo ver maar even een antwoord (soort van).

Wèl erg goed dat je het in Test hebt geprobeerd ! :yes:

Conclusie, ik moet nog even afwachten?
Wanneer ik problemen kan verwachten in de huidige situatie, ga ik geen risico lopen door ze over te zetten.

Nee, zou ik zeker niet doen !

De laatste tijd wordt me weer regelmatig gevraagd of ik al een keer weer verder kan met de wijziging van enkele relatie-id's en artikel-id's.
Uiteraard heb ik uitgelegd dat het niet zo eenvoudig op te lossen is en men geduld moet betrachten, maar op termijn wil ik hier toch verder mee.
Is er enig inzicht in op welke termijn eea opgelost zou kunnen worden?

Ik hoop dat je nog even geduld kan hebben. Maar dan nog moet je er rekening mee houden dat het alleen om die User Variabelen kan gaan hoor ...
Volgens mij vind je dat al minder leuk.
:17c:

Even voor mijn begrip: jullie zijn dus bezig met de laatstgemelde fout in LOUW (user variabelen) en daarmee de enige melding vwb het wijzigen van artikelen?
Wanneer dit opgelost wordt, kan ik dus nogmaals een aantal artikelen testen om te kijken of dit goed gaat?

En wat betreft de wijzigingen in relaties wordt het verhaal echt lastig?

Ja en Ja.

De Relaties waar jij het over hebt, zijn helemaal geen relaties. Het zijn in feite afgeleiden waar toevallig een Relatie ID in staat. Neem de Zoeksleutels maat als het beste voorbeeld. Het is gewoon een veld bij de Relatie, waar jij toevallig hetzelfde invult als het Relatie-ID zelf. Het is niet eens een sleutel ... (zelfde voor die andere dingen).

Mbt de zoeksleutel kan ik me voorstellen dat die niet omgezet wordt (rubriek LORZ_SLT in LORZ).

Maar vwb FOXLOLOTFLOZX.DBF rubriek APTX_KEY lijkt er wel een probleem te ontstaan: deze key lijkt de koppeling te vormen tussen tekst van een kontraktheader en het kontrakt. Zie voorbeeld: de kontrakten worden keurig omgezet van MATKAM naar SPRLOO, maar de teksten die aan het kontrakt hangen zijn verdwenen (of niet meer te vinden ivm niet omzetten zoeksleutel):

:17c:

Sorry, die heb ik steeds overgeslagen zie ik nu. Dit, terwijl het de meest terechte is van allemaal (domweg een bug).

Ok, ik schrok al.
Maar nu het volgende: ik wil graag een update aanvragen, de laatste was 2 september.

Nu staan de gewijzigde sleutels (en hetgeen er fout gaat) nog in de Test-omgeving.
Willen jullie deze data nog beschikbaar hebben, of kan ik produktie overzetten naar Test en de update aanvragen en installeren?

Problematiek m.b.t. LOZX (en trouwens ook LOAX v.w.b. teksten op regelniveau) kunnen wij hier gewoon nadoen;
LOUW zullen we hier vast ook wel na kunnen spelen.

Wat dat betreft hoef je daar niet een situatie live voor te houden in Test.

Dat scheelt, bedankt.
Ik overleg nog even intern wanneer de update het beste aangevraagd kan worden.

LOZX en LOAX zijn inmiddels opgelost, zie http://ha1.heartprofit.nl/profit/index.php?topic=23845.0
Dit zal in je eerst volgende Upgrade zitten.

Deze tabellen waren "relatief simpel" omdat we al een mechanisme hebben voor "tekstbestanden bij een entiteit";
de oplossing van LOUW zal wat langer op zich laten wachten. :(

Ok mooi, dan kan ik dat gelijk testen wanneer ik bij de volgende update opnieuw Produktie > Test kopieer.
Voor de rest wacht ik weer af. Ik snap ook wel dat niet alles in 1x gefixt kan worden, maar zolang er voortgang in zit ben ik allang blij :smile:

In februari heb ik in de Test-omgeving opnieuw een aantal sleutelwijzigingen uitgevoerd, als test. Deze wil ik allemaal in de toekomst overzetten, vandaar dat ik nieuwsgierig was naar waar het evt nog mis gaat op dit moment.
Onze laatste update is van 22-11-2012 volgnr 23739.

Onderstaande artikelen (LOAR_AID) heb ik omgezet in de Test-omgeving:

Oude waarde:   Nieuwe waarde:
DFMK8BRUIK   DFMK8SIERK
DF8KFGRIJK    DF8KFGRBAK
DFMK8GRIJK   DFMK8GRBAK
VBT303045GRIJK   VBT303045GRIJ
71513GRIJ   71513GRIJK
VB13151025GEBDK   VB1315G1025GEBD
VB13151025ZWKV   VB1315G1025ZWKV
VB13151025GRIJS   VB1315G1025GRID
VB10251315GEBDK   VBG10251315GEBD
VB10251315GRIJS   VBG10251315GRID
DF8GECAK   DFN8VESUK
DF8BRUIK      DF8SIERK

Zie schermafdrukken voor de gevallen waarin ik de oude waardes nog tegenkom.
Wanneer deze waardes in bv teksten voorkomen heb ik deze eruit gefilterd, voor zover ik ze herken.
Igv tabel LODA komt de identiteit in voor in LOSU_SID "/1BBB-BETON" en betreft het oude prijs/kortingsafspraken (2000/2001). Misschien zijn die dus niet erg relevant.

LOBH is een bestand met Elementaire Behoeftes. Deze tabel wordt tegenwoordig helemaal niet meer gebruikt, en je kunt het vullen van die tabel met een behoefterunparameter ook uitschakelen.

LODA / 1BBB-BETON. Inderdaad, de bedrijfs-id komt niet overeen, en dus logisch dat deze niet omgenummerd wordt.

LOLR zou in principe gewoon moeten werken. Kun je bij deze records een kijken wat de LROPEN indikator bevat?

LOUW / Uservariabelen; was al bekend.

PKAG. Agenda / Afspraken. En zo te zien iets wat uit een Prijs of een Kontrakt is gegenereerd?

Leuk zo'n module waarmee we proberen te doen wat in heel automatiseringsland niet is toegestaan :-)

Ok, die kan ik dus negeren.

Klopt, geen nieuws wat dat betreft (had 'm weg kunnen laten voor het overzicht).

LROPEN staat voor alledrie op 'N'.

Vind ik moeilijk om te achterhalen, ga ik verder naar kijken.

Ja - en als het bestaat dan ga je het nog gebruiken ook... :wink:

Ik wil graag een update aanvragen - kan ik de gegevens in de Test-omgeving overschrijven? Of is het voor de changekey handig dat de gegevens beschikbaar blijven?
De gevonden waardes PKAG kan ik niet 1-2-3 terugvinden in de Test.

Bvd!

Je hebt de voorbeelden duidelijk beschreven, dus ik denk dat we dat wel moeten kunnen reproduceren;
laat het i.i.g. geen Upgrade-aanvraag tegenhouden.

Ok, graag bij deze dan  :smile: . Bij voorbaat dank! > ik heb even apart een aanvraag voor een upgrade gedaan, ivm het overzicht.

Ter info: deze ben ik uiteindelijk tegengekomen, waardes staan onder menu 2-9-4-6-1
Bv van gebruiker GTH, zie schermafdruk hieronder.
We gebruiken de agenda trouwens verder niet actief (gebruiker kent de funktie zelfs niet).

Ik wil graag DFMK8BRUIK en DFMK8GRIJK omzetten.

Voor deze 2 artikelen worden de waardes in tabellen PKAG en LOUW niet omgezet.
Vwb LOUW willen we het oplossen door de waardes handmatig aan te passen.
De PKAG is voor zover ik kan beoordelen de tabel met kontakten in de persoonlijke agenda - wanneer we deze niet gebruiken, kan het dan kwaad de 2 artikelen om te zetten?
:17c:

De records voor PKAG blijken uit Funktie Triggers te komen. Funktie Triggers kun je niet alleen gebruiken om een email mee te verzenden als er een bepaalde funktie wordt uitgevoerd, er is ooit ook een optie opgenomen om een trigger via een formele Agenda (Profit-Workflow) te laten lopen.

Zo te zien hebben jullie daar vorig jaar een tijdje mee getest bij Kontrakten. Inmiddels staan alle Funktietriggers zodanig ingericht dat ze niet via de Agenda lopen, maar in de periode tot 29 april 2011 zijn er diverse Agenda punten als gevolg hiervan gegenereerd. Ik sluit niet uit dat er in die hoek ook iets niet werkt of verkeerd is ingericht, want, gezien soms talloze dubbele sleutels bij Kontakt-Deelnemers, vermoed ik dat e.e.a. nog wel eens in een loop heeft gezeten.

Zojuist (tel. overlegd) derhalve alle Afspraken en Afspraakdeelnemers van deze Funktie Triggers eruit gegooid. Dit alleen in Produktie. Tabel is overigens ook niet gereorganiseerd (er zitten mensen in), dus, een Tekst Search zal nog steeds wat vinden in deze tabel, maar dat kun je negeren. Er zal in PKAG niets meer hoeven te worden omgenummerd.

Resteert dus LOUW, en daarvan gaf je aan die zelf te doen.

Per heden is Profit-Change-Key zodanig aangepast dat deze nu ook omnummert in User Variabelen en tevens in Multi Media Buttons (http://ha1.heartprofit.nl/profit/index.php?topic=24510.0).

E.e.a. vereist een Upgrade.

Dat is goed nieuws!
Volgens mij zijn er nu geen tabellen meer die nog problemen geven (?).

Dan ga ik na de bouwvak voorzichtigaan ook weer een aantal relaties omzetten :smile:

Onderstaande artikelen (LOAR_AID) heb ik omgezet in de Test-omgeving:

Oude waarde:   Nieuwe waarde:
71513GRIJ   71513GRIJK
VB10251315GEBDK   VBG10251315GEBD
VB10251315GRIJS   VBG10251315GRID
VB13151025GEBDK   VB1315G1025GEBD
VB13151025GRIJS   VB1315G1025GRID
VB13151025ZWKV   VB1315G1025ZWKV
 en:
283026IVBLHARD   283026IBLHARD
283026IVBRHARD   283026IBRHARD
283026IVBTHARD   283026IBTHARD

Die eerste 6 heb ik al eerder in de Test-omgeving omgezet en de problemen gemeldt.

Het goede nieuws: controle van de databases (.DBF) op het voorkomen van de oude waardes leverde voor nog maar 1 artikel een probleem op:

In Test is 71513GRIJ omgezet in 71513GRIJK.
Controle leert dat de waarde 71513GRIJ nog voorkomt in \LO\LOTF\LOLR.DBF, en het zijn exact dezelfde 3 waardes als in de post Reply #16 on: February 28, 2012, 02:17:24 pm

Zie ook schermafdruk hieronder - in het raadpleegscherm staat nog het oude artikel, terwijl deze bij de artikelen zelf niet meer voorkomt.
Ik heb uiteraard de Produktie-bestanden naar de Test-omgeving gekopieerd voordat ik de sleutelwijzigingen heb uitgevoerd in de Test-omgeving.

Ik denk dat die LOLR situatie er bij ingeschoten is. Lees ook nergens dat daar iets voor is aangepast, terwijl deze wel fout gaat.
Ga ik naar kijken.


:17c:

Ik heb de situatie hier na kunnen doen, en ik denk dat ik hem opgelost heb.

De aanpassing staat al op jullie systeem.

Ik heb tevens een nieuwe Sleutelwijzigingsopdracht erin gezet, waarmee de 71513GRIJK weer even teruggenummert wordt naar 71513GRIJ. Als je die uitvoert, en daarna opnieuw 71513GRIJ omnummert naar 71513GRIJK, doet hij als het goed is wel alles.

Ok, dankje, ik zal het proberen deze week uit te voeren en de databases te controleren op gewijzigde waardes.
Ik post de resultaten in dit topic.

Nu ging het omzetten goed.
Bij het terugnummeren naar de 71513GRIJK ook gecontroleerd of er nog een 71513GRIJ aanwezig was, dit bleek niet zo te zijn.
Na omnummeren naar 71513GRIJ is er ook geen 71513GRIJK meer aanwezig.

Hartelijk dank!