Примеров хочется больше. Реальной работы. Например меня очень интересует розничная продажа с учетом товара на складе. Сейчас пользуюсь 1С УТ. Но количество магазинов начало расти и синхронизация между ними начала доставлять большую головную боль. Понравилось Odoo, но нет практических примеров.
Если вкратце, то когда я пытался в домен [('id','in', get_vendcontact_ids)] подставить значение поля типа Many2many, то для системы это выглядело вот таким образом: [('id','in', [(6,0,[ID1,ID2,ID3])])], что приводило к ошибке. Чтобы корректно сформировать домен в этом случае нужно писать так: [('id','in', get_vendcontact_ids and get_vendcontact_ids[0][2])]
Для моего случая понадобилось вычисляемое поле Many2many, куда будут записываться нужные id:
И вот так должно выглядеть определение поля, где можно выбрать контакт только из отфильтрованного списка:
vendcontact_id = fields.Many2one('my.contact', 'Контакт поставщика', domain="[('id','in', get_vendcontact_ids and get_vendcontact_ids[0][2])]")
Уже работает. Для полноты картины еще понадобится на OnChange поля «Поставщик» привесить обновление нашего вычисляемого поля и корректное изменение значения связанного лукапа:
@api.onchange('vendor_id')
def onchange_vendor(self):
if self.vendor_id:
vendor_contact_ids = self.vendor_id.contact_ids.mapped('id')
self.get_vendcontact_ids = self.vendor_id.contact_ids.mapped('id') # Обновление списка id для домена
# Очистить поле с контактом, если он не принадлежит выбранному поставщику
if self.vendcontact_id and self.vendcontact_id not in vendor_contact_ids:
self.vendcontact_id = None
else:
self.get_vendcontact_ids = None
self.vendcontact_id = None
nodes = doc.xpath("//field[@name='order_line']/form//field[@name='product_id']")
for node in nodes:
node.set('context', "{'partner_id':parent.partner_id,}")
Я правильно понимаю, что в контексте нужно передать идентификатор? Если так, то я не могу найти способ добраться до значений полей текущей записи при открытии формы.
Нужно в fields_view_get для модели где нужен custom lookup добавлять, что-то вроде node.set('context', "{'looluppartner_id':partner_id.id,}")
X
А в самой модели res.partner — переопределить метод search. Который в случаи наличия в контексте ('looluppartner_id')
будет фильтровать вывод search.
Но тут появляется проблема с типом этого поля. В случае, если это one2Many и он заполнен какими-то id контактов, то при нажатии кнопки лукапа появляется ошибка: TypeError: not all arguments converted during string formatting.
Работающий вариант получился только в комбинации: поле типа Char и в нем только один id контакта — тогда домен накладывается успешно.
Если в поле Char пытаться указать несколько id, например «4, 3», то появляется ошибка:
DataError: ОШИБКА: неверное значение для целого числа: «4, 3»
LINE 1: ...t".«active» = true) AND («my_contact».«id» in ('4, 3'))) ...
Есть fields_view_get(), но внутри него мне так и не удалось добраться до значений полей текущей записи:
def fields_view_get(self, cr, user, view_id=None, view_type='form', context=None, toolbar=False, submenu=False):
if context is None:
context = {}
res = super(my.agreement, self).fields_view_get(cr, user, view_id, view_type, context, toolbar=toolbar, submenu=submenu)
if view_type == 'form':
active_id = self.env.context.get('active_id', False) # <-- Падает тут, говорит, что нет env
vendor = self.env['my.agreement'].browse(active_id).vendor_id
vendor_contact_ids = self.vendor_id.contact_ids.mapped('id')
for field in res['fields']:
if field == 'vendcontact_id':
res['fields'][field]['domain'] = [('id', 'in', vendor_contact_ids)]
return res
Дмитрий, поверьте, как только вы наладите закупку и хранение в штуках, генеральный менеджер (особенно если он же собственник) захочет знать стоимость запасов.
Для формирования цены на изделия потребуется себестоимость. Odoo может посчитать прямые затраты на изделие по спецификации и технологическому маршруту.
Поскольку закупки комплектующих производятся партиями и не обязательно по одной цене, нужно будет посчитать остатки по среднему. Odoo это делает.
В общем, лучше, если заказчиком на Odoo как инструмент операционного и финансового менеджмента будет Первое лицо.
Организация не большая, поэтому роль закупщика и кладовщика выполняет один человек, а без менеджера как-то обходимся. В финансовых вопросах я плохо разбираюсь и меня больше волнует производство. Я конечно надеюсь убедить руководство использовать Оду для финансов, но пока нам бы склад перевести на нее. Начальство вообще планировало заказать разработку программы для склада, но я стараюсь убедить, что это долго и дорого при том, что есть готовые решения.
Наверное термин запасание здесь больше подходит. Суть в том, что нам надо обеспечить наличие всех компонентов для производства.
Т.е. заказчиком является даже не «закупец» и не производственный менеджер, а кладовщик?
Или все-таки нужен не «склад» (Inventory == опись), а «запасание» для производства.
И еще ремарка: «себестоимость» по Закону о бух.учете и по Налоговому кодексу разные. А для менеджмента она будет третьей. 1С хорошо считает налоги, а вот для финансового менеджмента Odoo куда лучше подходит.
У нас в организации в первую очередь стоит проблема складского учета. Сейчас он ведется в экселевском файле, при чем не совсем продуманном, и мы замечаем, что чего-то не хватает, когда уже начата сборка устройства. Это видео нужно для специалиста, который заведует складом. Проблема себестоимости тоже есть. Но денежные вопросы пока решаются в 1с бухгалтерии.
Спасибо за наводку, мы только начинаем осваивать эту программу.
Понимаю условность короткого демо-ролика, он, конечно, не «про жизнь», а про то как выглядит в Odoo натуральный (в штуках) учет запасов.
Сразу вопрос: а для каких коллег это видео, целевая аудитория? Потенциальным пользователям-специалистам или все-таки топ-менеджменту.
Последним должно быть интересно как раз то, что вы упомянули вскользь — учет в деньгаХ, пополнение запасов через эти самые purchases (закупки), и то, чего не коснулись совсем — считание себестоимости (costs) произведенной / проданной продукции.
Отдельный демо-ролик рекомендую сделать по функции «запасания» (Procurements) — это для производственного предприятия вообще может стать центром, вокруг которого выстраивается операционный менеджмент. Здесь и правила автоматического пополнения запасов, запуск Purchase и Manufacture ордеров. С этим стоит повозится. Здесь неизбежно придется обсуждать и фиксировать и даже изменять (!) политики предприятия.
Смею высказать предположение, почему эта тема висит уже два года.
С моей «кочки зрения» изначальное предположение, что задача обмена данными Odoo > 1C и обратно исключительно техническая есть серьезное заблуждение,
которое может съест уйму времени и средств.
Если вы полагаете, что найдется какой-нибудь очень главный бухгалтер, из которого вы сможете под это вынуть ТЗ,
боюсь время будет потрачено зря.
Дело в том, что это не ЗАДАЧА, а ПРОБЛЕМА, однозначного решения не имеющая.
Accounting (по GAAP и IFRS) с Российским бухучетом не стыкуются по принципу.
Точнее, по базовым принципам.
Здесь как в анекдоте:
— Назовите десять причин, почему батарея не поддержала наступление огнем?
— Во-первых не было снарядов…
В Российской бухгалтерии принимаются к учету (строго!) операции, подтвержденные документами. Нет документа — нет операции!
Это понятно, поскольку у бухучета нет другой цели, как начисление и своевременная оплата налогов государству. И все!!!
В Accounting'е и, следовательно в Odoo, наличие бумажек, не скажу необязательно, но сильно вторично.
Здесь важна сама операция, её экономический смысл, а далее наличие ресурсов и в целом финансовое состояния бизнеса.
Accounting нужен в первую очередь менеджменту, потом владельцу / акционерам, в-третьих, для расчета налогов.
[Следствие: не переводите «invoice» как «счет-фактура».
И вообще, не спешите менять английские понятия на термины из РСБУ.]
Погуглите в российском интернете по поводу конвертации отчетности из РСБУ в МСФО и наоборот,
проблема не решена ни на уровне мэпирования операций,
ни на уровне трансляции финансовых отчетов.
Разброс экономических результатов может составить более 50%.
Гипотетически эксперты полагают выходом совмещение в одном продукте двух параллельных учетов — МСФО и РСБУ.
На создание такого монстра, насколько мне известно, никто не замахивался.
А потому, пока у нас не откажутся от постсоциалистической «бухгалтерии народного хозяйства»,
предпринимателям и менеджменту не обойтись без параллельного ведения «капиталистического» управленческого учета
в отдельном инструменте — если не в Odoo, так по старинке в Excel.
Но лучше все-таки в Odoo, чтобы не изобретать велосипед.
А попутное освоение принципов и норм «капиталистического учета», поверьте, будет сильно полезно и предпринимателям, и генеральным менеджерам.
P.S. Задачки для программистов, типа загрузки выписок из банка в Odoo, конечно же остаются.
Добрый вечер.
По ТЗ, уже есть какие-нибудь наработки?
Моя компания только начала начала заниматься внедрением odoo, но необходимость модуля обмена данными с 1С Бухгалтерией уже видим. Считаю что краудфайдингом заниматься необходимо не на этом ресурсе, маловероятно что тут есть люди, готовые вложиться суммой 500 000, к тому-же аудитория сайта слишком мала. Считаю необходимо использовать ресурсы типа boomstarter.ru/. Если у кого-то ещё есть интерес к модулю обмена — пишите, можем объединить усилия, будет больше шансов собрать необходимую сумму. Мои контакты есть в профиле.
У Вас ошибочные данные, SAP содержать очень дорого, да и бухгалтера с навыками работы в SAP на каждом углу найти не реально. Если по количеству установленных лицензий они конечно могут обгонять 1С в России (так как работают в ней полноценно только огромные компании), но не по количеству компаний использующих данное решение. Сейчас не знаю как, но году в 2010-2012 товарищ работающий в РЖД рассказывал про использование SAP, так вот он говорил чтоб содержать один грубо говоря отдел бухгалтеров нужно было три сопровождающих отдела.
А насколько мне известно, 1С раза в два проигрывает САРу на российском рынке. А на мировом так и вовсе ее присутствие не выше статистической погрешности.
Если вкратце, то когда я пытался в домен [('id','in', get_vendcontact_ids)] подставить значение поля типа Many2many, то для системы это выглядело вот таким образом: [('id','in', [(6,0,[ID1,ID2,ID3])])], что приводило к ошибке. Чтобы корректно сформировать домен в этом случае нужно писать так: [('id','in', get_vendcontact_ids and get_vendcontact_ids[0][2])]
Для моего случая понадобилось вычисляемое поле Many2many, куда будут записываться нужные id:
Его невидимым нужно вытащить в xml формы:
И вот так должно выглядеть определение поля, где можно выбрать контакт только из отфильтрованного списка:
Уже работает. Для полноты картины еще понадобится на OnChange поля «Поставщик» привесить обновление нашего вычисляемого поля и корректное изменение значения связанного лукапа:
that's all
def fields_view_get(self, cr, uid, view_id=None, view_type=False, context=None, toolbar=False, submenu=False):
if context is None: context = {}
res = super(sale_order, self).fields_view_get(cr, uid, view_id=view_id, view_type=view_type, context=context, toolbar=toolbar, submenu=submenu)
doc = etree.XML(res['arch'])
nodes = doc.xpath("//field[@name='order_line']/form//field[@name='product_id']")
for node in nodes:
node.set('context', "{'partner_id':parent.partner_id,}")
res['arch'] = etree.tostring(doc)
return res
X
А в самой модели res.partner — переопределить метод search. Который в случаи наличия в контексте ('looluppartner_id')
будет фильтровать вывод search.
Вторая ветка моих исследований — это указание в xml формы в качестве домена названия какого-нибудь вычисляемого поля:
Но тут появляется проблема с типом этого поля. В случае, если это one2Many и он заполнен какими-то id контактов, то при нажатии кнопки лукапа появляется ошибка: TypeError: not all arguments converted during string formatting.
Работающий вариант получился только в комбинации: поле типа Char и в нем только один id контакта — тогда домен накладывается успешно.
Если в поле Char пытаться указать несколько id, например «4, 3», то появляется ошибка:
DataError: ОШИБКА: неверное значение для целого числа: «4, 3»
LINE 1: ...t".«active» = true) AND («my_contact».«id» in ('4, 3'))) ...
Попробуйте переписать в старом стиле:
Есть fields_view_get(), но внутри него мне так и не удалось добраться до значений полей текущей записи:
может быть есть событие на открытие окна на редактирование? там и вызови этот код…
есть задача запустить CRM на odoo.
если вам это интересно, то пож., свяжитесь со мной +7 903 792 13 25
Дмитрий
Для формирования цены на изделия потребуется себестоимость. Odoo может посчитать прямые затраты на изделие по спецификации и технологическому маршруту.
Поскольку закупки комплектующих производятся партиями и не обязательно по одной цене, нужно будет посчитать остатки по среднему. Odoo это делает.
В общем, лучше, если заказчиком на Odoo как инструмент операционного и финансового менеджмента будет Первое лицо.
Наверное термин запасание здесь больше подходит. Суть в том, что нам надо обеспечить наличие всех компонентов для производства.
Или все-таки нужен не «склад» (Inventory == опись), а «запасание» для производства.
И еще ремарка: «себестоимость» по Закону о бух.учете и по Налоговому кодексу разные. А для менеджмента она будет третьей. 1С хорошо считает налоги, а вот для финансового менеджмента Odoo куда лучше подходит.
Можем обсудить.
Спасибо за наводку, мы только начинаем осваивать эту программу.
Понимаю условность короткого демо-ролика, он, конечно, не «про жизнь», а про то как выглядит в Odoo натуральный (в штуках) учет запасов.
Сразу вопрос: а для каких коллег это видео, целевая аудитория? Потенциальным пользователям-специалистам или все-таки топ-менеджменту.
Последним должно быть интересно как раз то, что вы упомянули вскользь — учет в деньгаХ, пополнение запасов через эти самые purchases (закупки), и то, чего не коснулись совсем — считание себестоимости (costs) произведенной / проданной продукции.
Отдельный демо-ролик рекомендую сделать по функции «запасания» (Procurements) — это для производственного предприятия вообще может стать центром, вокруг которого выстраивается операционный менеджмент. Здесь и правила автоматического пополнения запасов, запуск Purchase и Manufacture ордеров. С этим стоит повозится. Здесь неизбежно придется обсуждать и фиксировать и даже изменять (!) политики предприятия.
Смею высказать предположение, почему эта тема висит уже два года.
С моей «кочки зрения» изначальное предположение, что задача обмена данными Odoo > 1C и обратно
исключительно техническая есть серьезное заблуждение,
которое может съест уйму времени и средств.
Если вы полагаете, что найдется какой-нибудь очень главный бухгалтер, из которого вы сможете под это вынуть ТЗ,
боюсь время будет потрачено зря.
Дело в том, что это не ЗАДАЧА, а ПРОБЛЕМА, однозначного решения не имеющая.
Accounting (по GAAP и IFRS) с Российским бухучетом не стыкуются по принципу.
Точнее, по базовым принципам.
Здесь как в анекдоте:
— Назовите десять причин, почему батарея не поддержала наступление огнем?
— Во-первых не было снарядов…
В Российской бухгалтерии принимаются к учету (строго!) операции, подтвержденные документами. Нет документа — нет операции!
Это понятно, поскольку у бухучета нет другой цели, как начисление и своевременная оплата налогов государству. И все!!!
В Accounting'е и, следовательно в Odoo, наличие бумажек, не скажу необязательно, но сильно вторично.
Здесь важна сама операция, её экономический смысл, а далее наличие ресурсов и в целом финансовое состояния бизнеса.
Accounting нужен в первую очередь менеджменту, потом владельцу / акционерам, в-третьих, для расчета налогов.
[Следствие: не переводите «invoice» как «счет-фактура».
И вообще, не спешите менять английские понятия на термины из РСБУ.]
Погуглите в российском интернете по поводу конвертации отчетности из РСБУ в МСФО и наоборот,
проблема не решена ни на уровне мэпирования операций,
ни на уровне трансляции финансовых отчетов.
Разброс экономических результатов может составить более 50%.
Гипотетически эксперты полагают выходом совмещение в одном продукте двух параллельных учетов — МСФО и РСБУ.
На создание такого монстра, насколько мне известно, никто не замахивался.
А потому, пока у нас не откажутся от постсоциалистической «бухгалтерии народного хозяйства»,
предпринимателям и менеджменту не обойтись без параллельного ведения «капиталистического» управленческого учета
в отдельном инструменте — если не в Odoo, так по старинке в Excel.
Но лучше все-таки в Odoo, чтобы не изобретать велосипед.
А попутное освоение принципов и норм «капиталистического учета», поверьте, будет сильно полезно и предпринимателям, и генеральным менеджерам.
P.S. Задачки для программистов, типа загрузки выписок из банка в Odoo, конечно же остаются.
По ТЗ, уже есть какие-нибудь наработки?
Моя компания только начала начала заниматься внедрением odoo, но необходимость модуля обмена данными с 1С Бухгалтерией уже видим. Считаю что краудфайдингом заниматься необходимо не на этом ресурсе, маловероятно что тут есть люди, готовые вложиться суммой 500 000, к тому-же аудитория сайта слишком мала. Считаю необходимо использовать ресурсы типа boomstarter.ru/. Если у кого-то ещё есть интерес к модулю обмена — пишите, можем объединить усилия, будет больше шансов собрать необходимую сумму. Мои контакты есть в профиле.