Re: [tryton] Upgrade documentation

2018-11-14 Thread 'Korbinian Preisler' via tryton 
Hi Axel,

there is a section on discuss:
https://discuss.tryton.org/c/migration

On 14.11.18 11:53, Axel Braun wrote:
> Hi,
>
> does anyone know where the upgrade documentation (e.g. 4.6 -> 4.8 ) of Tryton 
> went to? I cant find it on the website nor in the source package (of 4.8)
>
> Thanks
> Axel
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"tryton" group.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tryton/6c821cb4-06f3-836d-8676-13dad21e553a%40googlemail.com.

Re: [tryton] report name

2018-08-03 Thread 'Korbinian Preisler' via tryton 
Hi,

On 03.08.2018 09:53, JC Michel wrote:
> Hi,
>
>
> Is it possible to have reports named with the number ?
> For instance, Sale_2 instead of Sale or 2018-08-03_Invoice_1234.pdf
> instead of Invoice.
> Maybe would it be possible with the  meta:name=""/> of fodt format ?

the report_name is part of the return value of Report.execute()[1].
It is possible to modify the report name at this place.

For the future i would like to have some refactoring at this point with
a method _get_report_name() that would allow to add custom solutions for
computing the report name at this point.

Best,

Korbinian

[1] http://hg.tryton.org/trytond/file/tip/trytond/report/report.py#l185

-- 
You received this message because you are subscribed to the Google Groups 
"tryton" group.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tryton/f497cd79-f8a8-5d23-370a-077d1a1791fa%40googlemail.com.

Re: [tryton-dev] Test client build under GTK+-3

2017-11-22 Thread 'Korbinian Preisler' via tryton-dev 
On 22.11.2017 12:27, Gonzalo González Domínguez wrote:
> El martes, 21 de noviembre de 2017, 20:45:06 (UTC+1), Cédric Krier  escribió:
>> On 2017-11-12 23:58, Cédric Krier wrote:
>>> I need again some help to test the build of client with GTK+-3.
>>> The scripts needed some changes to manage correctly the introspection.
>>> You will find information and links at https://bugs.tryton.org/issue6932
>> I still did not have feedback on testing the clients:
>>
>> http://www.b2ck.com/~ced/tryton-4.7.dev0.dmg
>> http://www.b2ck.com/~ced/tryton-setup-4.7.dev0.exe
>>
>> -- 
>> Cédric Krier - B2CK SPRL
>> Email/Jabber: cedric.kr...@b2ck.com
>> Tel: +32 472 54 46 59
>> Website: http://www.b2ck.com/
> In Windows 10 (Spanish) it works, but the icons in the search limit menu are 
> lost. The buttons work, it's just aesthetic.
>
> Screenshot: https://snag.gy/wCmQk6.jpg
>
I tested it on Windows 7. Same problem. But the client seem to work.

-- 
You received this message because you are subscribed to the Google Groups 
"tryton-dev" group.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tryton-dev/fad04e03-8aae-695d-d487-92fa6179d885%40googlemail.com.

Re: [tryton] VAT listing

2017-08-19 Thread 'Korbinian Preisler' via tryton 
On 04.08.2017 10:37, Cédric Krier wrote:
> Hi,
>
> In Belgium, we have to generate two listing related to the VAT.
> The first one is a list of all parties with locale VAT number which were
> invoiced during the previous year (civil year). It must include the sum
> without taxes of the invoiced amount and the sum of the taxes.
> The second is a list of the all parties with EU VAT number (but not
> locale) with the sum of invoiced amount (without taxes but the rate is
> 0%) and a tax code (L, T or S) depending of the operation (service,
> goods, triangular goods).
>
> See in french:
>
> 
> https://finances.belgium.be/sites/default/files/downloads/165-725-formulaire-2016.pdf
> 
> https://finances.belgium.be/fr/entreprises/tva/declaration/liste_annuelle_clients_assujettis
> 
> https://finances.belgium.be/sites/default/files/downloads/165-723-formulaire-2016.pdf
> 
> https://finances.belgium.be/sites/default/files/downloads/165-723-directives-2016.pdf
>
> I would like to know if this is general for all EU countries, if the
> reports are similar. If so, I will make a proposal for a account_eu
> module.
>
In Germany only the listing with all parties with EU VAT number is
necessary.

See in german:

   
http://www.bzst.de/DE/Steuern_International/USt_Kontrollverfahren_ZM_eCommerce/Zusammenfassende_Meldungen/Zusammenfassende_Meldungen_node.html

http://www.gesetze-im-internet.de/ustg_1980/__18a.html


-- 
You received this message because you are subscribed to the Google Groups 
"tryton" group.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tryton/903020eb-c669-2b18-e982-350d299b8573%40googlemail.com.

Re: [tryton] Audit compliance?

2016-10-04 Thread 'Korbinian Preisler' via tryton 
On 04.10.2016 16:00, Pa Wa wrote:

[1] https://www.psp.eu/media/allgemein/GoBD-Leitfaden_Version_2_0_FINAL.pdf
>
This is a nice document. Thx for the link.
But be careful. This is not a legal document but a personal
interpretation of the GoBD by the authors which are tax advisors. So the
interpretation may or may not match the interpretation of the jurisdiction.

-- 
You received this message because you are subscribed to the Google Groups 
"tryton" group.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tryton/75f708ce-8ce9-27df-74df-89d2135ee7d6%40googlemail.com.

Re: [tryton] Audit compliance?

2016-10-04 Thread 'Korbinian Preisler' via tryton 
Hi,

On 04.10.2016 13:51, Pa Wa wrote:
> Hello Tryton Developers,
> Hello Tryton Users!
>
>
> From the legislator standpoint of view, wherever it may be,
> bookkeeping has to be 'audit safe'. Regulations may vary from country
> to country, but the character may be the same.
>
> That is to prevent fraud by manipulating the bookkeeping itself, I guess.
>
> The main question here: Does Tryton have measures implemented that
> track any changes made to any data Tryton stores or keeps track of?
You can track any change of a record by activating the history table on
the model [1]
On relations you can define a datetime_field[2]. It will be used to
retrieve the content of the related model by the date given by the
datetime_field.

>
>
> Background: in Germany since 2015 (GoBD) any digital handling of
> business process related data has to be, in essence, unchangeable, or
> safe from being manipulated. Therefore requirements to an ERP from the
> legislator/regulator standpoint of view are now stricter.
>
> These requirements are:
>   * book entries or records must not be changed in such a way that
> their original content cannot be retrieved or determined any more,
>   * later changes are to be made in such a way, that the original
> content as well as the fact that changes were made, are recognizable,
>   * when master data is changed, the distinct meaning in the according
> transaction data has to be recognizable afterwards.
I think that these 2 features should meet the legal requirements but
maybe except for the requirement that is defined by 'unchangeable'. All
the data is stored in a database and i do not see any proper technical
way how to make the content of it 'unchangeable'. For me the GoBD are
are quite vague about this term.


[1]
http://doc.tryton.org/4.0/trytond/doc/ref/models/models.html?highlight=history#trytond.model.ModelSQL._history
[2]
http://doc.tryton.org/4.0/trytond/doc/ref/models/fields.html?highlight=datetime_field#many2one


-- 
You received this message because you are subscribed to the Google Groups 
"tryton" group.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tryton/a0360ef2-0e4e-8fd8-21e7-fbfeb4318b79%40googlemail.com.

Re: [tryton-dev] Re: WSGI application server for Tryton

2016-09-20 Thread 'Korbinian Preisler' via tryton-dev 
Hi Ali,

On 20.09.2016 09:32, Ali Kefia wrote:
>
>
> Le mardi 20 septembre 2016 09:19:12 UTC+2, Sergi Almacellas Abellana a
> écrit :
>
> El 19/09/16 a les 18:07, Ali Kefia ha escrit:
> > => We will give werkzeug a try (if you have a document that
> helps on
> > configuration, please share)
> Using uwsgi you can run trytond with the following command:
>
> uwsgi --http :9090 --module trytond.application:app --processes 4
>
>
> I wanna make some tests
> uwsgi is making load balancing (same job as nginx)? is it made this way?

You should use uwsgi together with nginx as frontend [1]. We have made
very good experiences with this combination.

[1] http://uwsgi-docs.readthedocs.io/en/latest/Nginx.html

But i must say that i only managed to get tryton 4.0 run on uwgi with
some custom code. I will test Sergis command. Maybe i missed something.
>  
>
>
> It's a start, for full reference see the uwsgi documentation.
>
> Hope it helps.
>
> -- 
> Sergi Almacellas Abellana
> www.koolpi.com 
> Twitter: @pokoli_srk
>
> -- 
> You received this message because you are subscribed to the Google
> Groups "tryton-dev" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/tryton-dev/c1dfe583-90d8-4064-822a-e60d57c240d6%40googlegroups.com
> .


-- 
You received this message because you are subscribed to the Google Groups 
"tryton-dev" group.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tryton-dev/772e1a01-e4cc-b3f7-cd66-f8df57388e2b%40googlemail.com.

Re: [tryton-dev] cdecimal in Tryton 4

2016-06-10 Thread 'Korbinian Preisler' via tryton-dev 
Hi,

cdecimal has been integrated into Python 3.3 as you can see here:
https://pypi.python.org/pypi/cdecimal/2.3

So cdecimal should be only a dependency for python 2.7 packages.

On 10.06.2016 10:35, Axel Braun wrote:
> Hi,
> during build of Tryton 4 I came along cdecimal as requirement.
> cdecimal will stay in version 2.3, only libmpdec library will be
> developed further (currently in version 2.4.2)
>
> libmpdec is the basis for the decimal module in Python-3.3.
>
> Why do we have the separate requirement for cdecimal then?
> Thanks
> Axel
> -- 
> You received this message because you are subscribed to the Google
> Groups "tryton-dev" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/tryton-dev/9613d1cc-fa5e-4ad6-99ab-ec25b97a5380%40googlegroups.com
> .

-- 
You received this message because you are subscribed to the Google Groups 
"tryton-dev" group.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tryton-dev/575A8F85.5080609%40googlemail.com.

Re: [tryton] Re: RFC: Invoice sequences

2016-05-03 Thread 'Korbinian Preisler' via tryton 
On 03.05.2016 16:00, Cédric Krier wrote:
> Usually the rules of invoice numbering in countries is like this:
>
> 2015-12-20: INV-0018
> 2015-12-21: INV-0019
> 2015-12-22: INV-0020
>
> 2016-01-02: INV-0001
> 2016-01-03: INV-0002
>
> even if INV-0002 was created before INV-0020
> This means that if you look at the generated invoice over one fiscal
> year ordered by invoice date, you must see only increasing and
> continuous numbering.
>
> issue5205 is about not resetting the sequence so we will have:
>
> 2015-12-20: INV-0018
> 2015-12-21: INV-0019
> 2015-12-22: INV-0020
>
> 2016-01-02: INV-0021
> 2016-01-03: INV-0022
>
> But we can not allow to do this:
>
> 2015-12-20: INV-0018
> 2015-12-21: INV-0019
> 2015-12-22: INV-0022
>
> 2016-01-02: INV-0020
> 2016-01-03: INV-0021
>
> Because if there is a fiscal control for the year 2015, the controller
> can not know if the hole between INV-0019 and INV-0022 is because there
> are invoices on another fiscal year or if it is a tax fraud by hiding
> invoices.
>
> Note that I'm talking about the accounting date which is most of the
> time the same as the invoice date, except usually during the period of
> fiscal year change.
>
Are you really talking about the accounting date here? In issue5205 you
are talking about the invoice date.

If you are talking about the accounting date the planned constraint is
not a good idea as you would not be able to create an invoice for the
year 2015 if you share the invoice sequence with 2016 and you already
created an invoice for 2016.

If you do a monthly invoicing of services the invoice date will differ
from the accounting date every month as the invoice date will be a day
of the following month and the accounting date will be the last day of
the month when the services have been done.

-- 
You received this message because you are subscribed to the Google Groups 
"tryton" group.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tryton/5728BBB4.6090506%40googlemail.com.

Re: [tryton] RFC: Invoice sequences

2016-01-07 Thread 'Korbinian Preisler' via tryton 
On 07.01.2016 12:53, Cédric Krier wrote:
> On 2016-01-07 12:28, Mathias Behrle wrote:
>> * Cédric Krier: " Re: [tryton] RFC: Invoice sequences" (Sat, 26 Dec 2015
>>   15:10:15 +0100):
>>
>>> On 2015-12-25 22:26, Jordi Esteve (Zikzakmedia) wrote:
 El 24/12/15 a les 15:06, Cédric Krier ha escrit:
> Hi,
>
> Following the previous discussions about the invoice sequence and the
> fiscal year, I have started a feature request to improve the situation
> and manage more cases.
>
> https://bugs.tryton.org/issue5205
>
> Please comment if the proposal could be in conflict with your local
> usage.
 The new proposal (a check when setting the number on an invoice to ensure
 that the invoice date not before any invoice dates numbered with the same
 sequence) fits well the Spanish law and practice.

 In fact, the Spanish team maintains a module [1] that implements this idea
 with some restrictions because the sequence is not yet stored in invoices.

 https://bitbucket.org/trytonspain/trytond-account_invoice_consecutive
>>> I see you also have a check for invoice_date == accounting_date for out
>>> invoices. I'm wondering if we should also include this constraint in the
>>> base.
>> According to our knowledge this constraint is definitely wrong for Germany:
>>
>> The accounting date has to be
>> - the date of the delivery for imputed taxation
> But I guess there are some constraint. You can not put a date that is on
> a closed fiscal year for example. Or I think it will be very strange to
> have an invoice with a date in year Y (with numbering of year Y) and the
> accounting date in Y-1.
Think of this case which is very common if the delivery and the
invoicing is done separately:

1. Delivery on 2015-12-30 -> accounting_date = 2015-12-30
2. Invoicing on 2016-01-04 -> invoice_date = 2015-01-04

In Germany the rules for invoice numbering are not very strict. I did a
quick research but did not find any rule that the invoice number cannot
be from the 2015 sequence in this case. But i would prefer to have it
from the 2016 sequence. So i would say that at least in Germany the
sequence should be selected depending on the invoice date.

-- 
___
virtual things
Preisler & Spallek GbR
München - Aachen

Windeckstr. 77
81375 München
Tel: +49 (89) 710 481 55
Fax: +49 (89) 710 481 56

i...@virtual-things.biz
http://www.virtual-things.biz





-- 
You received this message because you are subscribed to the Google Groups 
"tryton" group.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tryton/568E6DB6.6050500%40googlemail.com.

Re: [tryton] RFC: Invoice sequences

2016-01-07 Thread 'Korbinian Preisler' via tryton 
On 07.01.2016 15:04, Mathias Behrle wrote:
> * 'Korbinian Preisler' via tryton: " Re: [tryton] RFC: Invoice sequences" 
> (Thu,
>   7 Jan 2016 14:52:54 +0100):
>
>> On 07.01.2016 12:53, Cédric Krier wrote:
>>> On 2016-01-07 12:28, Mathias Behrle wrote:
>>>> * Cédric Krier: " Re: [tryton] RFC: Invoice sequences" (Sat, 26 Dec 2015
>>>>   15:10:15 +0100):
>>>>
>>>>> On 2015-12-25 22:26, Jordi Esteve (Zikzakmedia) wrote:
>>>>>> El 24/12/15 a les 15:06, Cédric Krier ha escrit:
>>>>>>> Hi,
>>>>>>>
>>>>>>> Following the previous discussions about the invoice sequence and the
>>>>>>> fiscal year, I have started a feature request to improve the situation
>>>>>>> and manage more cases.
>>>>>>>
>>>>>>> https://bugs.tryton.org/issue5205
>>>>>>>
>>>>>>> Please comment if the proposal could be in conflict with your local
>>>>>>> usage.
>>>>>> The new proposal (a check when setting the number on an invoice to ensure
>>>>>> that the invoice date not before any invoice dates numbered with the same
>>>>>> sequence) fits well the Spanish law and practice.
>>>>>>
>>>>>> In fact, the Spanish team maintains a module [1] that implements this
>>>>>> idea with some restrictions because the sequence is not yet stored in
>>>>>> invoices.
>>>>>>
>>>>>> https://bitbucket.org/trytonspain/trytond-account_invoice_consecutive
>>>>> I see you also have a check for invoice_date == accounting_date for out
>>>>> invoices. I'm wondering if we should also include this constraint in the
>>>>> base.
>>>> According to our knowledge this constraint is definitely wrong for Germany:
>>>>
>>>> The accounting date has to be
>>>> - the date of the delivery for imputed taxation
>>> But I guess there are some constraint. You can not put a date that is on
>>> a closed fiscal year for example. Or I think it will be very strange to
>>> have an invoice with a date in year Y (with numbering of year Y) and the
>>> accounting date in Y-1.
>> Think of this case which is very common if the delivery and the
>> invoicing is done separately:
>>
>> 1. Delivery on 2015-12-30 -> accounting_date = 2015-12-30
>> 2. Invoicing on 2016-01-04 -> invoice_date = 2015-01-04
> This should be a minor typo?
> => 2. Invoicing on 2016-01-04 -> invoice_date = 2016-01-04
yes. sorry. 2016-01-04 is correct.

-- 
You received this message because you are subscribed to the Google Groups 
"tryton" group.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tryton/568E7212.5050409%40googlemail.com.

Re: [tryton] About removing invoice/credit note type

2015-11-09 Thread 'Korbinian Preisler' via tryton 
On 21.10.2015 15:08, Cédric Krier wrote:
> On 2015-10-21 14:31, 'Korbinian Preisler' via tryton wrote:
>> But now comes the interesting part. If this is the only case where tax
>> law talks about credit notes, how can we correct wrongly created invoice
>> documents?
>>
>> And this is where we have to switch to commercial common sense. I you
>> want to correct such a document you have to create a 'cancelation'. The
>> german tax authority says that such a cancelation is not a credit note
>> in the sense of value added tax law [3](site 4 right at the beginning)
>>
>> German tax authority also says that an invoice that contains lines for
>> goods supplied/services provided as well as goods/services that are
>> received from the other party the document must be called a credit
>> note.[3](at the end of site 3)
>>
>> Please consider in your plans that a cancelation must create moves with
>> negative amounts instead of the positive amounts an invoice or credit
>> note creates.
> Cancellation already exists, it is not activate on the posted customer
> invoice (but on supplier) because it is not allowed in every country.
> Of course, a standard module that makes the fine tune to activate it is
> welcomed.
I had a deeper look at the cancelation functionality. A legal
requirement for a cancelation is that you need to inform your customer
about the cancelation. So you need a document to do this. As the report
of the invoice is stored there is currently no way to create such a
cancelation report. But i found maybe a solution for this. See my
comments below.
>
>> Maybe these informations will help you to figure out if it is really
>> possible to remove the invoice and credit note type and only to keep the
>> out/in part.
>>
>> I took a look into the SAP documentation and i found there the even 8
>> cases[4]:
>> ininvoice, outinvoice. increditnote, outcreditnote,
>> ininvoicecancelation, outinvoicecancelation, increditnotecancelation,
>> outcreditnotecancelation
> As already stated having invoice/credit note distinction prevents to put
> in the same document both kind of lines. And in case of such mixed
> document it is name is not so trivial to determine. But we can keep the
> numbering distinction using the total sign.
> About the cancelation sub-type, I don't think we have to create a new
> document (record in invoice table) for that. The current design is to
> create a cancelation move linked to the invoice. If a specific number is
> needed for customer cancelation, I guess the module (I talk above) could
> add an other field to hold the number and the invoice report could be
> customized to use this number.
After some thoughts i agree that we do not need the cancelation sub-type
but my explanation is a little bit different to Cedrics one.
I think we already have the cancelation sub-type. I think that we just
use the currency credit note sub-type in a wrong way because it should
be the cancelation instead of the tax-law credit-note.

If we do like this many things will be possible or some others should be
done:
 * Mixed documents will be possible
 * The credit note like it is defined by tax law can be implemented with
a boolean field that marks the "self-billing" and that will switch the
layout of the report. As i noted in my last post there is no other
difference compared to a normal invoice.
 * The Wizard 'Credit Invoice' should be renamed to 'Cancel Invoice' and
should multiply the quantities of the invoice lines with -1
 * A constraint should be implemented that the total mount of an invoice
must be positive and the total amount of an cancelation must be negative

Re: [tryton] About removing invoice/credit note type

2015-11-09 Thread 'Korbinian Preisler' via tryton 
Am 09.11.2015 18:45 schrieb "Cédric Krier" <cedric.kr...@b2ck.com>:
>
> On 2015-11-09 18:21, 'Korbinian Preisler' via tryton wrote:
> > > I don't agree, negative amount is a credit note not a cancellation.
> > > The cancellation of an invoice is managed the cancellation move. This
is
> > > the only way to ensure that the cancellation is really a cancellation.
> > > The amounts can not be modified, the invoice can only be cancelled
once
> > > etc.
> > >
> > Could you please again define for me the credit note you are talking
> > about? What makes your credit note different from an invoice?
>
> A "credit note" in the future design is just an invoice with an amount
> negative

Can you please explain me the business case behind such a credit note? I
ask this because i think that we are talking from different things and i
really want to understand your plans as i think that the changes you plan
are really important.
>
> > Could you explain me how you want to handle partial cancelation?
>
> You don't because it is not possible to cancel partially an invoice
> because of the rounding issue.
> So you have to cancel the all invoice and create a new one with what you
> did not want to cancel.
> The goal of cancelling an invoice is to make like if the invoice was
> never created (for the balance, the credit and the debit of accounts)
> but with rounding issue of partial cancellation, this goal can not be
> achieved.

This is not the only reason for a cancelation.

Re: [tryton] About removing invoice/credit note type

2015-11-09 Thread 'Korbinian Preisler' via tryton 
On 09.11.2015 17:55, Cédric Krier wrote:
> On 2015-11-09 17:43, 'Korbinian Preisler' via tryton wrote:
>> On 09.11.2015 17:14, Cédric Krier wrote:
>>> On 2015-11-09 16:55, 'Korbinian Preisler' via tryton wrote:
>>>> On 09.11.2015 16:28, Cédric Krier wrote:
>>>>> On 2015-11-09 16:00, 'Korbinian Preisler' via tryton wrote:
>>>>>> On 21.10.2015 15:08, Cédric Krier wrote:
>>>>>>> As already stated having invoice/credit note distinction prevents to put
>>>>>>> in the same document both kind of lines. And in case of such mixed
>>>>>>> document it is name is not so trivial to determine. But we can keep the
>>>>>>> numbering distinction using the total sign.
>>>>>>> About the cancelation sub-type, I don't think we have to create a new
>>>>>>> document (record in invoice table) for that. The current design is to
>>>>>>> create a cancelation move linked to the invoice. If a specific number is
>>>>>>> needed for customer cancelation, I guess the module (I talk above) could
>>>>>>> add an other field to hold the number and the invoice report could be
>>>>>>> customized to use this number.
>>>>>> After some thoughts i agree that we do not need the cancelation sub-type
>>>>>> but my explanation is a little bit different to Cedrics one.
>>>>>> I think we already have the cancelation sub-type. I think that we just
>>>>>> use the currency credit note sub-type in a wrong way because it should
>>>>>> be the cancelation instead of the tax-law credit-note.
>>>>>>
>>>>>> If we do like this many things will be possible or some others should be
>>>>>> done:
>>>>>>  * Mixed documents will be possible
>>>>>>  * The credit note like it is defined by tax law can be implemented with
>>>>>> a boolean field that marks the "self-billing" and that will switch the
>>>>>> layout of the report. As i noted in my last post there is no other
>>>>>> difference compared to a normal invoice.
>>>>> I don't see the need of such field because cancellation is already
>>>>> implemented.
>>>> Self-billing is not a cancelation.
>>> Oops, yes I re-read your previous post. Indeed I see no need for such
>>> boolean. You can consider all negative invoice as "self-billing".
>> I think this is a wrong approach. Self-billing is a change in process
>> but not a change in the document itself.
>>
>> I will try to explain again the self-billing process. Consider a
>> supplier A delivering a product to company B. Company B is the company
>> that is manage by tryton.
>> Normally the supplier will write an invoice for this delivery. But A and
>> B can agree on a self-billing by the customer. The customer then will
>> write a 'credit note' to the supplier.
>> As the customer is writing the invoice for himself he does a
>> self-billing. But in the sense of tryton it is just an in-invoice. There
>> is no need to make the total amount negative.
>> It is just a supplier invoice. Only the process how the invoice is
>> written is different.
> OK so nothing to do. Tryton already manages the manual creation of
> supplier invoice.
You did not yet convince me about this point. Maybe we did not yet
understand each other completely.
>> I would use the negative total amount to determine the document to be a
>> cancellation or not. It will make the document handling for a
>> cancellation easier as you only have
>> one report per record.
> I don't agree, negative amount is a credit note not a cancellation.
> The cancellation of an invoice is managed the cancellation move. This is
> the only way to ensure that the cancellation is really a cancellation.
> The amounts can not be modified, the invoice can only be cancelled once
> etc.
>
Could you please again define for me the credit note you are talking
about? What makes your credit note different from an invoice?

Could you explain me how you want to handle partial cancelation?

Re: [tryton] About removing invoice/credit note type

2015-11-09 Thread 'Korbinian Preisler' via tryton 
On 09.11.2015 16:28, Cédric Krier wrote:
> On 2015-11-09 16:00, 'Korbinian Preisler' via tryton wrote:
>> On 21.10.2015 15:08, Cédric Krier wrote:
>>> Cancellation already exists, it is not activate on the posted customer
>>> invoice (but on supplier) because it is not allowed in every country.
>>> Of course, a standard module that makes the fine tune to activate it is
>>> welcomed.
>> I had a deeper look at the cancelation functionality. A legal
>> requirement for a cancelation is that you need to inform your customer
>> about the cancelation. So you need a document to do this. As the report
>> of the invoice is stored there is currently no way to create such a
>> cancelation report. But i found maybe a solution for this. See my
>> comments below.
> The cancellation report is simply the invoice report as the state will be
> showed as canceled (but it requires some tuning because of the report
> cache, maybe an other report entry).
If you want to do it that way another report entry will be needed.
>
>>> As already stated having invoice/credit note distinction prevents to put
>>> in the same document both kind of lines. And in case of such mixed
>>> document it is name is not so trivial to determine. But we can keep the
>>> numbering distinction using the total sign.
>>> About the cancelation sub-type, I don't think we have to create a new
>>> document (record in invoice table) for that. The current design is to
>>> create a cancelation move linked to the invoice. If a specific number is
>>> needed for customer cancelation, I guess the module (I talk above) could
>>> add an other field to hold the number and the invoice report could be
>>> customized to use this number.
>> After some thoughts i agree that we do not need the cancelation sub-type
>> but my explanation is a little bit different to Cedrics one.
>> I think we already have the cancelation sub-type. I think that we just
>> use the currency credit note sub-type in a wrong way because it should
>> be the cancelation instead of the tax-law credit-note.
>>
>> If we do like this many things will be possible or some others should be
>> done:
>>  * Mixed documents will be possible
>>  * The credit note like it is defined by tax law can be implemented with
>> a boolean field that marks the "self-billing" and that will switch the
>> layout of the report. As i noted in my last post there is no other
>> difference compared to a normal invoice.
> I don't see the need of such field because cancellation is already
> implemented.
Self-billing is not a cancelation.
>
>>  * The Wizard 'Credit Invoice' should be renamed to 'Cancel Invoice' and
>> should multiply the quantities of the invoice lines with -1
>>  * A constraint should be implemented that the total mount of an invoice
>> must be positive and the total amount of an cancelation must be negative
> I don't see the point of having a constraint. It is not needed to work
> correctly if the "type" is deducted from the sign of the amount.
>
Which "type" are you talking about?

Re: [tryton] About removing invoice/credit note type

2015-11-09 Thread 'Korbinian Preisler' via tryton 
On 09.11.2015 17:14, Cédric Krier wrote:
> On 2015-11-09 16:55, 'Korbinian Preisler' via tryton wrote:
>> On 09.11.2015 16:28, Cédric Krier wrote:
>>> On 2015-11-09 16:00, 'Korbinian Preisler' via tryton wrote:
>>>> On 21.10.2015 15:08, Cédric Krier wrote:
>>>>> As already stated having invoice/credit note distinction prevents to put
>>>>> in the same document both kind of lines. And in case of such mixed
>>>>> document it is name is not so trivial to determine. But we can keep the
>>>>> numbering distinction using the total sign.
>>>>> About the cancelation sub-type, I don't think we have to create a new
>>>>> document (record in invoice table) for that. The current design is to
>>>>> create a cancelation move linked to the invoice. If a specific number is
>>>>> needed for customer cancelation, I guess the module (I talk above) could
>>>>> add an other field to hold the number and the invoice report could be
>>>>> customized to use this number.
>>>> After some thoughts i agree that we do not need the cancelation sub-type
>>>> but my explanation is a little bit different to Cedrics one.
>>>> I think we already have the cancelation sub-type. I think that we just
>>>> use the currency credit note sub-type in a wrong way because it should
>>>> be the cancelation instead of the tax-law credit-note.
>>>>
>>>> If we do like this many things will be possible or some others should be
>>>> done:
>>>>  * Mixed documents will be possible
>>>>  * The credit note like it is defined by tax law can be implemented with
>>>> a boolean field that marks the "self-billing" and that will switch the
>>>> layout of the report. As i noted in my last post there is no other
>>>> difference compared to a normal invoice.
>>> I don't see the need of such field because cancellation is already
>>> implemented.
>> Self-billing is not a cancelation.
> Oops, yes I re-read your previous post. Indeed I see no need for such
> boolean. You can consider all negative invoice as "self-billing".
I think this is a wrong approach. Self-billing is a change in process
but not a change in the document itself.

I will try to explain again the self-billing process. Consider a
supplier A delivering a product to company B. Company B is the company
that is manage by tryton.
Normally the supplier will write an invoice for this delivery. But A and
B can agree on a self-billing by the customer. The customer then will
write a 'credit note' to the supplier.
As the customer is writing the invoice for himself he does a
self-billing. But in the sense of tryton it is just an in-invoice. There
is no need to make the total amount negative.
It is just a supplier invoice. Only the process how the invoice is
written is different.

I would use the negative total amount to determine the document to be a
cancellation or not. It will make the document handling for a
cancellation easier as you only have
one report per record.
>
>>>>  * The Wizard 'Credit Invoice' should be renamed to 'Cancel Invoice' and
>>>> should multiply the quantities of the invoice lines with -1
>>>>  * A constraint should be implemented that the total mount of an invoice
>>>> must be positive and the total amount of an cancelation must be negative
>>> I don't see the point of having a constraint. It is not needed to work
>>> correctly if the "type" is deducted from the sign of the amount.
>>>
>> Which "type" are you talking about?
> You are talking about constraint on specific type of invoice so this
> will require to put a type on the invoice. But I think it is not
> necessary because the sign of the amount define the type.
>

Re: [tryton] About removing invoice/credit note type

2015-11-09 Thread 'Korbinian Preisler' via tryton 
On 09.11.2015 17:14, Cédric Krier wrote:
> On 2015-11-09 16:55, 'Korbinian Preisler' via tryton wrote:
>> On 09.11.2015 16:28, Cédric Krier wrote:
>>> On 2015-11-09 16:00, 'Korbinian Preisler' via tryton wrote:
>>>> On 21.10.2015 15:08, Cédric Krier wrote:
>>>>> As already stated having invoice/credit note distinction prevents to put
>>>>> in the same document both kind of lines. And in case of such mixed
>>>>> document it is name is not so trivial to determine. But we can keep the
>>>>> numbering distinction using the total sign.
>>>>> About the cancelation sub-type, I don't think we have to create a new
>>>>> document (record in invoice table) for that. The current design is to
>>>>> create a cancelation move linked to the invoice. If a specific number is
>>>>> needed for customer cancelation, I guess the module (I talk above) could
>>>>> add an other field to hold the number and the invoice report could be
>>>>> customized to use this number.
>>>> After some thoughts i agree that we do not need the cancelation sub-type
>>>> but my explanation is a little bit different to Cedrics one.
>>>> I think we already have the cancelation sub-type. I think that we just
>>>> use the currency credit note sub-type in a wrong way because it should
>>>> be the cancelation instead of the tax-law credit-note.
>>>>
>>>> If we do like this many things will be possible or some others should be
>>>> done:
>>>>  * Mixed documents will be possible
>>>>  * The credit note like it is defined by tax law can be implemented with
>>>> a boolean field that marks the "self-billing" and that will switch the
>>>> layout of the report. As i noted in my last post there is no other
>>>> difference compared to a normal invoice.
>>> I don't see the need of such field because cancellation is already
>>> implemented.
>> Self-billing is not a cancelation.
> Oops, yes I re-read your previous post. Indeed I see no need for such
> boolean. You can consider all negative invoice as "self-billing".
A self-billing is not a credit note you talk about. What you call a
credit note is a correction of a wrongly written invoice.

But self-billing is something different. self-billing is not done to
make a correction it is just a change in the process of writing an
official invoice.
Instead of the supplier writing the invoice for his delivery the
customer writes this invoice for himself on his own letter paper.

1. Normal case:
* Supplier delivers product
* Supplier writes invoice for this delivery

2. Self-billing case:
* Supplier delivers product
* Customer writes invoice for this delivery on his own letter paper in
the name of the supplier.

This is a completely different thing than the credit note you talk about.

I think it is good to repost the part from the legal eu document:

Article 224 (taken from [1])
Invoices may be drawn up by the customer in respect of
the supply to him, by a taxable person, of goods or
services, where there is a prior agreement between the
two parties and provided that a procedure exists for the
acceptance of each invoice by the taxable person supplying
the goods or services. Member State may require that such
invoices be issued in the name and on behalf of the taxable
person.

And this article produces the current confusion:

Article 226 (taken from [1])
Without prejudice to the particular provisions laid down in this
Directive, only the following details are required for VAT
purposes on invoices issued pursuant to Articles 220 and 221:
...
(10a) where the customer receiving a supply issues the
invoice instead of the supplier, the mention
“Self-billing”;’; (taken from [2] which is an extension of [1])

Because in german "Self-billing" is translated into "Gutschrift" that is
often retranslated to "Credit Note" what is wrong in our case as you are
talking about the credit note in commercial common sense. To complete
the confusion the credit note in commercial common sense is called
"Storno" which is often translated in to "cancelation" which also does
not match your understanding of a cancelation. I just want to show the
difficulty what we have here with language interpretation.
>>>>  * The Wizard 'Credit Invoice' should be renamed to 'Cancel Invoice' and
>>>> should multiply the quantities of the invoice lines with -1
>>>>  * A constraint should be implemented that the total mount of an invoice
>>>> must be positive and the total amount of an cancelation must be negative
>>> I don't see the point of having a constraint. It is not needed to

Re: [tryton] About removing invoice/credit note type

2015-11-09 Thread 'Korbinian Preisler' via tryton 
On 09.11.2015 23:01, Cédric Krier wrote:
> On 2015-11-09 21:03, 'Korbinian Preisler' via tryton wrote:
>> I will try to sum up again the things that need to be done:
>>  * The invoice/credit note type will be removed
>>  * The self-billing like it is defined by tax law can be implemented with
>> a boolean field that marks the "self-billing" and that will switch the
>> layout of the report. As i noted in my last post there is no other
>> difference compared to a normal invoice.
>>  * The Wizard 'Credit Invoice' should should multiply the quantities of
>> the invoice lines with -1 to produce the negative total amount
>>  * A credit note (which is defined by a record with a negative total
>> amount) must produce move lines with negative amounts
> I don't agree with this. In most countries having negative debit or
> credit is at least suspicious or even forbidden. This must not be the
> default behaviour of Tryton and at least it should be possible to have
> a kind of invoice that inverse the debit/credit.
> Negative debit/credit are done with the cancellation procedure.
Could someone point me to some information about this? I really
interested why this should be forbidden in some countries as i think
that this is a native feature of accounting and i do not see any reason
why this should be forbidden.
>> For me the current cancelation functionality can be removed as it will
>> now implemented by a credit note (which is defined by a record with a
>> negative total amount). But i could live with it if it will be limited
>> to the supplier side like it is now.
> It must stay as I said above we need to have a way to generate both kind
> of move.
>
As i said above some pointers to the reasons why this is really needed
would help me to understand this requirement.

Re: [tryton] About removing invoice/credit note type

2015-10-21 Thread 'Korbinian Preisler' via tryton 
On 21.10.2015 12:26, Cédric Krier wrote:
> On 2015-10-21 12:07, Albert Cervera i Areny wrote:
>> 2015-10-20 21:53 GMT+02:00 Cédric Krier :
>>> On 2015-10-20 21:17, Jordi Esteve wrote:
 El 20/10/15 a les 19:24, Cédric Krier ha escrit:
> On 2015-10-20 19:07, Albert Cervera i Areny wrote:
>> 2015-10-20 18:38 GMT+02:00 Cédric Krier :
>>> Hi,
>>>
>>> I was discussing about issue5016 [1] which is indeed a continuation of
>>> issue4410 [2] and I came with the idea that we should remove the
>>> invoice/credit_note type on the Invoice object.
>>> Such types are really a big constraint that prevent us to generate mixed
>>> documents (half invoice and half credit note).
>>>
>>> So the idea will be to migrate the credit note to negate the quantity
>>> and keep in type only 'in' / 'out' (aka 'supplier' / 'customer').
>>>
>>> The only difficulty will be for the sequence. Until now, we have the
>>> possibility to use different sequences for invoice and credit note. I
>>> think the way to manage such change will be to warn early enough users
>>> that such configuration will no more be possible in the future and so
>>> people should configure the next fiscalyear by using unique sequence for
>>> both types in prevision of the future migration.
>> We need both sequences in Spain as it is a legal requirement [1].
> Could you point to which page?
 Page 23:

 
 Número y, en su caso, serie. La numeración de las facturas dentro de cada
 serie debe ser correlativa

 Es obligatoria, en todo caso, la expedición en series específicas de las
 facturas siguientes:
 - Las rectificativas.
 

 As Albert has said, credit notes could be removed and replaced by different
 invoice sequences, like account_invoice_multisequence module [1] does.
>>> This doesn't say that invoice and credit note must have a different
>>> sequence.
>> It does. When it says that they need to be with specific sequences, it
>> means that they must be different from standard invoices. "Facturas
>> rectificativas" is the equivalent to credit notes.
>>
>>> But of course, customization of the invoice numbering will still be
>>> possible. But they will have also to merge the two types.
>>>
>> Yet,
>> it should not be all that difficult to choose the sequence depending
>> on the sign of the invoice.
> I think if you have really this constraint, this means that you can not
> mix positive and negative lines on the same document otherwise it is not
> consistent.
 It depends, Spanish legal requirements for credit notes are strict (page
 38); summarizing credit notes in Spain must come from previous invoices. 
 But
 you can have negative amounts in sales/purchases and generate a single
 invoice with mixed positive/negative amounts.
>>> So I don't see that it is a requirement to have separated sequences
>>> for each kind.
>>>
>> Indeed, in page 171 of the same document (and some other notes
>> elsewhere in the same document) it states that it is not possible to
>> have negative amounts in normal invoices if they are to invoice
>> returning goods. Those should always be in a "Factura rectificativa"
>> and should state the invoice of the goods that were delivered in the
>> first place.
> I think you are not looking at the important information.
> In some way, we don't care how they named the document. What is
> important is if there should be a clear separation between what we call
> now invoice and credit note. If there is, what is the definition of an
> invoice and a credit note?
>
I try to write down that definition. I try to take texts from legal
documents where i was able to find the correct article. But we have to
consider that there are different definitions between commercial common
sense and tax law and this is the point where most of the confusion
comes from.

What is an invoice?

Article 220 (taken from [1])
Every taxable person shall ensure that, in respect of the
following, an invoice is issued, either by himself or by his
customer or, in his name and on his behalf, by a third party:
(1) supplies of goods or services which he has made to another
taxable person or to a non-taxable legal person;
(2) supplies of goods as referred to in Article 33;
(3) supplies of goods carried out in accordance with the
conditions specified in Article 138;
(4) any payment on account made to him before one of the
supplies of goods referred to in points (1), (2) and (3) was
carried out;
(5) any payment on account made to him by another taxable
person or non-taxable legal person before the provision of
services was completed.

So what is a credit note?

Article 224 (taken from [1])
Invoices may be drawn up by the customer in respect of
the supply to him, by a taxable person, of goods or
services, where there is a prior agreement between the
two parties and