I am creating a business app to manage the inventory of a mid-sized shoe company.
I already have a database created with PostgreSQL. I would now be able to connect it to Odoo 9 to develop applications.
How can I do that?
You can't just use your existing data directly with odoo
But Odoo makes it easy to use existing data from existing applications and databases with it's flexible import system. in which data is imported to it via csv files, you can import any data you can possibly think of, you just have to know the right format of data that odoo is expecting and the required fields you have to provide
Every model in Odoo even custom built modules can have data imported into them
If you want to import data just click on the listview of any model and you should see an import link beside the create button, from there you can carry on, there's even a FAQ there which you can read if you need to find out more about the import system.
As for knowing the required columns that have to be present when you're importing, Just create sample data and save it, Then
Go to the listview
Tick the check-box beside the record name to select it
Now click on the more button you should see an export option
From there you can pick the fields you want to export, the required fields will highlighted in blue
There are other ways of re-using existing data with odoo (You can write to the database directly...but this is not recommended as several constraints would not be checked and you can end up messing the database up) or you can use xmlrpc or jsonrpc which is going to be time consuming
Using the import functionality is the best and the easiest way.
Related
I am looking to build a simple, one page app that does the following (the users who would be utilizing this tool would need this to involve zero code, and as little "clicks" as possible):
a worker who has taken samples could import data (in an excel format) to a database, ideally a SQL server.
after import is complete, the user could use drop downs and filters to set parameters for what report they want to see.
with the "export data button," the user could then export a report to an excel file for their download and use.
I am not very familiar with PowerApps - by the looks of it, this seems like something that can be done, but I don't want to waste time if this is not worth the effort and won't have the functionality I am looking for. If this IS impossible, any suggestions on where I could build out something like this?
I have a email folder in Outlook that contains 100s of emails which record my discussions with a developer of some bespoke software. I want to import these into SQL to create a knowledge base of information that can be searched upon to extract all the decisions that we have made during the course of the 2 year project.
Having sreached the net, I found that it is very easy to dump the contents of an email folder into Access using the import data functionality. In fact I have linked the table and so believe (never used Access before!!) that I now have an Access table that is connected in 'real-time' to the Outlook folder. This is eactly what I want BUT in SLQ as this is something that I am very familiar with using.
So I have tried to import the Access database into SQL (which also appears to be relatively easy) but keep getting the message that 'The source database ...contains no visible tables or views'. Checking SQL pemissions, I am owner of this new databse.
Two questions please. First, cant believe that going through Access is the simplest way to do this and presume that I will loose the 'real-time' link - am I right? Second, given that I can see my Access database has a visible table, why am I getting the error?
The easiest and quickest way is to create a VBA macro where you can populate your SQL database from Outlook emails. You can build the table structure according to your needs and extract the required information from Outlook using VBA. I'd suggest processing emails in chunks using the Find/FindNext or Restrict methods of the Items class, so you will not reach the reference counter limit. The MailItem properties you may find described in MSDN.
BTW The internal store (if you use the cached mode) in Outlook acts like a database. So, why do you need to introduce yet a new database?
Using t-code SEGW, I created a SAP Gateway project with several data models based on RFC function modules. The data structure is based on the handy "Import" funtionality.
Due to a customer request, I had to copy the project into another, customer owned, namespace.
After the copy, I lost the funtionality to import fields to the data models.
When I create a new entity, the possibility to import is still there. When I copy a fully working project, lets say to $tmp, I lose the import feature again.
Sure, I can still edit my entities by hand but it is tiresome and prone to errors.
So, my question, is there a way to re-enable the import feature of copied SAP Gateway projects?
Check if you are importing complete project into customer system, check for the service and model. It should have come if the project has been imported successfully.
Note: Please update SEGW with latest release.
I am enhancing and fixing the forms/queries/VBcode etc. for an access 2007 database. The current version is being actively used and when I am done with my changes I need to transfer in my changes without disrupting the data stored in the tables already in the running mdb.
I'm not entirely sure how to handle the "merge" when the time comes. As an experiment I have a local backup copy of the version I started working on and used the import external Access data option. This imported the new forms, queries, vb, etc. But the only hang up is that the switchboard form isn't the new. Switchboard forms of course are guided by the switchboard manager but I was hoping that all that logic is held inside the form itself somehow. It seems this is not the case. After the import there is a new form of the same name with a number after it as expected, and the correct create/modify date. But when open it looks exactly the same as the old switchboard.
Any ideas?
It sounds to me as if you have both the data and the forms etc in the one database. This is not a good idea at all and if you are updating, it is the ideal time to correct the problem. If you split the database, any updates to forms and code can be simply copied to the user without worrying about the data. You will find some notes here: http://office.microsoft.com/en-us/access-help/split-an-access-database-HA010342026.aspx
The Access switchboard manager uses a table named Switchboard Items to dynamically populate switchboard form pages. You will need to transfer the updated version of that table to make your revised switchboard pages available in the other project.
I'm importing some customer information from Landslide CRM into Salesforce.
Anyone have advice on the best methodology for doing the import?
It seems like the Apex Data Loader is the best way to go, but I don't know
if there are any issues with handling the objects in question, or if there
might be a specific tool or script to perform this migration.
Any experience with this import in specific or importing data into Salesforce
in general would be appriciated.
Importing Data to salesforce can be achieved in multiple ways depending on the type of data nd the requirements you have.
The first thing to do is get your data into CSV files so you'll need to find a way to export the dat afirst. For UTF-8 encoded data don't use Excel use something like OpenOffice (only required if you have UTF-8 Characters)
If its account and contact data for example. There is an import wizard available in Setup > Administration Setup > Import Business Accounts/Contacts
Next Option is as you say to use the Apex Data Loader. This probably the best approach.
The first thing and this is critical for big migrations is to Create a Field on your account object which will be a Unique Field for reference purposes. When creating this field set it as an External ID field and populate it with a unique reference for your accounts, the same goes for anything else which will be a parent. (you'll see why shortly.)
Next use the Insert option in the Data Loader to load the data mapping all the fields, especially the External Id
Now when you upload child objects use the Upsert option and map your Account Id via the External Id created earlier. This will match the accounts using your unique Id instead of you having to use the Salesforce id, saves alot of time.
Repeat the same for other objects and you should be good to go.
Apologies for the lack for structure here... doing this while in work and don't have alot of time but hope this helps.
The data loader works great for most types of imports. The one suggestion I would give you is to create a new custom field on your target objects (presumably Account and Contact) called "Landslide ID" or similar, identify it as an external ID field, and then import the primary keys from your source system into this field (along with the "real" data).
Doing this achieves a couple things - first, you have an easy unique link back to the source data for troubleshooting or tracing back to the source system. Second, if you find yourself in a situation where you need to import more fields or related data from the original source system, you'll be able to do so in an easy and correct way. It's just a good standard practice to adopt when doing data migrations -- it's almost no additional effort and can save you many hours in the future.