Reopen Closed Ticket - Not Enabled (mapping looks fine)

If that coding is REALLY needed to support some other edge case then the “documentation about mappings” needs to mention these edge cases.

There is great documentation but it will never be able to cover everything. Your never going to get a comprehensive manual. We are getting some very good resources though and it will grow.

You simply can not document every use case. It goes against Sambapos nature. We discover new ways to use features all the time.

Btw it is documented in the forum. I believe I read a post where Sukasem explained it well.

We overlapped our posts timings there.
About the logical use of a blank mapping you just mentioned would be very EASY to document under the “How to use mappings” section.

I understand resources need to be rationed and that’s because of economic constraints. And those economics depend on market penetration, and that depends on user experience and ease of config, and that depends on documentation, and that depends on having enough resources.

Justifying the existing limiting circular condition and rejecting improvement suggestions by the idea “You’re never going to get a comprehensive manual” is not helping break out of it.

Having used and written technical documentation over decades, it is abundantly clear to me there are practical approaches and straight forward ways to document the automation system of SambaPOS. (This is moving into a subject for a different topic)

As I said we have a great knowledge base that is growing constantly. You won’t find a comprehensive manual though. New features are discovered constantly that were not specifically designed.

You have me all wrong. I never rejected anything. But this was not a bug. Yes we should probably document this I agree.

We are not trying to break out of a cycle. We are growing and expanding rapidly. Great things are happening.

Good! and I can see new sales expansion opportunities opening up. I also observe and can readily predict that those new opportunities will be deeply hampered if the “proper technical documentation job” is treated as low priority and you continue to believe the forum is an adequate source.

By “proper technical documentation” I don’t mean end user step-by-step instructions stuff. I mean documentation written for a moderately technical audience … things like lists of actions, rule conditions, action constraints, valid syntax, valid context of TAGS, all properly structured with details and interlinks.

Just look at documentation of almost any massively adopted development platform or API for ideas on how it could and should be done. To get anywhere near to that level of mass market acceptance you need to strive for that level of excellence.

There are various limiting factors including the need for clear and elaborate technical documentation which is glaringly obvious to any experienced s/w developer. But there is some kind of embedded erroneous ideas that “it can’t be done”, or “just search the forum” which is holding you back from reaching the potential of much larger scale use. Other technical aspects also need resolution but this is a core weakness.

I’ve never seen a technical manual on POS systems. I have seen one for old cash registers.

We are a POS system not a development platform.

Anyway it’s obvious you want something specific for your planned use case. I will stop here. I think your wanting to use Sambapos as a development platform. That’s great and may be possible. We are a restaurant POS and we will focus on our core market. I don’t think having a super technical manual serves our core. We need how to guides and simple tutorials and trainings which is what we are focusing on and will continue to do.

I’m sure you will agree that SambaPOS is unlike any other. It is because of Emre’s genius idea to provide such a level of abstraction that it is similar to a generic development framework.

Do you want to justify not having professional quality documentation?
or can we move beyond these limiting beliefs?

@Jesse I’m very happy regardless of this thread. I appreciate the quality of the forum and the active userbase. Keep up the good work.

1 Like

btw what i am suggesting has nothing to do with using SP for anything other than restaurant and retail POS. That market is worth billions of $ and there are new opportunities created because of a rapidly changing tech in many related fields such as payment types, supply chain integrations, etc.

it’s obvious you want something specific for your planned use case

Nothing related at all

EDIT: in fact what i am suggesting isn’t much related to my personal needs because I already spent 3 years learning how the whole system works, including deeper analysis using custom made automation tracing tools, automation management tools, widget management, etc. (which btw have revealed some deeper technical issues related to real time concurrency, atomic transactional logic issues, which can explain some of the weirdness other devs have experienced. this is obviously a topic for another thread).

My point is that I am not trying to satisfy personally needs here, but trying to help others avoid such an arduous learning curve and help SP reach a larger user base.

We have good professional documentation. It’s not perfect we work constantly to improve it.

It’s a major problem if you believe you already have it and therefore there is no need to make it!!!

I’m having a hard time with this discussion. I never said that and this is twice your trying to paint a picture about us. Why? What are you wanting?

I am wanting to help you know how make SP into a more ubiquitous POS product. (and we can all benefit from that)

That’s great. Thank you.

Am I missing something but this is converted on forum.
Is an old v4 tutorial but still applies.

Sorry dont mean to respark anything…