Hi all! In a Danish database (3.70) I found an (AddOn?) module for Payments (Version List PM3.01.01.2.02). In table 6016818 Payment Ledger Entry there is a field named UPR-No. which is filled OnInsert of a record by calling this function: AssignUPRNo() UPR : Integer // AssignUPRNo PmtSetup.GET; PmtSetup.TESTFIELD("UPR-No. (Min.)"); PmtSetup.TESTFIELD("UPR-No. (Max.)"); RANDOMIZE; UPR := RANDOM(PmtSetup."UPR-No. (Max.)"-PmtSetup."UPR-No. (Min.)"+1)+PmtSetup."UPR-No. (Min.)"-1; PmtLedgEntry2.SETCURRENTKEY("UPR-No."); PmtLedgEntry2.LOCKTABLE; IF PmtLedgEntry2.FIND('-') THEN; Attempt := 1; REPEAT PmtLedgEntry2.SETRANGE("UPR-No.",UPR); Ok := NOT PmtLedgEntry2.FIND('+'); IF NOT Ok THEN BEGIN UPR := RANDOM(PmtSetup."UPR-No. (Max.)"-PmtSetup."UPR-No. (Min.)"+1)+PmtSetup."UPR-No. (Min.)"-1; Attempt := Attempt + 1; END; UNTIL Ok OR (Attempt = 100); IF NOT Ok THEN ERROR( Text000, PmtSetup."UPR-No. (Min.)", PmtSetup."UPR-No. (Max.)", PmtSetup.FIELDCAPTION("UPR-No. (Min.)"), PmtSetup.FIELDCAPTION("UPR-No. (Max.)"), PmtSetup.TABLECAPTION); What is a UPR-No, what is it used for? Why is it created randomly? Could it be skipped/ignored? Please enlighten me! Kind regards,
UPR means “Unique Payment Reference” and is used to identify the payment. Obviously it cannot be skipped or ignored - and why would you?
Hi Steffen, thanks for your reply … “Unique Payment Reference” , I guessed it was something like this … So, this has to be a unique identifyer, but I’m still wondering why this UPR-No. is calculated using RANDOMIZE/RANDOM and not just by e.g. using a NoSeries or something … The problem is, that this function “AssignUPRNo” is really **** regarding to performance: It calcs a UPR, then it locks the Payment Ledger Entry table and runs a loop - up to 100 iterations, calcualting again a UPR and checking if this No. is already available … WHY is this done like this? Why not simply take a No. from a setup, increase by one (maybe check if unique), assign UPR, modify setup …
Hi Joerg, I’m not sure why it’s done this way (but I’m quite sure it’s done for a good reason). The product is developed by a danish company called Celenia, check out www.celenia.dk - maybe you can get an answer from them. Anyway you can fiddle with the “UPR-No. (Min.)” & “UPR-No. (Max.)” values in order to decrease the number of iterations.
Thanks for the advice! I’ll get in contact with them …
NP - and please let us know what they say…
FYI: I still wait for a reply from Celenia … (have contacted them again) … of course I’ll post their infos here …
Finally I got a reply from Celenia … … the funny thing first: even they don’t know for sure why they have implemented this RANDOM thing [:D] But: the only legal requirement is, that this UPR is unique, it is not necessary to have it created randomly. Thus, everyone could feel free to change it if required. My idea about changing this is this: Skip the RANDOM stuff, assign UPR via NoSeries or something (maybe just using the UPR setup and increasing via code by 1) To assure, this No is unique, I would create a UNIQUE index “UPR No.” on SQL Server, not checking via C/AL (SETRANGE/FIND) Any other suggestions?
quote:
… the funny thing first: even they don’t know for sure why they have implemented this RANDOM thing
Hehe - I guess some programmer had too much time on his/her hands at the time…[8D] Since the UPR-No is an integer, I’d definitely not go for the No. series solution - in fact I think I’d stick to my first suggestion (fiddle with the “UPR-No. (Min.)” & “UPR-No. (Max.)” values in order to decrease the number of iterations), thus not making any modifications whatsoever - but then again I’m a lazy guy [:D]
My guess is, that that is what happens when you outsource development to the ukraine 
Or maby pdj could enlighten us…