Unexpected formatting on Entity Custom Data

Hello again -

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}


Any insight is most appreciated! Thanks as always!

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

2 Likes

I’m creating the Entity via the Application, though - Not with the API/GQL. Or am I misunderstanding?

Either way. I appreciate the help!

I can see in the code you are using GQL execute for mutations and queries.
You are using SambaPOS API

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.

Thanks again!

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.

Confirmed. Same result having removed any references to GraphQL.



1 Like

I haven’t had a time to check it today, but Ill check tomorrow and get back to you on how to bypass this issue

Can you try setting the ECD field type to number and setting a mask in editing format as #####

Same result only shorter. :slight_smile:


I told you wrong mask. Try #####-####

@cpeckat

Similar problem to yours was that I would get room names from the PMS like 046-047 (DFG)which when stored would convert to date like they do for you.

Changing masks types didn’t yield any results so adding a string followed by space character solved it for me.

So my code would output a value Room 046-047 (DFG), in your case it can be ZIP 72007-8736
image

That should prevent it from converting it to date, in your reports when querying ZIP you can use substr() to cut out first 4 characters.

What if followed the Create Entity action with an Update Entity Data to update the zip code field. Does that have any effect?

Unfortunately I get the same result.

Same result.

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. :slight_smile: I’ll give it a try and see.

Thank you everyone for your help!

1 Like

What if you store the full zip code as all numbers, then format it whenever you need to pull the zip code out.

One more thing to try. Have you tried setting the Mask Type to Numeric instead of Simple.

Try setting Field Type to Number and Mask Type to Numeric then use mask #####-####

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.

1 Like

Select Editing Format as Regex and try applying the format as follows.

[0-9]{5}-[0-9]{4}

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.

@cpeckat

I can see this is working just fine. Are you sure you haven’t made a mistake somewhere?