NB: If you are new to the Forum, please ensure that you read the Forum Policies as well as the rest of this post.

If you're posting a request for assistance, your chances of getting a useful and speedy answer will be greatly enhanced if you follow the guidelines below. Also, please remember that no-one here is providing "official" support on behalf of the software vendor. The answers are being given by fellow users who donate their own valuable time and knowledge to you for free, and the clearer the question, the less time they need to spend in answering it:

1) Ensure that the versions of the software that you're using are specified in your question. If you don't have that in your profile or signature file (you can update these through the User Control Panel shown at the top of the screen), please ensure that you specify that in the body of the question. This includes whether it's 32 or 64 bit, and where applicable your operating system, version of Excel, etc.

2) Ensure that you specify the component of the software that you're having a problem with. If someone states that they have a problem with (say) number formatting, people need to know whether that's in Cube Viewer, Web, EV, the API, or wherever.

3) Try to make the question as specific as possible. A general question like "How do I write a rule?" is difficult to answer without copying out the whole of the user manual. A question like "I have a payroll cube which contains the following dimensions {details} and a general ledger cube which contains the following dimensions {details}, and although I've read through the Rules Guide I'm still not sure how to write a rule to give me average sales per employee" is far more likely to get the answer your need.

4) Similarly if you're getting unexpected results, specifics of what you're running, how, and what results you're getting will yield a more valuable response than "I'm running a T.I. but my code doesn't work properly". If you're getting an error, please be specific about what the error is (full details, not just "a runtime error" or "process terminated with errors"), and the circumstances under which it's occurring. But remember that even if you do specify the exact error message, it's not likely to be helpful unless you provide the context for it; which part of the software the error is occurring in (point 2 above), and what, specifically, you were doing at the time.

5) For Rules and TurboIntegrator processes, posting the actual code and the real names of and structures of your cubes, dimensions and elements will be a thousand times more useful than an attempted description of them. You don't need to post real data, but the real code is needed. Pseudo code is obviously not "the real code". When you post something like "Suppose I have cube A and Cube B, and my rule is ['value'] = N:DB('CubeA', 'dim1, dim2'" etc, then three things happen. One, you reduce the chance that a syntax or typing error will be spotted, which means wasting time bouncing posts back and forth to try to get to the root of the problem. Two, you are usually describing what you think is happening, which may not be what is happening. Three, some more experienced members won't even look at the question because they've had too much time wasted by the first two issues in the past. You can upload entire .pro, .cho or .rux files as attachments if necessary, or just copy and paste the relevant part into your post using the Code tag at the top of the post editing window.

6) Keep to one topic per thread. It's the nature of threads (in all on-line forums, not just this one) that they tend to wander into other subjects by way of digression. However if you have a completely separate question, please don't append it onto the thread of a previous, unrelated question that you asked. Give it a separate thread with an appropriate heading. (An appropriate heading not being "Help", "TM1 Question" or even something like "Rules Question", but rather a brief description of the specific issue.) That makes it more likely that someone who knows about that area of the software will see it and be able to respond, and it will also help make the search results more relevant.

7) Give a brief outline of what you've done to find the answer; which manuals or guides you've looked in, and what tests you've done. TM1 documentation isn't the best or most logically organised, and nobody expects new users to be able to find things which are obscure. It's OK to ask a question which more experienced users might consider obvious; we've all done it. However if the person answering your question knows what you've looked at, they won't waste your time or theirs by telling you what you already know. At a minimum, you should ensure that you browse the FAQ thread and use the search box in the top right to see whether there is already a solution to your problem. Also, please don't ask very basic questions about how to do things in TurboIntegrator or Rules without at least looking through the relevant functions in the Reference Guide.

8) Let people know whether the answers that you received did (or didn't!) work for you. If someone searches for the same issue at some future time, that will help them to decide which suggestions might be the most beneficial for them to follow. Besides, posting a quick "Thank you, that solved my problem" is common courtesy in most societies, and is doubtless appreciated by the answerers.