I’ll be blogging every few weeks in the future about any more trinkets of PowerApps information I come across. That’s it – I’d appreciate any comments about the method I used, or the actual code developed. I’m sure the code could be optimised to have less lines but I wanted to keep it readable (for when I come back to it in 6 months times to see how it works □). Below is the full code:ĬlearCollect(colStringChars, Split(txtInputValue.Text, "")) The code took a fair bit of time to develop as PowerApps is not really designed to work with loops and arrays, hence the need for several collections. The last digit, the 16th, is the check digit. The next nine digits identify the individual account associated with the card. For a sum of ’14’, the check digit is ‘6’ since ’20’ is the next number divisible by ten.īelow is a recording of the App being run using the test value of 139 Check Digit On credit cards, the checksum takes the form of a 'check digit.' In a typical 16-digit credit card number, the first six digits identify the institution that issued the card. So the answer is ‘1 + 8 + 3 + 2 = 14′ and the check digit is the amount needed to reach a number divisible by ten. Now sum all of the digits (note ’18’ is two digits, ‘1’ and ‘8’). Work right-to-left, using “139” and doubling every other digit.Ģ. All resulting digits are summed and the check digit is the amount necessary to take this sum up to a number divisible by ten.ġ. Every other digit is doubled and the other digits are taken unchanged. Summary: Given an identifier, let’s say “139”, you travel right to left. These are the steps for the calculation (taken from this website). I used a variant of the algorithm using modulus 10. The Luhn Algorithm seemed to fit the requirements – it wasn’t overly complex and is used on credit card numbers so must be accurate. There were no replies so I went about writing the code myself.įirstly, there was the matter of choosing an algorithm that would generate the check digit. I initially posted onto a PowerApps forum to see if someone had designed code for this method previously. To ensure that they are working with the correct parent record and also to bypass user typing errors, I thought it would be a good idea to add a check digit to this number. The ID field is just an incremental counter on the backend and the user would enter this onto their device. In the scenario where the users device is offline, the user will call the office and be told the ID of the parent record they are working with. The App also has a requirement to be able to function when the device is offline (i.e. I can’t go into specifics about what the App is used for, suffice to say that there are parent records created on the server and the App is used to create multiple child records linked to the parent record. I’m quite new to the world of designing and developing Power Apps and came across an interesting puzzle during the creation of my first App.
0 Comments
Leave a Reply. |