date:20161204

Re: [tryton] Invoice Location

2016-12-04 Thread Cédric Krier

On 2016-12-04 12:04, Carlos Eduardo Sotelo Pinto wrote:
> *-- Parties on tryton let to add more than one identifier, that makes me a
> legal issue on a before implementation that I have done, since **tax
> autority said it must not be done on this way because each party must have
> just one identifier an no more than one.*

I can not believe you that tax authorities have requirement on how a
software should be designed.
I can not see how what you describe can be a legal issue. Of course if a
party can be assigned only one of those numbers by the authorities,
there are no reason you magically enter more than one.

Until this point is not clarify, I will not talk any other topics.

-- 
Cédric Krier - B2CK SPRL
Email/Jabber: cedric.kr...@b2ck.com
Tel: +32 472 54 46 59
Website: http://www.b2ck.com/

-- 
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/20161205013927.GL71015%40tetsuo.

Re: [tryton] Invoice Location

2016-12-04 Thread Carlos Eduardo Sotelo Pinto

Hello List, Raimon

2016-12-04 12:15 GMT-05:00 Raimon Esteve :

> Hie,
>
> You could custom the invoice report and show/hide more fields. Or add
> labels depends the party (a boolean field, if party has a
> identifier/vat.).
>
> For example, in Spain, a party has'nt a vat (identifier), the report is
> "factura simplificada".
>

Yes, I currently do that, however tax autorithy do a observation on this
way on manage, since identifiers are a many to many relation ship, and
party must have one identifier and no more than that.

Thre is no issue son simple invoice, since is no mandatory the identifier,
but on commercial invoice is mandatory vat , and must be one on a one to
many relationship

Identifiers must be on this sctructure and list


CODE| Description
==
* 0 | DOC.TRIB.NO.DOM.SIN.RUC
* 1 | DOC. NACIONAL DE IDENTIDAD
* 4 | CARNET DE EXTRANJERIA
* 6 | REG. UNICO DE CONTRIBUYENTES
* 7 | PASAPORTE
* A | CED. DIPLOMATICA DE IDENTIDAD

And invoice types must have this structure and list

 CODE| Description | Document Name | Tryton Name
===
* 
01 | 
FACTURA
 | 380
   | Invoice
* 
03 
| 
BOLETA DE VENTA
 | 346
   | --
* 
07 
| 
NOTA DE CREDITO
 | 381
   | Credit note
* 
08 
| 
NOTA DE DEBITO
  | 383
   | Debit Note



>
> About invoice sequences, we have developed a module wich has new features
> about invoice sequence defined in the invoice journal.
>

I also do something similar, also was observed but tax authority, that is
the reason on asking, I want to fill tax autority requirements without
break python guidelines.


Best regards




>
> --
> 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/CAN2HbXU6kYsXCcS%3DPNMPG73bqrwr2Ltto5Myj2VmNvpG
> 0N-NXg%40mail.gmail.com
> 
> .
>



-- 
Carlos Eduardo Sotelo Pinto
Senior Software Developer
Claro RPC +51 989550602
GTalk: carlos.sotelo.pi...@gmail.com | Skype: csotelop
GNULinux RU #379182 | GNULinux RM #277661

Please consider the environment before printing this email
Join the campaign at http://thinkBeforePrinting.org

-- 
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/CAEhw%3DE8p0KsR136V%2BkA0hG%2B008AwiK_mv%2BK0mJHLa0y101h4Pw%40mail.gmail.com.

Re: [tryton] Invoice Location

2016-12-04 Thread Carlos Eduardo Sotelo Pinto

2016-12-04 10:39 GMT-05:00 Cédric Krier :

> On 2016-12-04 07:29, Carlos Eduardo Sotelo Pinto wrote:
> > Hi Cedrik
> >
> > 2016-12-04 6:34 GMT-05:00 Cédric Krier :
> >
> > > On 2016-12-03 21:46, Carlos Eduardo Sotelo Pinto wrote:
> > > > Hi Cedrik, List
> > > >
> > > > Yes Cedirk, you are right, there is no difference on accounting,
> just on
> > > > the printing, on this way:
> > > >
> > > > - Simple invoice, no taxes must be printed, but the taxes are the
> same
> > > > - Commercial invoice, taxes printing is mandatory as a common
> invoice.
> > >
> > > So I do not see why you could not use the same layout. A simple invoice
> > > with taxes shown will not make it invalid.
> > >
> >
> > Yes, I currently using this layout, however I am having some issues,
> on it
>
> If you do not describe the issue, it is not possible to follow you.
>
> > > > I guess, the main difference is relted to party, no the invoice at
> > > itself.
> > > > As the information provided and the ER diagram, Party could be
> > > categorized
> > > > on :
> > > >
> > > > - Companies, which one just could request for a common or commercial
> > > invoice
> > > > - No companies, this kinds of partyes couldnt request the common
> invoice,
> > > > just simple invoice
> > >
> > > I do not understand the point. You just said that both type does
> exactly
> > > the same.
> > >
> >
> > Yes, on accounting side is the same behavior, but printing report are
> > different. I have solve that on this way
> >
> > - Giving a sub type [ Boleta, Factura ] with diferent sequences
>
> First time, you talk about sequence. What are the requirements?
>
> > Until here all is ok and work perfectly, the issue is:
> >
> > - There is no restruiction on the use. I mean.
> >
> > - Boletas ( Simple invoice ) must be ussed just for NON Companies (
> Parties
> > with no VAT identification )
> > - Facturas ( Current Invoice ) must be used just for COmpanies ( Parties
> > with VATidentification )
> >
> > And the generated problems
> >
> > - A lots of mistakes generated for the final users since there is no a
> > restriction for Parties
> >
> > * Simple invoices generated for Companies that must be nulled later
> > * Comercial invoiced generated for Non COmpanies
> >
> > I need to fins a way on the tryton layout in order to restrict:
>
> I do not understand what you mean, a layout will never restrict
> anything.
>
> > - Parties must have one of this identifiers as unique and main
> identifier:
> >
> > CODE| Description
> > ==
> 
> > * 0 | DOC.TRIB.NO.DOM.SIN.RUC
> > * 1 | DOC. NACIONAL DE IDENTIDAD
> > * 4 | CARNET DE EXTRANJERIA
> > * 6 | REG. UNICO DE CONTRIBUYENTES
> > * 7 | PASAPORTE
> > * A | CED. DIPLOMATICA DE IDENTIDAD
> >
> > - Based on the before point, commercial or current invoice must be
> > generated just for customer parties with Code 6 ( Companies ) other wise,
> > just simple invoice
> >
> > - That codification must be part of the document party and a combination
> > with the number of the document. I must be suing idetifiers, however
> > identifiers are on a many to many relation ship, I could add more than
> one
> > identifier to one party, that is a legal issue. I could fix it just
> > extending parties.
>
> I do not understand how this can be a legal issue. If the party has many
> identifier, it is something he has.
>
> > - Invoice types must be coded on this way ( There are 19 different
> taxable
> > documents but we could start with this 4):
> >
> >  CODE| Description | Document Name
> > ===
> > * 
> > 01 | 
> > FACTURA
> >  | 380
> >
> > * 
> > 03 
> > | 
> > BOLETA DE VENTA
> >  | 346
> >
> > * 
> > 07 
> > | 
> > NOTA DE CREDITO
> >  | 381
> >
> > * 
> > 08 
> > | 
> > NOTA DE DEBITO
> >   | 383
> >
> >
> >
> >
> > THat is my issues, I have it clear on my side, extend the invoice witha
> > relation ship restriction on the party document type, however I dont want
> > to break trytonic way. That is teh reason on asking the a suggest
>
> I still do not understand what is the problem you try to solve and why.
>
> --
> Cédric Krier - B2CK SPRL
> Email/Jabber: cedric.kr...@b2ck.com
> Tel: +32 472 54 46 59
> Website: http://www.b2ck.com/
>
> --
> 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/20161204153944.GH71015%40tetsuo.
>


**Hello Cedrik

I wil try to explain again the requirements:

*Party*
=

- Parties must have one of this identifiers as the only one an no more.

CODE| Description
==
* 0 | DOC.TRIB.NO.DOM.SIN.RUC
* 1 | DOC. NACIONAL DE IDENTIDAD
* 4 | CARNET DE EXTRANJERIA
* 6 | REG. UNICO DE CONTRIBUYENTES
* 7 | PASAPORTE
* A | CED. DIPLOMATICA DE IDENTIDAD

- This type of codification must be part of *the document or party
identifier* and, a combination of this

Re: [tryton] New Tryton installation

2016-12-04 Thread Eric Magray



> You can install with pip from pypi and it will download the python3 
> version. 
>
> All the modules are prefixed with the `trytond_` keyword, so for example 
> for installing the sale module you should install the `trytond_sale` 
> package. 
>

Thank you! When I first tried installing them I believe it was before the 
python3 versions were available. I just happened to be attempting my setup 
the day 4.2 was released. Now I see the python3 versions are up and ready 
for download =) 

-- 
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/9b7aae88-2b78-4ca7-8c4b-83e9d917c0a1%40googlegroups.com.

Re: [tryton] Invoice Location

2016-12-04 Thread Raimon Esteve

Hie,

You could custom the invoice report and show/hide more fields. Or add
labels depends the party (a boolean field, if party has a
identifier/vat.).

For example, in Spain, a party has'nt a vat (identifier), the report is
"factura simplificada".

About invoice sequences, we have developed a module wich has new features
about invoice sequence defined in the invoice journal.

-- 
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/CAN2HbXU6kYsXCcS%3DPNMPG73bqrwr2Ltto5Myj2VmNvpG0N-NXg%40mail.gmail.com.

Re: [tryton] Invoice Location

2016-12-04 Thread Cédric Krier

On 2016-12-04 07:29, Carlos Eduardo Sotelo Pinto wrote:
> Hi Cedrik
> 
> 2016-12-04 6:34 GMT-05:00 Cédric Krier :
> 
> > On 2016-12-03 21:46, Carlos Eduardo Sotelo Pinto wrote:
> > > Hi Cedrik, List
> > >
> > > Yes Cedirk, you are right, there is no difference on accounting, just on
> > > the printing, on this way:
> > >
> > > - Simple invoice, no taxes must be printed, but the taxes are the same
> > > - Commercial invoice, taxes printing is mandatory as a common invoice.
> >
> > So I do not see why you could not use the same layout. A simple invoice
> > with taxes shown will not make it invalid.
> >
> 
> Yes, I currently using this layout, however I am having some issues, on it

If you do not describe the issue, it is not possible to follow you.

> > > I guess, the main difference is relted to party, no the invoice at
> > itself.
> > > As the information provided and the ER diagram, Party could be
> > categorized
> > > on :
> > >
> > > - Companies, which one just could request for a common or commercial
> > invoice
> > > - No companies, this kinds of partyes couldnt request the common invoice,
> > > just simple invoice
> >
> > I do not understand the point. You just said that both type does exactly
> > the same.
> >
> 
> Yes, on accounting side is the same behavior, but printing report are
> different. I have solve that on this way
> 
> - Giving a sub type [ Boleta, Factura ] with diferent sequences

First time, you talk about sequence. What are the requirements?

> Until here all is ok and work perfectly, the issue is:
> 
> - There is no restruiction on the use. I mean.
> 
> - Boletas ( Simple invoice ) must be ussed just for NON Companies ( Parties
> with no VAT identification )
> - Facturas ( Current Invoice ) must be used just for COmpanies ( Parties
> with VATidentification )
> 
> And the generated problems
> 
> - A lots of mistakes generated for the final users since there is no a
> restriction for Parties
> 
> * Simple invoices generated for Companies that must be nulled later
> * Comercial invoiced generated for Non COmpanies
> 
> I need to fins a way on the tryton layout in order to restrict:

I do not understand what you mean, a layout will never restrict
anything.

> - Parties must have one of this identifiers as unique and main identifier:
> 
> CODE| Description
> ==
> * 0 | DOC.TRIB.NO.DOM.SIN.RUC
> * 1 | DOC. NACIONAL DE IDENTIDAD
> * 4 | CARNET DE EXTRANJERIA
> * 6 | REG. UNICO DE CONTRIBUYENTES
> * 7 | PASAPORTE
> * A | CED. DIPLOMATICA DE IDENTIDAD
> 
> - Based on the before point, commercial or current invoice must be
> generated just for customer parties with Code 6 ( Companies ) other wise,
> just simple invoice
> 
> - That codification must be part of the document party and a combination
> with the number of the document. I must be suing idetifiers, however
> identifiers are on a many to many relation ship, I could add more than one
> identifier to one party, that is a legal issue. I could fix it just
> extending parties.

I do not understand how this can be a legal issue. If the party has many
identifier, it is something he has.

> - Invoice types must be coded on this way ( There are 19 different taxable
> documents but we could start with this 4):
> 
>  CODE| Description | Document Name
> ===
> * 
> 01 | 
> FACTURA
>  | 380
> 
> * 
> 03 
> | 
> BOLETA DE VENTA
>  | 346
> 
> * 
> 07 
> | 
> NOTA DE CREDITO
>  | 381
> 
> * 
> 08 
> | 
> NOTA DE DEBITO
>   | 383
> 
> 
> 
> 
> THat is my issues, I have it clear on my side, extend the invoice witha
> relation ship restriction on the party document type, however I dont want
> to break trytonic way. That is teh reason on asking the a suggest

I still do not understand what is the problem you try to solve and why.

-- 
Cédric Krier - B2CK SPRL
Email/Jabber: cedric.kr...@b2ck.com
Tel: +32 472 54 46 59
Website: http://www.b2ck.com/

-- 
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/20161204153944.GH71015%40tetsuo.

Re: [tryton] Invoice Location

2016-12-04 Thread Carlos Eduardo Sotelo Pinto

Hi Cedrik

2016-12-04 6:34 GMT-05:00 Cédric Krier :

> On 2016-12-03 21:46, Carlos Eduardo Sotelo Pinto wrote:
> > Hi Cedrik, List
> >
> > Yes Cedirk, you are right, there is no difference on accounting, just on
> > the printing, on this way:
> >
> > - Simple invoice, no taxes must be printed, but the taxes are the same
> > - Commercial invoice, taxes printing is mandatory as a common invoice.
>
> So I do not see why you could not use the same layout. A simple invoice
> with taxes shown will not make it invalid.
>

Yes, I currently using this layout, however I am having some issues, on it

>
> > I guess, the main difference is relted to party, no the invoice at
> itself.
> > As the information provided and the ER diagram, Party could be
> categorized
> > on :
> >
> > - Companies, which one just could request for a common or commercial
> invoice
> > - No companies, this kinds of partyes couldnt request the common invoice,
> > just simple invoice
>
> I do not understand the point. You just said that both type does exactly
> the same.
>

Yes, on accounting side is the same behavior, but printing report are
different. I have solve that on this way

- Giving a sub type [ Boleta, Factura ] with diferent sequences

Until here all is ok and work perfectly, the issue is:

- There is no restruiction on the use. I mean.

- Boletas ( Simple invoice ) must be ussed just for NON Companies ( Parties
with no VAT identification )
- Facturas ( Current Invoice ) must be used just for COmpanies ( Parties
with VATidentification )

And the generated problems

- A lots of mistakes generated for the final users since there is no a
restriction for Parties

* Simple invoices generated for Companies that must be nulled later
* Comercial invoiced generated for Non COmpanies

I need to fins a way on the tryton layout in order to restrict:

- Parties must have one of this identifiers as unique and main identifier:

CODE| Description
==
* 0 | DOC.TRIB.NO.DOM.SIN.RUC
* 1 | DOC. NACIONAL DE IDENTIDAD
* 4 | CARNET DE EXTRANJERIA
* 6 | REG. UNICO DE CONTRIBUYENTES
* 7 | PASAPORTE
* A | CED. DIPLOMATICA DE IDENTIDAD

- Based on the before point, commercial or current invoice must be
generated just for customer parties with Code 6 ( Companies ) other wise,
just simple invoice

- That codification must be part of the document party and a combination
with the number of the document. I must be suing idetifiers, however
identifiers are on a many to many relation ship, I could add more than one
identifier to one party, that is a legal issue. I could fix it just
extending parties.

- Invoice types must be coded on this way ( There are 19 different taxable
documents but we could start with this 4):

 CODE| Description | Document Name
===
* 
01 | 
FACTURA
 | 380

* 
03 
| 
BOLETA DE VENTA
 | 346

* 
07 
| 
NOTA DE CREDITO
 | 381

* 
08 
| 
NOTA DE DEBITO
  | 383




THat is my issues, I have it clear on my side, extend the invoice witha
relation ship restriction on the party document type, however I dont want
to break trytonic way. That is teh reason on asking the a suggest


>
> > As explained on before, I am using just a difference on the printing,
> and I
> > use a extra field like "Invoice document type", then I could choice which
> > one will be the final printing. However this is no making a real
> difference
> > between the parties related, since I could select a non company and use
> the
> > common invoice, do you make send?
>
> This will be solved by using the same layout.
>
> --
> Cédric Krier - B2CK SPRL
> Email/Jabber: cedric.kr...@b2ck.com
> Tel: +32 472 54 46 59
> Website: http://www.b2ck.com/
>
> --
> 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/20161204113420.GF71015%40tetsuo.
>



-- 
Carlos Eduardo Sotelo Pinto
Senior Software Developer
Claro RPC +51 989550602
GTalk: carlos.sotelo.pi...@gmail.com | Skype: csotelop
GNULinux RU #379182 | GNULinux RM #277661

Please consider the environment before printing this email
Join the campaign at http://thinkBeforePrinting.org

-- 
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/CAEhw%3DE-x0GZKPykC34MaVJq6ZtLqVOv4TiLr8MfpiZ9YWqvr8Q%40mail.gmail.com.

Re: [tryton] Invoice Location

2016-12-04 Thread Cédric Krier

On 2016-12-03 21:46, Carlos Eduardo Sotelo Pinto wrote:
> Hi Cedrik, List
> 
> Yes Cedirk, you are right, there is no difference on accounting, just on
> the printing, on this way:
> 
> - Simple invoice, no taxes must be printed, but the taxes are the same
> - Commercial invoice, taxes printing is mandatory as a common invoice.

So I do not see why you could not use the same layout. A simple invoice
with taxes shown will not make it invalid.

> I guess, the main difference is relted to party, no the invoice at itself.
> As the information provided and the ER diagram, Party could be categorized
> on :
> 
> - Companies, which one just could request for a common or commercial invoice
> - No companies, this kinds of partyes couldnt request the common invoice,
> just simple invoice

I do not understand the point. You just said that both type does exactly
the same.

> As explained on before, I am using just a difference on the printing, and I
> use a extra field like "Invoice document type", then I could choice which
> one will be the final printing. However this is no making a real difference
> between the parties related, since I could select a non company and use the
> common invoice, do you make send?

This will be solved by using the same layout.

-- 
Cédric Krier - B2CK SPRL
Email/Jabber: cedric.kr...@b2ck.com
Tel: +32 472 54 46 59
Website: http://www.b2ck.com/

-- 
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/20161204113420.GF71015%40tetsuo.

Re: [tryton] Re: version 4 GL & balance reports

2016-12-04 Thread Cédric Krier

On 2016-12-04 07:59, Richard PALO wrote:
> As a side note, seems a bit heavy if tryton needs to read all previous
> years to get starting balance (I most certinaly hope not).

It is not heaving and indeed it is even a speedup.

> This is one of the benefits of having an annual opening balance as is
> traditionnally done (not to mention it expressly provides for independent
> accounting years, a fundamental principle in accounting).

This is not the design chosen by Tryton because it breaks any attempt to
track receivable or payable.

> In any event, one must not be myopic as to the number of fiscal years.

Do not understand.

> > > 3. with movements (in the period)
> > 
> > This could probably be done by creating a Function field that returns
> > the number of moves.
> > 
> > > seems there should probably also be an option simply to include or not 
> > > the 'start balance' as well
> > 
> > Do you mean that you want to have a column with debit - credit ?
> > 
> 
> Well, for a balance report, it is useful to have either extra column for 
> initial balance, or both debit and credit,
> but this is probably a simple matter of report formatting which could be site 
> specific.

For me, it is not necessary on trial balance because the goal is to show
that the accounts are balanced so if start and and balance sum equals 0
and debit equals credit sum, it is OK.

> For GL it is typically an additional line prior to the moves for the period.

There is already.

> > > while suppressing the non-intuitive behaviour currently of 4.x selecting 
> > > by default only the first account.
> > 
> > That's default behaviour to select the first record, I do not think it
> > will change.
> > 
> 
> For a report, this is not intuitive though perhaps a 'selection only' option 
> that limits output to what is
> selected on the screen could continue to provide current behaviour...

It is better to have always the same behaviour in the all application.
Any action applies on what is selected.

> But have you tried to select only used
> accounts (say 200-300) out of 1200 in e.g. the French accounting plan?

Use the filters.

> > > There seems to miss as well a means to be able to select only 
> > > non-reconciled entries (relative to the
> > > accounting year), which appears to be a crucial need expressed by 
> > > accountants and legal auditors.
> > 
> > I do not understand exactly what you mean. For me, there is no sense to
> > care about non-reconciled per fiscal year. Also I do not see the point
> > to care about them individually, we have the Aged Balance for that.
> > 
> 
> Balance is not interesting for this, although auxiliary balance/GL is also 
> necessary,
> what is expected is a GL *detailing* only non-reconciled entries, typically 
> for year-end
> (or periodic situation) closing.

What is the point? It is useless in Tryton because non-deferral lines
stay.

-- 
Cédric Krier - B2CK SPRL
Email/Jabber: cedric.kr...@b2ck.com
Tel: +32 472 54 46 59
Website: http://www.b2ck.com/

-- 
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/20161204113016.GE71015%40tetsuo.

Re: [tryton] Invoice Location

Re: [tryton] Invoice Location

Re: [tryton] Invoice Location

Re: [tryton] New Tryton installation

Re: [tryton] Invoice Location

Re: [tryton] Invoice Location

Re: [tryton] Invoice Location

Re: [tryton] Invoice Location

Re: [tryton] Re: version 4 GL & balance reports

9 matches

Site Navigation

Mail list logo

Footer information