Scheduler Action is not running

Bug #1336152 reported by spreehut
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
OpenERP Connector
Invalid
Undecided
Unassigned

Bug Description

Hi,

Please help i've setup my server following the instructions provided. Using Ubuntu 14.04, OpenERP v7, Mangeto 1.9.0.1.

The Metadata is pulled and store info is visible and the worker is alive. However, the scheduler action is not running the jobs.

The jobs are all in 'Pending' state and aren't getting picked up by the worker.

I attempt to follow the guide below but no luck.
https://bugs.launchpad.net/openerp-connector/+bug/1281073

Please let me know if you need anything thing else from my end.

Revision history for this message
Guewen Baconnier @ Camptocamp (gbaconnier-c2c) wrote :

What do you have in --database or db_name option?

Revision history for this message
Guewen Baconnier @ Camptocamp (gbaconnier-c2c) wrote :

Do the others "Scheduled Actions" run? I can't see any scheduled actions in your logs.

Revision history for this message
spreehut (awmin) wrote :

I don't think any of the scheduled actions are running, because the 'Next Execution Date' is not being updated. I even attempted to changed to server timezone to UTC to the OpenERP standards. Is there a cron or what else can it be possibly that is preventing the schedules to not run?

information type: Public → Private Security
information type: Private Security → Public
Revision history for this message
spreehut (awmin) wrote :

Also the dates on each of actions for the 'Next Execution Date' are from the first day I installed openERP.

information type: Public → Private Security
spreehut (awmin)
information type: Private Security → Public
Revision history for this message
Guewen Baconnier @ Camptocamp (gbaconnier-c2c) wrote :

Hi,

Ok, they are not running if the next execution date is not updated. That means it is an OpenERP issue, not in the connector.
I see 2 potential causes:
 * db name different in 'database' or 'db_name' but you already ensured that it is not the case (you can try to remove entirely the option's value
 * this option set to 0, but the default is 2
    --max-cron-threads=MAX_CRON_THREADS
                        Maximum number of threads processing concurrently cron
                        jobs (default 2).
Apart that, I have no idea, but you can try on a more general channel like http://help.odoo.com

Changed in openerp-connector:
status: New → Invalid
Revision history for this message
spreehut (awmin) wrote :
Download full text (3.3 KiB)

thanks for the help, i figured it out. i never installed the addons branch and was missing key addons. I installed the branch and removed the 'db_name' but left the --database option. Also had to dropped the old db and create a new one to start the jobs.

However, now i am getting the following error during import... the product import wroked but orders from mangeto are showing this...

********************************************ERROR************************************************************

Traceback (most recent call last):
  File "/opt/openerp/v7/addons/openerp-connector/connector/queue/worker.py", line 122, in run_job
    job.perform(session)
  File "/opt/openerp/v7/addons/openerp-connector/connector/queue/job.py", line 485, in perform
    self.result = self.func(session, *self.args, **self.kwargs)
  File "/opt/openerp/v7/addons/openerp-connector-magento/magentoerpconnect/unit/import_synchronizer.py", line 373, in import_record
    importer.run(magento_id, force=force)
  File "/opt/openerp/v7/addons/openerp-connector-magento/magentoerpconnect/unit/import_synchronizer.py", line 229, in run
    self._after_import(binding_id)
  File "/opt/openerp/v7/addons/openerp-connector-magento/magentoerpconnect/sale.py", line 516, in _after_import
    self._create_payment(binding_id)
  File "/opt/openerp/v7/addons/openerp-connector-magento/magentoerpconnect/sale.py", line 473, in _create_payment
    amount, context=context)
  File "/opt/openerp/v7/addons/e-commerce-addons/sale_payment_method/sale.py", line 133, in automatic_payment
    amount, date, context=context)
  File "/opt/openerp/v7/addons/e-commerce-addons/sale_payment_method/sale.py", line 168, in _add_payment
    move_obj.create(cr, uid, move_vals, context=context)
  File "/opt/openerp/v7/addons/account/account.py", line 1393, in create
    result = super(account_move, self).create(cr, uid, vals, c)
  File "/opt/openerp/v7/addons/openerp-connector/connector/producer.py", line 42, in create
    record_id = create_original(self, cr, uid, vals, context=context)
  File "/opt/openerp/v7/server/openerp/osv/orm.py", line 4550, in create
    result += self._columns[field].set(cr, self, id_new, field, vals[field], user, rel_context) or []
  File "/opt/openerp/v7/server/openerp/osv/fields.py", line 559, in set
    id_new = obj.create(cr, user, act[2], context=context)
  File "/opt/openerp/v7/addons/account/account_move_line.py", line 1148, in create
    if ('account_id' in vals) and not account_obj.read(cr, uid, vals['account_id'], ['active'])['active']:
  File "/opt/openerp/v7/server/openerp/osv/orm.py", line 3679, in read
    result = self._read_flat(cr, user, select, fields, context, load)
  File "/opt/openerp/v7/server/openerp/osv/orm.py", line 3731, in _read_flat
    cr.execute(query, [tuple(sub_ids)] + rule_params)
  File "/opt/openerp/v7/server/openerp/sql_db.py", line 161, in wrapper
    return f(self, *args, **kwargs)
  File "/opt/openerp/v7/server/openerp/sql_db.py", line 226, in execute
    res = self._obj.execute(query, params)
ProgrammingError: operator does not exist: integer = boolean
LINE 1: ...d FROM "account_account" WHERE account_account.id IN (false)...
                       ...

Read more...

Revision history for this message
Guewen Baconnier @ Camptocamp (gbaconnier-c2c) wrote : Re: [Bug 1336152] Re: Scheduler Action is not running

My guess is that you configured a journal for the payments on the
'payment method', but this journal miss the default credit and debit
accounts. They are mandatory on 'Bank and Check' journals, so you may
also check if you journal has the correct type.

spreehut (awmin)
description: updated
Revision history for this message
spreehut (awmin) wrote :

Guewen,

Thank you so much for the help, i have setup credit and debit for Sale and Purchase Journals to the recommended settings.

I am now stuck and need help with the process workflow. I am not sure what else i need to do next.

One other thing i noticed is that there are several customers created multiple times during import. Is there a way to merger and avoid it from creating companies and only rather customer only once?

Thanks once again,

Revision history for this message
Guewen Baconnier @ Camptocamp (gbaconnier-c2c) wrote :

Your message is not sufficiently precise to help me to help you. What do
you mean by stuck? What do you mean by several customers? (It is normal
that it creates contacts for the magento addresses).

Revision history for this message
spreehut (awmin) wrote :

When the orders are imported, it triggers to create the customers. However, there are three of the same customers created one is marked as "Company" (it actually should not be), other two are just customers with the same exact info pulled from magento.

So how do I only have it create one customers record rather then three as it does now?

Sorry about the inconsistency with my earlier comment.

Revision history for this message
Guewen Baconnier @ Camptocamp (gbaconnier-c2c) wrote :

So this is expected: the 'Company' is linked to the Magento "Account". The 2 others are each one linked to 1 address on Magento.

Revision history for this message
Guewen Baconnier @ Camptocamp (gbaconnier-c2c) wrote :

This is just a replication of what you'd see on Magento

Revision history for this message
Guewen Baconnier @ Camptocamp (gbaconnier-c2c) wrote :

Actually it should be a 'Company' because this is the only way in OpenERP 7 to link several addresses to an individual (see https://bugs.launchpad.net/openobject-server/+bug/1151947). Consider the field 'company' as a misnamed
.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.