I have created an Excel template to collect data from multiple sources in a standard format. Pretty soon, I will be sending this template to people from different countries. I would like them to be able to select the language of the template directly from within the Excel workbook. This would enable them to have the headers translated in their own languages. I want to support 4 major languages and I can provide the translations of my headers in these languages.
Is there a good solution to do this? Could my Excel workbook embed a set of *.properties files containing the translations? Or should I use nasty formulas to retrieve the headers from a hidden sheet? Should I use VBA and how?
Of course, another solution would be for me to create 4 different files. But I feel this will become a nightmare when I want to support more languages or make changes to my template.
Thanks,
I would choose a nasty formula because your recipients might not appreciate the security risks of VBA, amongst other considerations. If you have a range with Language names (or other references) in a column (say a named range of HLcol1) and the appropriate headers in a matrix alongside HLcol1 (with the entire array named say HeaderLanguagethen:
=INDEX(HeaderLanguage,MATCH($A$6,HLcol1,0),COLUMN())
in B6 and copied across might suit, where the chosen Language name (or other reference) is in A6.
6 because rows 1-5 seem as good a place as anywhere to place the lookup array - these rows could be hidden.
Related
I am trying to make a list in Excel that has as its output a list of unique items that appear multiple times in different sources of the excel sheet. Ideally, the list should be automated automatically as more data is inputted in the sources, but no additional sources will be added. I used a formula I found here, but it only works for a single source of data (and this data then needs to be adjacent).
I attached a picture of my document with circles enclosing the sources and pointing to where the list should be created. I highlighted in yellow a cell in the top row that does not get outputted (because I don't know how to do this). Picture for reference
I can provide the excel document if need be.
I am thinking of consolidating the sources to a single source, but I would like to solve this in a more sophisticated way that does not involve creating more tables.
As per your screenshot it seems you are using tables. Then try below formula-
=IFERROR(INDEX(FILTERXML("<t><s>"&TEXTJOIN("</s><s>",TRUE,Table1[Machine],Table2[Machine])&"</s></t>","//s[not(preceding::*=.)]"),ROW(1:1)),"")
Please note: TEXTJOIN() is available to Excel-2019 & Excel-365 and it has limitation to 50,000 data only.
To learn more about FILTERXML() read this article from JvdV.
We get at least 20 queries a day on an average from our clients, where in we have to open and look at data on 4 to 5 Excel sheets to answer them. questions such as what is my available balance, am i eligible for this etc. All our clients are connected to our intranet and have access to internet. I was wondering is there a way where we can develop a front end app (do not have budget for MS VB or any other) either in excel or any other to connect these 4 to 5 excel sheets to retrieve the data in response to queries (e.g. using perhaps some if and true/false queries). I am not an advanced Excel user but would be great for an advice from tech experts.
Yes, i wouldn't call it an app but consider a worksheet like a dashboard. You can have a cell for entering client name, and then use formulas to look up relevant information of the name entered. The cosmetic and arrangement of the information retrieved and published on the dashboard is up to you and of course do consider investing some time in the looks and feel if you want to enjoy using it.
Things you may consider are:
Place the files are kept and file name convention
because your dashboard will look for information in external workbooks, ensure that the files are saved in a fixed directory and have a specific file name. if the external files are updated from time to time by other folks, let them know too that they have to save it in a particular folder with a specific name format.
Properly structure the source of data
Format you data source into tables so that it is easier for use with formulas. Throw away titles if any in the data source worksheet. Use tools like "Table" under the INSERT tab. When data are properly organized, they can be easily looked up using formulas such as VLOOKUP, SUMIFS, MATCH-INDEX, and COUNTIF.
Be good with formulas
Since we have no budget for VB, then good formulas will be needed. There are plenty of help on the internet for this I think you'll have no problem in it.
Employ sanitary check measure
It is difficult to tell if our formula isn't functioning properly when we have no counter check measure. Certainly you want to give your clients accurate information. One way to check is, think of alternative ways to get the information wanted and check if it matches to the first way. Another way is to retrieve a sequence of related information to be put on the dashboard, then do simple calculation to check if the numbers add up. Use conditional formatting to highlight errors if necessary.
I think these are key consideration, there may be more, but this is what i can think of for the moment.
I'm basically inserting information from a dataset into an excel document. We really don't want to use interop services, so my best option is to use the OpenXML SDK.
Basically all I need to do is select a cell based on an id/name/whatever (I would rather not use the standard "A1" format), and then insert something into it. But for the life of me I can't figure out how to obtain a set of cell elements based on an attribute value.
Part 2 of this is I then need to merge certain cells. Which is much easier to do since it involves simply appending a collection of mergecell elements to the mergecells table. But I'm looking to make sure that any cell within a merge range isn't a part of another merged cell range, as this would cause problems.
I feel like this is a REALLY powerful tool, but the lack of documentation and examples makes it a difficult subject to approach.
It seems the easiest interface for editing excel documents is the ClosedXML library.
Searching each worksheet for specific cells is a lot easier. You can also search for named ranges.
and it automatically handles cell mergers by deleting any previous merged ranges that conflict with the newest one.
My current employer (to remain nameless) has a collection of incredibly sophisticated Microsoft Excel 2003 worksheets (developed by contractors, also to remain nameless).
The employer is replacing the Excel-based solution with a SalesForce-based solution (developed by other contractors, likewise to remain unnamed). The SalesForce solution is also very complex using dozens of related objects and "Dynamic SOQL" to contain the data and formulas which previously was contained in the Excel-based solution.
The employer's problem, which has become my problem, is that the data from the Excel spreadsheets needs to be meticulously and tediously recreated in .CSV files so it can be imported into SalesForce.
While I've recently learned I can use CTRL-` to review formulas in Excel, this doesn't solve the problem that variables in Excel have cryptic names like $O$15. If I'm lucky, when I investigate $O$15, I'll find some metadata explaining if n cells up and/or some other data m cells to the left, and/or (in rare instances) there may be a comment on the cell.
Patterns within the Excel spreadsheets are very limited, rarely lasting more than 6 concurrent rows or columns and no two sheets which need to be imported have much similarity.
Documentation of all systems are very limited.
Without my revealing any confidential data, does anyone have any good ideas how I might optimize my workflow?
It's not clear exactly what you need to do: here are 3 possible scenarios, requiring increasing knowledge of Excel.
1. If all you want is to convert the Excel spreadsheets into CSV format then just save the worksheets as CSVs.
2. If you just want the data and not the formulae then it would be simple (using VBA) to output anything that isn't a formula (the cell.Formula won't start with =).
3. If you need to create a linkage excel-->csv-->existing Salesforce objects/SOQL then you will need to understand both the Excel Spreadsheets and the Salesforce objects/SOQL that have been created. This will be difficult unless you have good knowledge and experience of Excel and also understand what the salesforce App requires.
Brian, if you're still working on this, here's one way to approach the problem. I use this kind of process often for updating data between SFDC and marketing automation apps.
1) Analyze the formulae that you're re-creating in Salesforce.com to determine what base data fields you need (stuff that doesn't have to be calculated from something else.
2) Find those columns/rows in your spreadsheets and use Paste Special -> Values in a new spreadsheet to create an upload file with values instead of formulae that you need for each data area (leads, prospects, accounts, etc.)
3) If you have to associate the info with leads or contacts or accounts and you have already uploaded or created those records in Salesforce.com, be sure to export them with their ID numbers. That makes it easy to use the vlookup formula in Excel to match up fields that you need to add and then re-upload the data into Salesforce.
Like data cleaning, this can be a tedious process. But if you take it step by step it shouldn't be too hard. Good luck.
My Access programming is a little rusty, & I've never worked with Excel files all that much.
I have a requirement to bring data from Excel spreadsheets into Access 2007. These spreadsheets have a fixed (predictable) format, but it includes a "header area" where I need to read single data items from specific cells, followed by a mass of tabular data (~500 rows in the one sample I've seen so far). I will be processing all of this into a set of tables that are normalized quite differently from the flat layout of the spreadsheet.
I know how to open an ADO recordset on the tabular data, and it should work fairly well for my purposes. I also figure that I can reference the Excel object model and open the sheets through Automation to get the "header area" data items.
My question is this: since I have to (I think) use the Automation approach for the "header area", am I better off just leaving it open in this mode to move on to the tabular data (with cell/range navigation), or closing that mode & going over to ADO? I suspect it's the latter--and I'd be more comfortable with it--but I don't want to do the wrong thing just because it's more familiar.
Edit
It seems I wasn't clear that I need to build this capability into the "application", as something that a user can repeat down the line. I'm assured that I can trust the format of the spreadsheet (though I'll include error trapping for graceful failure if that turns out to be false). These spreadsheets are "official design documents" for hardware, and my app needs to handle bringing in new &/or updated ones to track the things that are described in the tabular data in ways that the flat Excel format diesn't allow for.
Of those two options, I would choose the second simply because I find it more convenient to work with an ADO recordset. It should be fairly simple if you can assign a named range to your spreadsheet's tabular data.
Edit: If your spreadsheet includes field names, the recordset approach would be less prone to break due to spreadsheet changes such as one or more new columns inserted before or between the existing columns or a re-ordering of the existing columns.
But actually, I think the TransferSpreadsheet Method might be more convenient. You can specify the spreadsheet range as a named range or by cell address as in this example from the linked page:
DoCmd.TransferSpreadsheet acImport, 3, _
"Employees","C:\Lotus\Newemps.wk3", True, "A1:G12"
Also, you can choose between importing the spreadsheet range directly into an Access table, or linking to the range as a "virtual" table ... whichever best meets your application's needs.
Edit2: Creating a link (acLink instead of acImport) with TransferSpreadsheet would allow you to execute SQL statements against the link table:
INSERT INTO DestinationTable (field1, field2, field3)
SELECT foo, bar, bat FROM LinkedTable;
If the header information is really complicated, this can simplify your coding work:
In the official design Excel file, create a hidden tab.
In that tab, make a 1-row table connecting to all the header elements you're interested in. (i.e. set row 1 column 1 to "Document#" and row 2 column 1 to Sheet1:A1)
Then you can re-use the same VBA procedure to import both your tabular data and your header data.
I would do it all via Automation. Why have two separate processes where one will do? After you've read the header information reading the tabular information will be quite easy.
I inherited an application back in mid-2000 that was built to import Excel spreadsheets that were basically reporting output from MYOB (an accounting program). What had been done was to simply create a template table that had all the columns necessary to accomodate the report, using text data type for all columns. Then the non-data rows were filtered out and processed into the eventual destination table.
It's not elegant, and doesn't require a lot of programming, though the implementation I inherited used a dedicated temp table for each report layout that was being imported. You could easily replace all of those with a single table with 100 text columns of 255 (or memo fields, for that matter, if that was a requirement), and just re-use it.
I'm not sure if I'd recommend it or not, but it really is quite easy without requiring much in the way of code.