Customizing Tryton?

I am trying to make Tryton “work for me”, but am unsure about which parts are just usage problems, or for which parts, I should look at developing code, and what kind of code.

Q1: I would like to have customer-specific numbers. So far, I understand that a “Party” is a customer if I create a sales invoice to them. I found an old thread about adding customer specific fields, like their EU VAT-Id etc., and I would need a text field for the customer, too. Is modifying the ‘Party’ model still the way to go, or could it work in a different way?

Q2: I would assume that I need an additional table in the database to hold the relevant information, eg.

class PartyAdditionalInfo:
party_id = Integer, # referencing the table which has the addresses
field_name = String, # eg. 'EU VAT Id"
field_value = String # eg. “DE1234567890”

or, in my most urgent case,

field_name = ‘Invoice Prefix’
field_value = ‘ABC’ # varies per customer


field_name = ‘Last Invoice Number’
field_value = ‘123’ # or whatever the customer had

so that the next invoice will have an invoice number of, say, ‘ABC000124’.

Q3: Date Invoices on NBD

Irrespective of when I create an invoice, I would like to have it being issued on the next business day. I would also like the payment terms to be calculated on the invoice date. Lastly, I would like those invoices be emailed on the date specified on the invoice. I have no idea where to start solving this problem, but it would be bad to eg. write invoices on a Saturday and have them come due on a Saturday, too, as my customers tend to be businesses which only work five days a week, and it would make their payment period one day shorter, which is undesirable, too. Or I’d need to have weird payment terms to compensate for that, which is also undesirable.

Q4: Perform Elster declarations

In Germany, we need to declare VAT electronically, and I would like to have this process automated. I have seen that there is already a SEPA module for interfacing with banks, but there does not seem to be anything for Elster - right? Wrong? If there is no such module, I expect to need to write one. But I have no idea about this topic, yet, and for some odd reason, the Elster guys require registration as a developer before letting me see the specs. :frowning:

I found two tutorials, Home · coopengo/tryton-training Wiki · GitHub and training: log . Are these still recommended, or what should I be looking at, short of sifting through the entire source code? Thank you!

It’s hard to say without knowing more about the number usage.
But if it is just for searching and identifing a party I will add them as Identifiers of the party as this fields are using when searching parties.

It is strange to have specific sequence for customer. Probably what you are requesting is what we already discussed on this post.

I think you will need to code here. The best is to have a cron job that post customer invoices with a date today. You can use notification_email module to automatically email the invoices when post.

If this is something generic to the whole country I think the best is to extend the german localization modules to include the process to generate the required file format or to talk with the webservice. We’ve done that in the Spanish localization and it works very well as all the features all available for all german customers.

There is a Work in Progress to include a developer tutorial in the oficial documentation, you may be interested in having a look at it as its quite advanced.
Lets see if we can make it ready for the upcoming release.

It’s not the same thing, but similar, as far as I understand. The post in the link seems to discuss how to make invoices with different numbers for the case that a ‘party’ (ie, customer) is a customer to more than one company. This might also be interesting, of course.

But the usage of what I want, is just to have one invoice for customer “Abraxas Brimborium Caesarium, Ltd” to have an invoice number of “ABC000123”, and the next invoice to them should then have the invoice number “ABC000124”, and so forth. For a different customer, the prefix should be something else, and they should have their independent numbers, so in one batch of invoicing, I would eg generate invoices numbered ABC000123, ABA000025, ZYX000101 etc. I am not using those identifiers to search for a customer at all.

Ok. Then this will have to wait, because I need to gain confidence that I am actually creating correct invoices first.

On the one hand, this is generic for the entire country. On the other hand, there are many, many options and variants, as far as I understand it so far. But I’ll see what I can do. I presume you think I should create an ‘account_de’ module, then? Or is there an existing module you think I should try to add to?

Thank you, I’ll look into that!

So far, I am trying to collect the Sphinx extensions to get it to build.

Also, sorry for the confusion, I clicked the wrong post to delete, and then found no way to undo the damage.

A post was split to a new topic: Building doc yield warnings

The case discussed there is about having diferent invoices sequences (so difernt prefixes) per company branch. But from what I understand you have the same requirement but having different prefixes for each party.

There is already a german localization module. If its for all german companies it should be included there.
If it is an option, you may have a separate module to be activated just for the german companies that require it. But for sure we should collect the requirements in a new topic before doing any development.

Ok. I understood this module to be for the German SKR03 chart of accounts only. We also have SRK04 and SKR07, and you can roll your own, too. SRK03 is probably the most popular of these, but you are free to choose whatever suits you, within legal boundaries. Elster, on the other hand, is not optional at all, and there is no flexibility, as far as I know. But it has maybe 20 or so subcomponents, of which I need one, two or three (I am not quite sure, yet).

We are missing such charts for now but it can be easly implemented in a single module by using xslt transformations. So if this is implemented we can rename the module to account_de

We have this already implemented in the Spanish localization where a single module holds two charts with share accounts and taxes.

I assume you are not talking about „Elster“, which is just the IT interface, but about the VAT declaration „Umsatzsteuervoranmeldung“, UStVa). The module account_de_skr03 includes the respective report, based on the accounts used in SKR03. Please see „→ Konten und Tabellen →Steuerkennzifferntabelle öffnen“. XML output/reports is provided by some German Tryton service provider.

I suggest to get in touch with one of the service German providers. AFAIK they have tooling to create Tryton modules for other SKRs and custom KRs easily.

To be frank: Try to get rid of this requirement. It’s hard to implement without much actual benefit. Looks more like a left-over from a non-IT-based process. (I also doubt this complies to German regulations, demanding „Nummernkreise”: If a new customer occurs, this will get a new prefix and the invoices could easily be thrown avail.)

If you are a small company an don’t want to leak your (small) number of invoices, base the numbers e.g. on the month. Invoice no. Like 2204-005 don’t give much information bejond this specific month.

My operation has been checked by the authorities, albeit for other reasons (probably to train their new joiners), and nobody ever complained about these invoice numbers. But I am considering trying to think of a different numbering scheme precisely because it is probably much work to implement the old scheme.

I am actually talking about Elster, and am currently wading through their documentation. This “just an IT interface” is a huge package, covering lots and lots of things I don’t need, and UStVa is just a small part of that. I was hoping to get that integrated into Tryton, so I don’t need to produce a report manually, then type it into the web interface, which is quite cumbersome. On the other hand, this is a daunting task.

I have to admit that I was over-simplifying.

This is why I pointed you the the German Tryton service providers. They might have a nicer solution like some XML export which can be uploaded via ElsterOnline.

You may alos want to read Taxbird – Wikipedia andür_Softwarehersteller.

It will be great to include such reports as part of the main Tryton module so anyone using Tryton will be able to generate the export to be uploaded directly.


This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.