On Feb 20, 2010, at 10:17 PM, Simon wrote: > If a customer purchases your product multiple times, your ACG (code > generation script) gets called multiple times. Unfortunately Kagi > stuff all the results into one tiny field rather than breaking out > multiple rows. So the registrationName field now has "Joe Public > Joe Public Joe Public" and the registrationCode has "1234-ABCD > 5678-EFGH 9012-IJKL". You get the idea. Rather than analysing the > reports, I have to look at regular expressions. In fact, they also > manage to mangle up the TFYP emails in such multiple orders, with > customers quite confused.
The TFYP system is undergoing a major overhaul and we have actually two versions in QA. One is a major rewrite for the existing TFYP format (version 5.0), the other supports a different TFYP format (version 5.1) (and will be released after the interface for it is released). The new TFYP system with the existing TFYP format (version 5.0) supports a new way to merge the regcode data into the TFYP. Instead of "Joe Public Joe Public Joe Public" and "1234-ABCD 5678-EFGH 9012-IJKL" it can give you Joe Public 1234-ABCD Joe Public 678-EFGH Joe Public 9012-IJKL We have beta testers who are using the new 5.0 TFYP and right now it's not for everyone because there are supplier situations where it will not display a TFYP with reg codes. But it is in beta testing and might work for your situation. The way it works is that in the "postcard blurb" you enter your <username> and <regnumber> tags. Then in the blurb instead of those tags you put a tag that is the postcard blurb tag (it's not named that and we have to vet beta testers since it only works correctly under ideal conditions during this beta test). The postcard blurb gets swapped in for each user/regcode pair. contact [email protected] for details if you want them see if they can add you to the beta list Putting each reg code in the new payment data file is a reasonable change. Will see how quickly we can make that happen. > > Interested to know how many Kagi suppliers have experienced this and > have also raised this issue over the years. I have. Yet still > nothing gets fixed. Not to mention they still mangle the > registrationName, so if you're in Japan, your name could end up being > **** because foreign character sets aren't handled properly. Actually the major reason for the new payment data file is to support unicode characters. The file is UTF16 and the customer data is supplied as unicode characters. We have three systems that are not unicode compliant and if any of those systems deals with a transaction, it converts the characters to non-unicode characters. Revision to two of the systems are in QA and when they roll out, their character conversions to non-unicode will no longer occur. We have a third system that is queued up to be revised because it too is converting unicode to non-unicode. Getting unicode end to end is a priority for us. We think that when these are deployed, you should have unicode end to end. Kee Nethery Kagi, CEO
