tvl , коллега, давайте для начала смоделируем, чего же такое вы хотите сделать, какой такой инструмент, с каким функционалом и под какие процессы?

1. Кого вы представляете: производителя или дистрибьютора (явно не дилера)?
Либо вообще это что-то третье, типа биржи услуг для перечисленных категорий?

2. В Odoo вы можете завести на одном сервере отдельную БД для каждого собственника (компания или группа компаний), но в этом случае данные учета каждого собственника будут изолированы.

3. Задать режим multi-company и завести несколько компаний от разных собственников в одной БД можно, но нецелесообразно, поскольку admin будет иметь неограниченный доступ к информации всех компаний.

4. Можно создать БД для собственника группы компаний, например, сеть дистрибьюции. При этом компании группы могут работать с общим продакт каталогом (номенклатурой в терминах 1С) и/или общей клиентской базой. Клиентам можно открыть режим доступа к порталу, типа личного кабинета, где они смогут видеть свои заказы, взаиморасчеты.

Поясните, пожалуйста, ваш подход и потребности.

tvl , для добавления новых категорий через импорт, сначала экспортируйти весь список категорий или его часть в CSV.
При первом экспорте каждой категории будет присвоен еxternal ID типа __export__.product_category_3
Добавьте в файл строку с новой категорией, укажите для нее external ID родительской категории и заполните обязательные поля.
Если оставите поле id пустым или зададите отсутствующий в БД external ID, при импорте Odoo создаст новую категорию.
Сохраниете файл как CSV и импортируйте в Odoo.

aladkoi , нет, tenant — владелец базы данных, заказчик; т.е. в варианте multi-company — собственник группы компаний.

Multi-tenant — обслуживание одним сервером Odoo нескольких не связанных между собой заказчиков.

physics , кстати, на одном выделенном сервере можно одновременно поднять сервера Odoo разных версий, в прокси прописать передачу имени базы в качестве параметра нужному серверу.
Да, и не забудьте внести записи доменов третьего уровня в DNS :)

physics , ваша ситуация абсолютно штатная. Можно вести одновременно несколько проектов для разных заказчиков на одном арендованном сервере, при этом они друг друга не увидят.

Для этого используются домены третьего уровня, совпадающие с именами баз данных DBname1.mydomain.abc, перед Odoo настраивается прокси Nginx.
В конфигурационном файле Odoo нужно отключить выдачу списка БД и включтить режим «за прокси».

# DB filtering for multi-site instances
dbfilter = ^%d$
list_db = False

# Is it behind a HTTP reverse proxy?
proxy_mode = True

aladkoi , если я не ошибаюсь, после v6.1 параметр timezone в конфиге сервера игнорируется, Odoo оперирует в UTC, настройки TZ операционной системы не влияют. Все логично, вы в любой момент можете перебросить Odoo и/или PostgreSQL куда угодно по сети. Имеет значение только TZ пользователя.

aladkoi , возможно, я чего-то не допонял…
Тайм-зона прописывается для пользователя, данные в PostgreSQL хранятся в UTC, серверу Odoo зачем заморачиваться на его локальное время? Мало ли где он физически находится!

IRIP , эта проблема на форуме разбиралась, можно поискать.
Гугель не доверяет Odoo как клиентской программе.
В настройках эккаунта Гугла нужно прописать разрешение работать с недоверенными приложениями.

dskarataev , План счетов — это краеугольный камень, без него вообще не может быть учета на двойной записи. Журналы, главная книга, возможность сверки приходов на банковские счета и т.п. — должны присутствовать в любом движке фин. учета. А дальше начинаются пользовательские функции.

В восьмерке было иерархическое представление плана счетов и, если не ошибаюсь, можно было создать несколько иерархий, а для конкретной компании указать корень иерархии.
В девятке сделали гладкий список, отчего у бухгалтеров глаза округлились — им дерево подавай. В качестве компенсации ввели теги для группировки генеральных счетов в отчетах и привязка каждого счета конкретной компании.
В разы увеличили количество внутренних типов счетов, различаемых движком…
Все это уже обсуждалось.

Фабиен не зря сказал, мелкому бизнесу достаточно полуавтоматизированного инвойсинга, потому у вас проблем не возникает.

Среднему и крупному бизнесу, группе компаний в отсутствии готовых «вертикально-интегрированных» решений приходится запускать в Accounting финансового контролера и финансового менеджера (заметьте, не бухгалтера в нашем понимании), чтобы проводить транзакции вручную, настраивать аналитический учет, задачки типа рекурсивного выставления счетов по контрактам, собирать косты по проектам, налоги считать и много чего еще.

«В чем сила Odoo, брат?» ))
При условии правильно организованного учета и выполнении правил ВСЕМИ пользователями, Odoo может выдавать текущий реальный, а значит управленческий, балансовый отчет предприятия с погрешностью в пределах рабочего дня.

В российской действительность отчет по состоянию финансов для собственника бизнеса и топов консолидируется вручную по завершению периода с задержкой от недель до месяцев — пресловутый «посмертный учет» ((

В моем понимании, Фабиен всерьез нацеливает потенциальные крупные внедрения на EE.

dskarataev , Денис, все-таки я соглашусь OBEH и вот почему.

1. Важна сама по себе декларация Фабиена о маркетинговой стратегии Odoo SA.

2. Accounting переписывался при переходе на 9-ку, технологически один движок обеспечивает и Invoicing, и Accounting, но во втором случае потребитель получает доступ к расширенному фукнционалу для финансового менеджера.

3. По-видимому, архитекторы и технологи не успели за маркетологами и выпустили v11 с тем же движком, «скрыв» от потребителя расширенный функционал.

4. Пока не было времени и особой необходимости самому покрутить v11, надеюсь, найдется энтузиаст, который исследует вопрос на наличие возможных подводных камней в рецепте Фабиана.

5. Даже если Фабиан не лукавит, не факт, что движок финансового учета не будет переписан в v12.

OBEH (2018-01-26 15:14:07):

У меня просто рабочий комп с 32-разрядной Windows 7
Поэтому, как развести это все на одном компе пока не представляю.

Мдя-я-я, 32-Винда — сочувствую. Но это проблема, которую каждый решает сам, это за рамками тематики сайта.

Пара ядер и 2 Гб оперативки для старта Odoo под Linux без Иксов (GUI).

Уп-с, а почему вам на десктопе не сделать мультизагрузку и выделить кусок харда под Linux? Изящное решение ))

OBEH , ставьте несколько версий Odoo через git и настраивайте каждую как отдельный сервис. Через nginx и домены третьего уровня обращения к разным версиям очень хорошо разводятся.
И место хранения filestore и дополнительных addons сами определяете.
У меня на внешнем VPS крутятся v8 из репозитория и v9,10 из git.

OBEH , столько сразу проблем подняли, вижу наболело, не знаю на что отвечать :))

Для меня Odoo инструмент и как любой инструмент можно использовать по предназначению (замысел его творца) или «гвозди забивать».

Как употреблять инструмент — решает ЗАКАЗЧИК. И тогда вопрос: кто ваш заказчик?

Если это Производственный, Продажный или Логистический МЕНЕДЖЕР — зачем вам вообще заморачиваться на Accounting??? Billing'а за глаза хватит.

Каждому из них нужен ЧАСТИЧНЫЙ учет, к УПРАВЛЕНИЮ бизнесом в целом и предприятием в частности они прямого отношения не имеют!

А вот если ваш ЗАКАЗЧИК — Генеральный директор, а лучше ПРЕДПРИНИМАТЕЛЬ — СОБСТВЕННИК бизнеса, вот только тогда возникает тема УПРАВЛЕНЧЕСКОГО УЧЕТА, который дает полную картину финансового состояния предприятия или предприятий.

РСБУ как нормы учета разрабатывался государством и исключительно под нужды государства. Поэтому в РСБУ про УУ ничего нет. А поскольку 1С заточен под РСБУ, то по определению не ищите там УУ.

Насколько я знаю про употребление SAP в России, серьезные компании вынуждены реализовывать в этом инструменте два-три параллельных и независимых учета: «посмертный» под РСБУ как вынужденное зло (за такие деньги «западло» отдельно 1С поддерживать) и нормальный живой и проспективный Accounting под нужды бизнеса (УУ). Результаты отчетности, например по прибыли, могут различаться в разы ((

OBEH ,
кроме заморочек с технологией программирования в 11 версии измененили расклад функционала между CE и EE.
Если в 9 и 10 было примерно 90% на 10%,
то начиная с версии 11 будет 80% на 20%.
Заявлено, что стратегически из CE убрали Accounting, оставив Billing. Подробности здесь Fabien Pinckaers: Re:[Odoo 11 CE] Are Accounting Features Removed?!

В таком виде Odoo CE не устроит финансовых менеджеров и собственников бизнеса.

Odoo CE перестанет быть полноценным инструментом для Управленческого учета, а именно в этой нише в России лишь дорогие проприетарные продукты, не подъемные для малого и среднего бизнеса. 1С не предлагать :)

При этом Фабиеном высказана мысль, что фанаты Open Source могут компенсировать потерю использованием разработок OCA/account-financial-tools.

Интересно, найдутся у нас желающие копать в этом направлении?

Odoo ,
День добрый. Если поискать на форумах, можно найти обсуждения еще в приложении к v8. Но логика не изменилась.
Procurement (запасание) в Odoo регулириуется настройками для каждого продукта.

Параметр Product Type задает Odoo, следует ли при создании MO проверять наличие продукта (тип Stockable) или считаем, что на складе его всегда достаточно (т.е. про это у закупца должна голова болеть).

При недостатке продукта-компонента типа Stockable, Odoo выделяет позицию красным и устанавливает статус в «ожидание поступления».
Другая линия поведения Odoo, если у вас задан для компонента Route «купить» или «произвести» в сочетании с галкой в «Make to order». В этом случае Odoo создает заказ PO или MO на количество, в точном соответствии в производственным заказом, независимо, есть ли этот компонент на складе и сколько.
С чем, собственно вы и столкнулись.

AndyZotov , посмотрите приложение для Odoo OpenEduCat
Там есть ссылка на сайт разработчика с предложением демо с разными планами: от небольшой школы до университета.

straga ,
тем, кто не хочет заморачиваться на разработку кода, рекомендую готовую утилиту odoo_csv_import от tfrancoi на Github.

Плюсы: может резать исходный csv на пакеты, отказные записи/пакеты пишет в выходной csv, запускает несколько worker'ов, распараллеливая процесс.

Dimav , здравствуйте.

Немного сбивает с толку терминология финансовых рынков «MIO» как аббревиатура «millions», здесь было бы понятнее «9M позиций».

По существу. В качестве СУБД Odoo штатно использует PostgreSQL. Возможности и рекомендации по объемам обрабатываемых данных смотрите на сайте https://www.postgresql.org/about/.

Узкое место будет с импортом данных (первичный и обновления). Odoo обрабатывает пакет данных по одной записи, проверяет корректность и целостность, и, в случае обнаружения проблем, отклоняет весь пакет. Поэтому рекомендуется использовать внешние утилиты, нарезающие массив вводимых данных на пакеты по 50-500 записей и запускающих на каждый пакет сессию по xmlrpc.

Можно, конечно, минуя Odoo залить массив данных напрямую в PostgreSQL, но это уже тонкая хирургическая операция, если будет нарушена целостность данных, Odoo ни за что не отвечает :-)

Одна и возможностей оптимизации — при большом числе конкурентных сессий разнести серверы Odoo и СУБД на разные физические или виртуальные машины.

В общем, при проектировании решения, нужно корректно посчитать необходимые ресурсы и выбрать подходящую архитектуру.

А дальше нужно обсуждать детали вашего проекта.

abzhan ,

Совет: для начала смоделируйте автоматизированный расчет в Excel с сохранением в csv и импортом данных спецификации в Odoo.

Поработайте, если получится сделать для всех случаев, под любой заказ, считайте, что вы готовы сформулировать ТЗ на программирование модуля в Odoo.

Причем собственные процессы Odoo вы не затроните, добавите новую/отдельную функцию для конструктора.
Сейчас Odoo не заморачивается, как конструктор или технолог творят спецификации, главное, чтобы ввели их.