Invoice Location

[Carlos Eduardo Sotelo Pinto]

Hello People

I am working on a location for the invoice module. I refer to peruivian location, and I have this issue:

We have two kind of out invoices on the printing, but accountant behavior is the same, however the party customer is different

- Comercial Invoice (FACTURA), just for Companies
- Simple Invoice (BOLETA DE VENTA), just for Non Companies

Both of the aaplyes the same taxes, however on the Simple Invoice, is no necesary to specify the tax ammount.

Refered to Party, since on Tryton have Identifiers, is no necesary to manage identifiers, however, bahavior is no the same, since on this way on manage indentifiers, let the prty manage more than once, however, party just have once identifier, legal identifiers are:

* 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

ID 6 Is just for Companies, then Comercial INvoices are just for them


Until now, on a  previous locale version, I have been working on this way:

- Just one invoice, two different reports, and m,anage indentifiers using tryton identifiers. The main issue, any kind of customer could have invoice or simple invoice, and make some errors on the people who will operate the erp, then I thinking on changing the design

Any suggest?

Best regards

-

My ER Diagram is attached,

​

--

Carlos Eduardo Sotelo Pinto
    Senior Software Developer

    Claro RPC +51 989550602

    GTalk: carlos.so...@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

[Cédric Krier]

On 2016-12-03 08:51, Carlos Eduardo Sotelo Pinto wrote:
> Hello People
>
> I am working on a location for the invoice module. I refer to peruivian
> location, and I have this issue:
>
> We have two kind of out invoices on the printing, but accountant behavior
> is the same, however the party customer is different
>
> - Comercial Invoice (FACTURA), just for Companies
> - Simple Invoice (BOLETA DE VENTA), just for Non Companies
>
> Both of the aaplyes the same taxes, however on the Simple Invoice, is no
> necesary to specify the tax ammount.
>

> Refered to Party, since on Tryton have *Identifiers*, is no necesary to

> manage identifiers, however, bahavior is no the same, since on this way on
> manage indentifiers, let the prty manage more than once, however, party
> just have once identifier, legal identifiers are:
>
> * 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
>
>
> ID 6 Is just for Companies, then Comercial INvoices are just for them
>
>
> Until now, on a previous locale version, I have been working on this way:
>
> - Just one invoice, two different reports, and m,anage indentifiers using
> tryton identifiers. The main issue, any kind of customer could have invoice
> or simple invoice, and make some errors on the people who will operate the
> erp, then I thinking on changing the design
>
> Any suggest?

You did not describe what are the differences between both types of
invoices except that tax amount is not necessary but I guess having it
it not a problem.

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

[Carlos Eduardo Sotelo Pinto]

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.

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

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?

What I need is to make a diference related to the party bases on the Party Type of identifier. Parties provide a many to many relation ship for identifiers, but I need a many to one relationshiop.

A common ER Diagram used for invoicing software is like the provided on my attachment, where a party dependence based on the id document type could be used. Finaly the invoice type  ( or invoice document type ) could be restricted based on the party document type, that is what I am looking for.

My question is about a suggest in order to do a right locale custommization, since I will let this module as free for the comunity, and I am interested on maked it as much as as posisble as trytonic could be done.

I have done some invoicing modules as explained on before, that make no sense for the final users, and I countinue making maintenance, but this build as a gpl module, musty be tested and 100% trytron

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/20161204022554.GD52356%40tetsuo.

[Carlos Eduardo Sotelo Pinto]

List

Summarizing, about invoicing on peru.

- There is two kind of invoices: Invoice and Simple Invoice

- There is no difference on accounting or tax policies for both types

- Differences on both invoices are based on make a restriction refered to the Party Type or party Identifier [ Companies and No Companies ]

- Each invoice type have different printying document

Best regards

[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.

[Carlos Eduardo Sotelo Pinto]

Hi Cedrik

2016-12-04 6:34 GMT-05:00 Cédric Krier <cedric...@b2ck.com>:

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...@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.

[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 <cedric...@b2ck.com>:
>
> > 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.

[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.

[Carlos Eduardo Sotelo Pinto]

--
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 document codification with the number of the document ( the document or party identifier ) must be unique and propably ( just a suggestion ) the primary key.

-- 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.

Invoices
========

​ - Based on the before point, commercial or current invoice ( I call it Commercial Invoice ) must be generated just for customer parties with Identiffier Document Code "6" ( Companies ) other wise, just simple invoice.

- Invoice types must be coded on this way ( and reported on the same way to the tax authority ):

​ 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

​

-- Tryton just manage one invoice out named Invoice, although the current invoice layout works ok, and looks like a printing requirement, tax authority doesn¡'t approve it since dont have this restriction

** Comercial Invoice must be generated just for Companies and no more

** Simple Invoice must be generated for Non companies

** Tryton invoice doesnt have the code required for the tax autority

A ER Diagram suggested is attached


​

​There are extra requirements based on type on invoice generated

- Manual. Printing a common document like the tryton document. Secuences are like:

  * Comercial Invoice: 999-99999
  * Simple Invoice: 999-99999

- Invoicer gateqway. No document must be printed, and it uses a gate way to prepare the documentas a midle interfaz before sent the document to the tax autority. Sequeneces are like:

  * Comercial Invoice: FF99-99999
  * Simple Invoice: BB99-99999

- Electronic​. No document must be printed, and it comunicated directly to the tax autority to repot innvoice emision. Sequences are like

  * Comercial Invoice: EE99-99999
  * Simple Invoice: EE99-99999

​This would be part of two extra modules athta I am designing

- account_invoice_pe            : main invoice locale invoicing, on current development

- account_invoice_invoicer_pe   : using the invoicer gateway, using the still on design
- account_invoice_electronic_pe : using the electronic gateway, still on design​

​Best regards​

[Carlos Eduardo Sotelo Pinto]

Hello List, Raimon

2016-12-04 12:15 GMT-05:00 Raimon Esteve <raimon...@gmail.com>:

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

[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.

[Carlos Eduardo Sotelo Pinto]

Hello

2016-12-04 20:39 GMT-05:00 Cédric Krier <cedric...@b2ck.com>:

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 have never said that!!!

What I have said is , there is no a way to manage indetifiers on this way:

- a Code

- a Description name

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​

If identifiers has no a way to manage identifiers on this way, then software doesnt work. just that, simple, since repots need that codification, reports dont need names, reports need the Code on Reports

But is no legal having this:

- Many identifiers per party, this screen was observed. I have fixed it on the implementartion, but on custom modules, anyway, the software doesnt fill restrictions.

​

 

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.

​Yes you are right!! but users, if the user makes a mistake, could get into a legal issue and get more than USD 1000.00 on penalties for a user mistake ( sometimes is no a mistake and the company would like to avoid any kind of mistake as possible )​ Again, I have soled this issue on custom modules, hidden identifiers and create a selection field, that runs for me, my customer and tax autgority with mnking issues.

The reason on asking here is, I am designing a trytonic module in order on solve this issue on a trytonic way without breaking tryton design or rules , or guidelines for make this module free to the comunity.

After review requirements and some extra local erps and invoicing software, I have done that ER diagram, since it is accoording to the tax authority

Best regards

 

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

--
Cédric Krier - B2CK SPRL
Email/Jabber: cedric...@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.

[Cédric Krier]

On 2016-12-05 05:15, Carlos Eduardo Sotelo Pinto wrote:
> Hello
>
> 2016-12-04 20:39 GMT-05:00 Cédric Krier <cedric...@b2ck.com>:
>
> > 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 have never said that!!!
>
> What I have said is , there is no a way to manage indetifiers on this way:
>
> - a Code
> - a Description name
>

> *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​
>
> If identifiers has no a way to manage identifiers on this way, then
> software doesnt work. just that, simple, since repots need that

> codification, reports dont need names, reports need the *Code on Reports*

>
> But is no legal having this:
>
> - Many identifiers per party, this screen was observed. I have fixed it on
> the implementartion, but on custom modules, anyway, the software doesnt
> fill restrictions.

So you actually said it and I can not believe it.

>
> > 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.
> >
> >
>
> ​Yes you are right!! but users, if the user makes a mistake, could get into
> a legal issue and get more than USD 1000.00 on penalties for a user mistake
> ( sometimes is no a mistake and the company would like to avoid any kind of
> mistake as possible )​

Just like any mistakes a user can do. Software can not correct mistakes.

> Again, I have soled this issue on custom modules,

I do not understand "soled".

> hidden identifiers and create a selection field, that runs for me, my
> customer and tax autgority with mnking issues.

I do not understand "mnking".

> The reason on asking here is, I am designing a trytonic module in order on
> solve this issue on a trytonic way without breaking tryton design or rules
> , or guidelines for make this module free to the comunity.

I can not give any advise because the requirements described are not
clear nor complete.

[Fernando Sánchez]

Hello carlos
Is not very correct that in Peru a physical person should have only one identifier, I have dni and ruc just like you. And it is also not correct to say that only one company can request the receipt with code "01 FACTURA". In LiberOrbis we are also working in the Peruvian accounting and fiscal location of tryton and we did not have the problem that you indicate. If the customer (company or not) has ID code equal to 6 (RUC) tryton automatically choose the payment receipt with code "01 FACTURA" otherwise "03 BOLETA DE VENTA"

Greetings

Fernando Sanchez
LiberOrbis

[Carlos Eduardo Sotelo Pinto]

Sorry for the typewritting mistakes

​I understand that functionlity is ok, however doesnt full the full structure.

- Identifiers on Tryton are just [Type, Name] and let more than one identifier.
  It looks like a many to many relation ship

​- ​I nned something to [Code, Description] closed list but the identifiers, yes, a list for it for chose one from the list and no more than the list, like a one to many relation ship.

Yes, this is a requirement from the tax authority

- Each party must have one, nad no more than one identifier choosen from the list provided

Requirement from my customers

- Let the admin or the user responsible on register customers to choose more than one identifier, could make this user get into mistakes, related to regitration with multiple identifier, they prefer just a simple list to chose one of the list provided by the tax authority

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​

>

> > 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.
> >
> >
>
> ​Yes you are right!! but users, if the user makes a mistake, could get into
> a legal issue and get more than USD 1000.00 on penalties for a user mistake
> ( sometimes is no a mistake and the company would like to avoid any kind of
> mistake as possible )​

Just like any mistakes a user can do. Software can not correct mistakes.

​Yes, but It is possible to ​reduce de probability on make mistakes, at least on our requirements

 

> Again, I have soled this issue on custom modules,

I do not understand "soled".

​
I mean, ​on older customers, I have solved this issue hidden the identifiers seccion and adding a Selecction Box with the requirements list, and one more textbox for the number of the identification document.

That solution worked for me and my customers, and filled tax authority requirements

Question: If I have solved this issue, whay I am asking here? well I am building a module that I would like been compatible with tryton comunity guidelines in order on let this module as free and open for the comunity

Best regards

> hidden identifiers and create a selection field, that runs for me, my
> customer and tax autgority with mnking issues.

I do not understand "mnking".

> The reason on asking here is, I am designing a trytonic module in order on
> solve this issue on a trytonic way without breaking tryton design or rules
> , or guidelines for make this module free to the comunity.

I can not give any advise because the requirements described are not
clear nor complete.

--
Cédric Krier - B2CK SPRL
Email/Jabber: cedric...@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/20161205105336.GO71015%40tetsuo.

[Cédric Krier]

On 2016-12-05 09:53, Carlos Eduardo Sotelo Pinto wrote:
> Question: If I have solved this issue, whay I am asking here? well I am
> building a module that I would like been compatible with tryton comunity
> guidelines in order on let this module as free and open for the comunity

OK, I will just answer this because others point have already been
answered.
No you did not, the Tryton way is using identifier and unicity
constraint is almost never good. As Fernando pointed there is always
exceptions. Also it is not a matter of unicity but validity, if you want
to prevent user from mistakes, you must validate the input so he can not
invent a wrong number.

[Carlos Eduardo Sotelo Pinto]

Hi Fernando

According with the "Facturacion Electronica" and "Libros Electronicos" is yes, is a request, I was two weeks ago with the accountant checking that, also with a lawyer, and said that. That is the reason.

About having a RUC and DNI, well, for tax Authority are two different people

- With DNI is a common person, and Boleta is just the document required

- With RUC is a company,

Is no legal having both as identifiers. I have checked it with a lawyer

I am trying to make this according the tryton way since I am looking for make this module free and open, and could be good for all peruavian people working with tryton on Peru

best reagrds

--
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/007db495-3443-4ebb-a943-827b1c2d5f76%40googlegroups.com.

[Carlos Eduardo Sotelo Pinto]

--
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/20161205154213.GR71015%40tetsuo.

​Ok

Sounds better

About the invoicing, I have noticed something similar, and more complex on Argentina.

I will been completeing it this end of month and waiting for libertate these modules firth day of 2017 and get the tryton community approval.

best regards ​

[Sergi Almacellas Abellana]

Hello Carlos,

El 05/12/16 a les 11:15, Carlos Eduardo Sotelo Pinto ha escrit:

>
> What I have said is , there is no a way to manage indetifiers on this way:
>
> - a Code
> - a Description name
>

> *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​
>
> If identifiers has no a way to manage identifiers on this way, then
> software doesnt work. just that, simple, since repots need that

> codification, reports dont need names, reports need the *Code on Reports*

>
> But is no legal having this:
>
> - Many identifiers per party, this screen was observed. I have fixed it
> on the implementartion, but on custom modules, anyway, the software
> doesnt fill restrictions.
>

If you need to fill this requirements, you can add the Peruvian VAT as
custom type on the selection, and then add a new field (requied and only
visible for the peruvian Vat) to indicate the type. This new field can
be a many2one to a new model with code and description.

For the identifier uniqueness, you can add a check on identifier that
checks on creation/modification of an identifer that does not exist
another peruvian_vat for the party and raise and error (or maybe a
warning) if it exists.

Hope it helps.

--
Sergi Almacellas Abellana
www.koolpi.com
Twitter: @pokoli_srk