Another late night thought.
Although not sure if we discussed this before.
At the minute we have the field which we enter product tags as a comma separated list which gives us additional fields on the product settings page.
This is powerful feature which has lead to allot of great setups but think the comma separated list for the fields is fairly basic.
My idea would be a page/table similar to entity custom fields were we can setup as a more clear list and ideally configure with validation/options like with entity fields;
Free text
Number value
Tickbox/selector (true/false or yes/no value)
Dropdown list values
Maybe a file directory option for easier product image etc settings
Am gutted this didnât drawer any comments (for or against) thought it was a nice enhancement possibility.
Although I just noticed there is a edit arrow which displays them in list format now - when did that sneak in there
But think it would be good to be able to setup validations/field types as with more complex setups using these product tags mistyping could lead to issues.
I for one have âPrint to kitchenâ tag which then gets applied as a state on order adding to ticket although it is configured as âisnot blankâ on the action, the courses states is probably a better example as courses are then defind in the grouping function on the template it would be good to be able to restrict them to the options set in the kitchen order template for example.
Also the tickbox type field would be a nice touch rather than typing Y, Yes or True.
I have a difficult time understanding some of the ideas you come up with. Best to do 1 or 2 graphical mock-ups to help explain what youâre going for, showing different ways the idea could be accomplished⊠this is what I do when I request something, unless it is dirt-simple.
Just like this. I donât know what youâre referring to. Is this in the Product card? For the default Tag? For custom Tags? Or in the Product Tag Editor? Or in the Custom Product Tag Captions?
This is what I was trying to get at.
That the Product Tag Captions had options similar to those for custom entity fields, that the field type could be defined to things like;
Free text
Number value
Tickbox/selector (true/false or yes/no value)
Dropdown list values (constrained)
Maybe a file directory option for easier product image/file directory etc settings
The picture is literally a screengrap of the custom entity fields options placed over I know but should help elaborate my idea. Obviously phone with mask type is not what would be wanted but demonstraits the idea
Quick moch up.
While just options of freetext or select values would do the toggle/tickbox would be just a nice touch as dropdown YES/NO or TRUE/FALSE would achive same thing.
Directory popup would be good for those using product images for customer displays etc.
Have been thinking about the integration via API and am going to have to work out a way to define department/category of products to match those used in the booking system.
As the idea of the ability to constrain product groups didnt show much promise my next thought was if this were to be on the table as a prospect that the âdepartmentsâ to match the booking system could be defined via product tags from a predefined list.
I think a predefined list would be the safest option as the linking of department (product group equivalent) setting on samba would need to be âmappedâ to the appropriate account account code on the booking system and you would want to be able to know that only options which have a mapped account code can be set so when it comes to âpostingâ sales over to the booking system API everything goes over correctly as only mapped department options can be used.
I know that one is more specific to my setup but as more interrogations begin to happen this type of mapping/linking of information will become very important.
@JTRTech sometimes the way you explain things makes my head explode and its really hard to follow your logic Can you provide some sort of visual reference?
I understand the original request. But I cant quite understand your point with how it helps improve your API integration.
Is it the part about the integration departments causing confusion?
Terminology conflicts for things like departments wont help, I try to adopt samba terminology but am so used to calling what samba refers to as product group as sales department from my long time use of the existing system at the hotel.
Will try and work something out to better explain.
Having an ability/option to constrain/define available options will reduce any potential for loophole/crash/issue from customer/manager entering values which will not fit within the configurations.
Courses for example would likely be defined on the printer template and this would prevent the typing/mistyping of values which are not setup in the config. (My course setting start with product tag which is transferred to order state on order adding to ticket).
Additionally beleive (although I think I already mentioned before but similarly an option to be able to define product groups - say you have created a report which delt with perticular groups and didnt want to mess up report OR save troubles with unwittingly creating new group for some new food items which isnt defined within the print job mapping for example.
So @JTRTech do you need custom fields for products? Tags and custom fields are somehow different implementations. Custom Fields are useful as you frequently create new customers. So we have a specific âCustomer Creationâ screen for operator and we can customize it for specific needs. Product creation is somehow different. We do it in batches. I mean not everyday but maybe we create 100 products in a day due to menu changes etc⊠So Iâve implemented YAML support for products. If you see YAML Iâve recently posted as a tutorial youâll see product tags are just key,value pairs. Implementing custom field support for products will make it unnecessarily more complex. For example you can see how Iâve added product tag support for print job mappings. From development side I already know all tags are plain strings so further handling is not needed.
Understand
It is obviously more of a re-seller concern where setup may have tag dependent constraints etc which is end user does not necerserally understand
Any suggestions?
I missed this bit on first reading, I was not meaning a change in the value or way it is stored but more of a way to constrain the input to preset values within the interface.
If using batch create it doesnt define tags anyway and if using yaml you could presume the use of will be done by someone with understanding of needed values.
However its not always admin who could bee needed to add products.
Again it is more a reseller thought I guess what user can only select say âKitchen Courseâ product tag of a course which is defined in the template and update course button.
But sure many places would allow manager/seniour staff to add a new product but those people did not need to know the complete âhow to use sambaâ just how to add products.
While my print to kitchen/bar setup works well with any value as have done order added rule to with {PRODUCT TAG} != ââ then set state of Kitchen Order to Kitchen Order and added a ticket close state update of Kitchen Order to Kitchen Ordered.
While this works fine for single value tags (which would look more professional as a tickbox hence that idea but tickbox would just make the value Y or Ticket or whatever when selectedâŠ)
It is less efficient for multi option tags like course, which need to match the order group specified in the template.
In regards to the PMS api script to transfer sales to a room and the general sales at end of day the âdepartmentsâ/âreceivables accountsâ for the product groups on the PMS will need to be known within samba and samba will need to know which ones relate to which product.
While this could be done with product group and set in script which group relates to which department that would mean script change for new product groups and as product groups wouldnt directly relate to the PMS department (weather it was WET/DRY or by more detailed breakdown)
Which leads me to think the best way would be to define how products are translated to PMS department is with a product tag of PMS Department.
However this department would need to be defined within the script and the script know which tag relates to which department.
So if the product tag could be defined/constrained to a list of options you can rest assured that only options setup in the script can be selected.
Can you provide some sort of visual reference?
