Sales

Yes. CRM tracks leads and opportunities, Sales produces quotations and orders; the two can be installed separately. When you use them together, you create a quotation directly from the opportunity screen, and the quotation amount is reflected in the opportunity's expected revenue. In most setups both are switched on, because the process runs from the lead record to the order without a break.

CRM, Sales, Point of Sale, Restaurant and Contacts are available in the Community edition as well, and you can go ahead on Community with those five. Subscriptions is Enterprise-only. Before the setup, ASON lists which application is in which edition.

The decision depends on whether you need subscriptions and on other Enterprise modules such as Accounting and Studio. If you will only track leads and produce quotations, orders and register sales, all those steps sit within the Community scope. If you need recurring invoicing, the edition decision follows from the Subscriptions app being in Enterprise.

No. You can start with CRM and Sales and add Point of Sale or Subscriptions at a later stage. Because the apps run in the same database, an app added later uses the existing customer and product records as they are. Which app is switched on at which stage is set in the rollout plan.

Data such as customers, products, pricelists, open orders and account balances is moved through Odoo's import interface or its XML-RPC interface. The files taken from the source system are mapped to the fields in Odoo. If the source data is untidy, a cleaning step is added before the transfer.

The transfer is made into a test database first. Record counts and totals are compared with the source system; if there is a difference, the mapping is corrected and the transfer is repeated. Any untidiness in the source data also shows up at this stage, and the cleaning step is planned accordingly. Once the result is verified, the same steps are run on the live database.

Yes. The invoice is issued in Odoo, produced in the format of GİB (Türkiye's revenue administration), sent to the integrator, and the document's status is written back into Odoo. e-İrsaliye goes the same way and is prepared on the delivery order. The e-Defter file is produced in Odoo and downloaded. The localization also brings the Turkish chart of accounts and the tax definitions.

Buyers registered with GİB get an e-Fatura; buyers who are not registered, and exports, get an e-Arşiv. Odoo makes that distinction itself from the buyer's GİB registration — your sales team picks nothing extra. Which document types will be enabled is settled with the integrator at the start of the project.

First we map your current sales process: which step sits with whom, and where each document is produced. Then the configuration and the data transfer are done in a test database. Which app is switched on at which stage is part of the same plan. Once the process is verified, it goes live and the configuration changes that are made are recorded.

Training is given to the user groups on a role basis; each group works through the screens it actually uses. Support is provided after the installation, and the configuration changes made in that period are recorded.

In the flow from order to invoice, e-Fatura and e-Arşiv are sent from Odoo. On the payment and shipping side, connections specific to Türkiye are set up with third-party modules; which bank or provider is used is decided within the project. These modules are not covered by Odoo S.A. support, so before the choice we evaluate the publisher's maintenance continuity together.