Add documentation for Silo Entry States

[yalaska04]

This PR adds a new section explaining the purpose and usage of the state field in Silo entries.

[samlown]

This is a difficult one as there are quite a few subtle details to consider.

[samlown]

I don't think this is accurate. There is no JSON Schema for silo entries.

[yalaska04]

Thanks for the clarification. I might’ve misunderstood the structure. My assumption was based on the idea that since silo entries are returned as structured JSON objects with consistent fields like id, state, created_at, etc. they were implicitly defined by some kind of internal schema, even if not exposed as a formal JSON Schema like GOBL documents are.

That said, I see your point. There isn’t an official JSON Schema for silo entries like there is for GOBL documents. Would it be more accurate to say that silo entries follow a consistent JSON structure with various fields, rather than referring to a schema?

My goal is to implicitly convey the meaning behind the term “silo entry state”: “silo entry” because it refers to an entry stored in the silo, and “state” because it relates to the state field.

[samlown]

They actually can be configured for each workspace, we just haven't enabled that functionality yet...

[pmenendz]

Great first version! This is a really complex and abstract topic, and I think you've done a solid job starting to break it down.

A couple of suggestions from my side that might help simplify the guide and make it easier for users to grasp:

• I’d avoid diving into how the state is technically a field of the silo entry — most users won’t know or care about that detail. What matters is understanding what the state is (whatever the user wants it to be) and how to set it (via workflows).

• I would write something like this:

Silo entries are documents stored in Invopop — like invoices, parties, etc.
When created, they start with an empty state.
The state is just a flag that helps users organize and identify entries easily.

For example, most of our templates set the state of an invoice to "error" when an error occurs. This makes it easier to spot problematic invoices without digging into the faults object.
But states can mean whatever the user wants — someone might decide to use "registered" to mean the same thing. While weird, it is totally valid!

Silo Entry States:
(…list here…)

How do I set a Silo Entry state?
This is done in workflows, using the Set State step. Every time a silo entry goes through that step, its state would change to the one defined in the step.
For instance, you want your suppliers to show as registered in Invopop after they have successfully registered in Verifactu. In this case, after the step Registered with Verifactu, you want to add a Set State step with the value "registered"(as we do in our templates - ref to template of Verifactu).
If you skip this step, the state will remain empty — which doesn't mean the entry wasn’t registered, just that no state was set.

States don’t reflect any official status in the real world of invoices. They’re just a flexible tool in Invopop to help you track and debug things more easily.

We strongly recommend using states — but remember, they’re fugazzi ✨ and only mean what you decide they mean.

Feel free to polish it up — you’ve definitely got a better touch with wording than I do 😅.

• Finally, I think adding some screenshots from the console would really help make this clearer for users.

Hope this helps! Let me know if I can support further.