2016-12-04 10:39 GMT-05:00 Cédric Krier <[email protected]>:
> On 2016-12-04 07:29, Carlos Eduardo Sotelo Pinto wrote:
> > Hi Cedrik
> >
> > 2016-12-04 6:34 GMT-05:00 Cédric Krier <[email protected]>:
> >
> > > 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: [email protected]
> 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 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
Senior Software Developer
Claro RPC +51 989550602
GTalk: [email protected] | 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_7W5wOhW%3DCcY%3Dab-d%2ByHhKDUGhwfx392yzpCoTSm9PUg%40mail.gmail.com.
