gestinux quotes

[nomorelogic]

hi all
I've a question about quotes in gestinux.

You know, I come from Italy and and I need a "commercial" translation.
In menù [ Ventes (fr) | Sales (en) ], I can found item [ Devis (fr) | Quotes (en) ], and I traslate this last item in (it) "Ordini da clienti".

Now: I know (it) "Ordini da cliente" can be translated in (en) "Customer Orders".
Instead of (en) "Orders", here I found the (en) "Quotes" and, once inserted a record, I can't modify this one: this confuses me.
Why I can't modify a customer order? This is very strange to me.

So: do (en) "Quotes" = (fr) Devis = (it) "Ordini da clienti"?
If Quotes=Devis=Ordini: why an inserted order became read only?

thanks
nomorelogic

[tintinux]

Hi

Quotes in english and Devis in french are I think Preventivo in Italiano.
Currently, Gestinux do not make orders, only quotes and invoices.

I was planning them in the next version in a few months but currently i'm a little busy in other areas. If someone is more available, he is welcome.
A basic ordering should be very easy to develop, because there are already a unit and a form designed to be common to all sales documents.
These are overriden by more specific objects to make quotes and invoices, and it should be trivial to duplicate and turn quotes to orders (and to delivery bills also).
Of course, more complex features might be useful in relation with ordering. Stock management is one of them, and many enterprises have rather specific processes to order.

For information, I have also made a php script to store orders and invoices on internet, compatible with Gestinux which can be used afterwards for the backoffice.

If you create a Quote or an invoice with the current version of Gestinux and use only the "Save" button, it is certainly possible to update it later.
However the "Validate" a button (on the right bottom) makes the documents read-only.
For invoices it is necessary : after a transfer to accounting an invoice should never be altered. It is possible to make a credit note (negative invoice)
For quotes, I think it is useful to forbid changes once you have sent it to the customer, but this is not required.

Hope this helps
Regards

Tintinux

[nomorelogic]

I was planning them in the next version in a few months but currently i'm a little busy in other areas. If someone is more available, he is welcome.
...
A basic ordering should be very easy to develop, because there are already a unit and a form designed to be common to all sales documents.
These are overriden by more specific objects to make quotes and invoices, and it should be trivial to duplicate and turn quotes to orders (and to delivery bills also).
Of course, more complex features might be useful in relation with ordering. Stock management is one of them, and many enterprises have rather specific processes to order.

First of all, thanks for you time and forgive me for my questions: I'ts first time for me to compare my knoledge with an international product
I need to study more time

[nomorelogic]

...
Currently, Gestinux do not make orders, only quotes and invoices.
...
I was planning them in the next version in a few months but currently i'm a little busy in other areas. If someone is more available, he is welcome.
A basic ordering should be very easy to develop, because there are already a unit and a form designed to be common to all sales documents.
These are overriden by more specific objects to make quotes and invoices, and it should be trivial to duplicate and turn quotes to orders (and to delivery bills also).
Of course, more complex features might be useful in relation with ordering. Stock management is one of them, and many enterprises have rather specific processes to order.

Hi
I looked a bit in sources and into database structure, in effect should not be complicated to implement orders.
I tried to imagine an implementation for orders and, simultaneously, a stock management.

I used PlantUml to try to describe what I had in mind: following the code (paste content in http://www.plantuml.com/plantuml/) you can find two new tables (StockMovementType and DocumentType) through which, all document types can be stored in a single master table/detail.

Code: Select all

    @startuml

    class StockMovementTypes << (T,#FF7700) database table >> {
      .. primary key ..
      + id: integer
      .. fields ..
      + Name: varchar 35
      Item description
      + HolderType: varchar 1
      flag document holder, possible values:
      Customer, Supplier, None (internal document)
      + ValueType varchar 1
      It identifies what type of value must be updated
      Purcharsed, Loads, Sold, Unloads, Orders, Commitments 
      + StockQuantityOperator: varchar 1
      Operator to use to update stock quantity
      possible values:
      "+" increases / "-" decreases / "=" set to value
      " " no operation required
      + SalesOrdersQuantityOperator: varchar 1
      Operator to use to update commitments quantity
      (used in customer orders)
      possible values:
      "+" increases / "-" decreases / "=" set to value
      " " no operation required
      + PurchaseOrdersQuantityOperator: varchar 1
      Operator to use to update commitments quantity
      (used in supplier orders)
      possible values:
      "+" increases / "-" decreases / "=" set to value
      " " no operation required
      + TriggeredSMTid: integer
      Triggered StockMovementTypeId
      used for double movements (i.e. internal transfers)
    }

    class Stores << (T,#FF7700) database table >> {
      .. primary key ..
      + id: integer
      .. fields ..
      + Name: varchar 35
      Item description
      .. address ..
      fields for address
    }


    class DocumentType << (T,#FF7700) database table >> {
      .. primary key ..
      + id: integer
      .. stock management fields ..
      + Name: varchar 35
      Item description
      + HolderType: varchar 1
      flag document holder, possible values:
      Customer, Supplier, None (internal document)
      matches StockMovementTypes.HolderType
      + FlagIssuedReceived: varchar 1
      flag document issued or received, possible values:
      Issued, Received
      + DocumentClass
      class of document, possible values:
      IN=Invoice, CN=Credit Note, PO=POS, TD=Transport Document,
      RC=Receipt, ID=Internal Document
      + StockMovementType
      + StoreId
      + TriggeredStoreId
      store to apply StockMovementTypes.TriggeredSMTid
      used only wher required
      .. document fields ..
      + GeneratorId
      when null, number can be entered fro muser
      when not null, number is calculated from generator
      + Alfa
      + TariffId
    }
     
    DocumentType --> Stores: StoreId
    DocumentType --> Stores: TriggeredStoreId
    DocumentType --> StockMovementTypes: StockMovementTypes
    @enduml

Using SQL JOINS we can calculate the inventory.
It 'an idea to expand but I want to share with you, to find out if it can be useful for Gestinux.


Best regards
nomorelogic

[tintinux]

Hi

You are welcome to work in the ordering and stock area !

Here is what I could say and explain :

I have considered for a long time the advantages and drawbacks of having distinct database tables for different document types (quotes, invoices, orders...) versus having a common table with a DocumentType field in the first one.
My conclusion was to create, as you can see, different tables for quotes and invoices, and for other types of documents in the future.
The main reasons was :

• most ERP I have used are working this way
• avoid impacting stable processes when developing a new one.
• avoid too big tables
• avoid useless or NULL columns required only by some document type
• easier referential integrity constraints
• easier data import

But I realize there are good reasons to choose the other way...
However, since it was started like this, I would prefer to go on and not to change everyting.

Fields should have the same name in similar documents when possible to simplify usage of common programmatic objects.
Unfortunately they have often not currently the same name because the initial choices were wrong (ex: InvoiceId was created first, and found not suitable to identify Quotes).
May be in the future we could change the Invoice field names, but this is not easy.
For now, the right field names to use when possible are those of Quotes.

I would suggest to try to populate the stock movement table by triggers on OrderLines or DeliveryBillLines.
The stock quantity could be either stored by triggers on stock movements, or recomputed from stock movements every time it is displayed (it is used to be very quick).
A new tabsheet in article will have to be created to display stocks in different stores.
A StockManagement column will be useful in Product table.
A form to make stock transfers and adjustments will have to be created.
Since you have the good idea to record stock by store, you may have to select the store when ordering and delivering.
It would be a good idea to suppress the choice when the product is available in only one store.

So you have a lot of work !

NoMoreLogic sourceforge account is now developper in Gestinux Project (I hope it is you !)

Best regards
Tintinux

[nomorelogic]

...
So you have a lot of work !
NoMoreLogic sourceforge account is now developper in Gestinux Project (I hope it is you !)
...

Yes, it seems I have a lot of work to do.
For sure you know how to not traumatize people

Now I will start the last file translation (util) and in the meantime I will clarify my ideas about orders. Clearly I come back to talk about how to implement things (such as triggers or views, in a multi-database application, requires an alignment system between the different SQL syntax).

Best regards
nomorelogic

PS: Yes, NoMoreLogic sourceforge account is me.