I’m getting some unexpected results while using automation to create and Entity and I’m curious if anyone else has experienced the same.
I have a script that parses information from US Issued drivers licenses which is working as it should pulling all the pertinent info from the license to use while creating a Member Entity for our new members. Everything works expect one part, the zip code and I can’t put my finger on why…
It reflects correctly on the Entity Screen before and after the entity is made. If I did a show message with the Local Setting it appears correclty, however when creating the entity it formats it as though it’s a date? I’ve checked the Custom Entity Field for formatting and there is none as I’ve not gotten that far along in setting this up. (None of the fields have formatting)
Can anyone think of why this is reflecting data that isn’t correct?
That full CustomData Entry is : Member ID={LOCAL SETTING:MP_ME_MemberID_Local};Status=New;VIP Level={LOCAL SETTING:MP_ME_VIPLevel};Address={LOCAL SETTING:MP_ME_SCAN_ID_ADDR};City={LOCAL SETTING:MP_ME_SCAN_ID_CITY};State={LOCAL SETTING:MP_ME_SCAN_ID_STAT};Zip Code={LOCAL SETTING:MP_ME_SCAN_ID_CODE};Phone={LOCAL SETTING:MP_ME_Phone};Email={LOCAL SETTING:MP_ME_Email};Govt ID={LOCAL SETTING:MP_ME_SCAN_ID_NUMB};Govt ID Exp={LOCAL SETTING:MP_ME_SCAN_ID_EXPY};Date of Birth={LOCAL SETTING:MP_ME_SCAN_ID_BRTH};Access ID={LOCAL SETTING:MP_ME_AccessID_Local};Image=URL;Comments={LOCAL SETTING:MP_Comments};Zip={LOCAL SETTING:MP_ME_SCAN_ID_CODE}
Its a bug that was reported few years ago that hasn’t been patched.
If it includes characters \ / | - _ , API processing of custom data will try to convert it into date.
I cant remember how I bypassed that off the top of my head when doing PMS integration, I will look into the code and entity type custom data settings and get back to you when I have a moment
That’s a fail safe. If I remove that it should correct the issue? I’m setting the program setting via Rules. At least that was my intention. Lol I’ll remove the API calls and see if I get the same result.
On the entity screen you are loading value of the ZIP setting.
When you are processing to update / insert an entity via GQL, you are using SambaPOS API to process this request and update the database.
Update entity custom data endpoint has a tendency to convert anything with the characters mentioned into date because of the bug.
So technically, on the entity screen you are showing the user value of the setting {LOCAL SETTING:ZIP} which is 72007-8736, but after its processed and stored by the API - because of the bug it becomes 9/20/1827.
I think this may work for our needs. I know this data is important to our owners as they use it to track demographics and advertising. Since you bring up parsing after the fact… is it the “-” that is the culprit here? If so I could just parse out the dash from the get go and hope ABC regulations do not require the last four. I’ll give it a try and see.
You can try and replace _ - / \ characters with space character before passing it to API to update.
Or you could simply add word ZIP before it. When running reports you can simply substring first 4 characters to trim out ZIP and space character - leaving only the actual value.
It doesn’t work, I’ve tried all the combinations too.
This didn’t work either. I ended up just parsing out the “-” and the last 4 pending confirmation we don’t need it due to state law here. If we do I will add Zip to the beginning and take Posflow’s advice. Thanks again, Sir! Thank you everyone for your input.