Delete invoice, table of accounts etc

When doing my first steps, I’m subject to make many mistakes…
By accident, I created two identical tables of account (“minimaler Kostenplan”), and used both of them randomly.

Now I need to get rid of the surplus one, but it’s already in use by an invoice. Is there any chance to get delete that invoice ? - Or a trick to “force delete” a table of accounts with all its children?

Is there an “experimental” mode for noobs, where the normal data storage rules in accounting are disabled, so noobs can experiment without fatal consequences?

Cheers,
Wolf

No because posted invoice can never be deleted.

No because it would be too risky to allow bad practice in production.

You just have to delete your database and restart your experimentation.

Thanks for clarification.

I don’t think that’s really realistic. I cannot belive anybody can dive into tryton without making severe mistakes in the very beginning and early stages. A complete startover each time will soon leave noobs frustrated and disappointed. Think only how many tries a noob needs until his invoice template really fits… (for myself I expect several months of parallel usage of tryton and the old system till I really know how to handle tryton.)

I think tryton should have the chance to begin with an “experimental version” where mistakes can be corrected. That could have a red-coloured background and a huge warning “not for productive use - test only” or so. Finest would be if I could at a certain point copy the testing database to productive and keep the testing one for further experiments.

Please let me know your thoughts.

Cheers,
Wolf

It is not up to the software to organize your work. Do your homework and don’t blame software.
You may get inspired by the Tryton hosting I provide, it runs (at least) 3 independent tryton services.
One for production, one for testing and one for training.
An additional panel allows to save/restore/clone/move databases between these three services.
A “tachy-backup” mode with a database backup every hour or every quarter is available to help you restore the state before.
test and training services must be maintained over time, because test allows to validate new modules and upgrades before they hit the production service and training is always needed to rehearse unusual
operations and to train a new employee.
Hope this helps.

1 Like

You can backup the database at any time you like, then restore it to go back to that point in time.

This means that you can create a database backup before you start doing an experiment, then if you find that the experiment didn’t work out as expected you can just restore the database and you will be back to the point just before you started your experiment.

Another alternative would be to have a testing system and a production one, you could copy the production database to the testing one, run the tests to see what will happen, then if you are happy perform the same actions on your production system.

Yes, this is needed in particular if your test is about modifying/complementing Tryton code.

1 Like

Thank you very much - this is helpful.
(barking “do your homework” is not…)

Could you please be a little more detailed?

When I bark, I don’t spend time to answer.
details are:
save: pg_dump -O db_name > db.sql
restore: psql -d “db_name” -f db.sql --username db_user

take care if you use several copies of a database, only the production one should perform actions to the outside, like sending mails.

Thank you.
As you may have noticed: I’m not at all a pro, just an entrepreneur looking for a tool to do the not-at-all-fun-part of the work. I never worked with docker, and I dont have the time to dig into the details. So could you please let me know how I can access the database and where it lives?

Are you using docker now? If so the database will be stored inside your postgres container. You can find the ID for the container by running:

sudo docker ps

Once you know the ID you can run the commands suggested by @SISalp in the container by doing something like this: (remember to change the [container_id] for the one you previously found)

sudo docker exec [container_id] pg_dump -U tryton -O tryton >backup.sql

and

sudo docker exec [container_id] psql  -U tryton -d tryton <backup.sql

More information on postgres backup and restore can be found in their documentation.

If you are not using docker then you should be able to use the commands above without the “sudo docker exec [container_id]” part, although the user name and database name may be different.

Thank you very much.

This is what I tried:

$ sudo docker exec ed01cfc74801 pg_dump -U tryton -O tryton >Sikop28.04.20.sql
pg_dump: error: connection to database “tryton” failed: FATAL: role “tryton” does not exist

I tried with running or not-running tryton and tryton-postgres - does not matter…

Sorry, my mistake, if you followed the docker install instructions then it should be -U postgres and not -U tryton.

Another thing, you also might want to specify -c or --clean as one of the options when running pg_dump as well.

I seem to make a mistake. That’s what I tried:

From a running tryton, I logged out.

$ sudo docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
18ccc2fcd7db tryton/tryton “/entrypoint.sh uwsg…” 4 hours ago Up 41 seconds 0.0.0.0:8000->8000/tcp tryton
ed01cfc74801 postgres “docker-entrypoint.s…” 4 hours ago Up 7 minutes 5432/tcp tryton-postgres
$ sudo docker stop tryton
$ sudo docker exec ed01cfc74801 pg_dump -U postgres -O postgres >Sikop28.04.20.sql
$ sudo docker start tryton

log into tryton, changed a bit: created a bogus article
logged out tryton

$ sudo docker stop tryton
$ sudo docker exec ed01cfc74801 psql -U postgres -d tryton <Sikop28.04.20.sql
$ sudo docker start tryton

logged into tryton, expected my bogus article inexistant - but it was not.

What’s my mistake?

This line:

sudo docker exec ed01cfc74801 pg_dump -U postgres -O postgres >Sikop28.04.20.sql

Needs the -c flag mentioned above (plus the -C flag to be safe), and the correct database name, so should be this (I think):

sudo docker exec ed01cfc74801 pg_dump -C -c -U postgres -O tryton >Sikop28.04.20.sql

And this line:

sudo docker exec ed01cfc74801 psql -U postgres -d tryton <Sikop28.04.20.sql

Needs an additional -i flag that I missed (sorry!):

sudo docker exec -i ed01cfc74801 psql -U postgres -d tryton <Sikop28.04.20.sql

No reason to be sorry - good to see that experts make mistakes as well…

When playing back a backup, I get a heep of error messages:
https://www.dropbox.com/s/z2dsjuabjc80qso/restore.txt?dl=0

The database seems to be the same as before.
My fault?

These are not error messages, they are just a list of all the things that are getting restored to the database.

If you have a look in the backup file, there should be a line near the top that says something like DROP DATABASE tryton;. If the backup file contains this (which it should do if you ran the pg_dump command with the -C flag) then you can be pretty sure that any changes that you made to the database will have been removed.

So, make sure the tryton server is restarted (which it will be if you do the commands you listed before), and the client as it may be caching some of the data. To restart the web client use the reload button in the toolbar of your browser.

Good morning.
Sorry, still in trouble… ):

Today, I did an entry to “parties” and tried to save the database:

$ sudo docker stop tryton
$ sudo docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
ed01cfc74801 postgres “docker-entrypoint.s…” 19 hours ago Up 25 minutes 5432/tcp tryton-postgres
$ sudo docker exec ed01cfc74801 pg_dump -U postgres -O postgres >29.4.20.sql

And I got a tiny database dump, hardly containing anything:
https://www.dropbox.com/s/701tgmvdir3j9v0/29.4.20.sql?dl=0

Seems to be a bit away from the final goal…

Seems you miss to add dbname “tryton” ?
… pg_dump -d tryton …

I tried again with this line:

and it worked, I could find my input changes in the dump. Probabely my copy/paste error.