File formats
First, recognize that office suite file formats are natively associated with specific products. The publishers of those products continually tweak the suite features, and the file formats to support them. They publish the file format specs, but for other office suite publishers, compatibility is secondary and a game of catch-up.
There is certain core functionality that all of the office suite developers include. But some developers may choose not to include certain complex features, at least initially. Also, as each developer comes up with new features, other developers may choose not to replicate those immediately, or at all. If they do, they might implement them differently. So there is never 100% compatibility between different products.
Full-featured app vs. lightweight app
This is especially true between a full-featured suite and a lightweight suite. The lightweight suite won't contain all of the features of the full suite. However, complex features used in a document that are unsupported by the lightweight app still need to be dealt with. Sometimes they can just be ignored (not used or rendered), in which case the file will not look or perform the same. Sometimes the lightweight app doesn't know what to do with the information and fails to open the file. So trying to work between a full-featured app and a lightweight one is always finicky.
There's another potential issue with a lightweight third party app. If you use it to edit a document that's been prepared using a full-featured application, it may not know how to preserve document features it doesn't support. So when you reopen the document on the big application, you may find things missing or corrupted.
Docs to Go is a featherweight application that is designed to let you do basic stuff on a portable device with limited resources. If you are moving between it and a full-featured office suite, it's most effective for the simpler tasks, like doing the initial work, which you then enhance on the more capable package, or minor cleanup if the document doesn't contain unsupported features.
If you are doing anything fancy on the more capable application, you are likely to run into problems where Docs to Go won't be able to render or reproduce the features, or may have trouble opening the file.
Improving compatibility
You will have the best compatibility if you use the native file formats of the office suite, or use the office suite for which the desired file formats are native. Stick with the same publisher's products across platforms. Using full-featured third-party apps on both platforms is likely to have fewer incompatibilities between them.
In your case, you want to use Microsoft file formats because they are a common denominator between the two apps you've chosen. Docs to Go was designed around those formats, but it's a featherweight, third-party app. The formats aren't native to OpenOffice. Also, your two apps are from different third-party developers that have each taken different approaches to how much of the spec they implement and how they do it. The farther you deviate from ideal, the more incompatibilities you will encounter, especially if you do anything fancy in your documents.
There are a few directions you can go for better compatibility.
Full-featured application on the phone.
LibreOffice and OpenOffice are pretty similar (they share common roots), and are full-fledged office suites. They're big, so if you can fit them on your phone, they will push the available resources.
LibreOffice is working on an Android version. They have LibreOffice Viewer for Android. The editing capabilities are currently limited and experimental, but can be enabled (they don't recommend it for anything mission critical).
OpenOffice has had some organizational issues (see this article as mentioned by DrMoishe Pippik), but is farther along on this path. There is a third party port to Android called AndrOpen Office. It's supposed to be the full-featured package, although it's based on an older version of OpenOffice -- 3.4 vs. the current 4.1.3 at the time of this writing).
I suspect that the Android versions are intended for a tablet rather than a phone, but they're free, so you have nothing to lose trying it (if it will fit).
Outside of those two, there are other Android office suites (some free), that are compatible with the Microsoft formats and some may be more robust than Docs to Go. Bear in mind that anything designed to function well on a phone will be a lightweight app, so expect less than 100% compatibility. Microsoft offers Android versions, so those are likely to be the most compatible (but not free).
I haven't tried any, but here are a couple of good reviews of offerings: Android Authority, and Lifehacker. There's a lot of overlap. InforWorld seems very enamored with a couple of products.
SO member Mark Yisri recommended WPS Office, a free multi-platform office suite, in chat based on his own success with it, and I understand you've found the Android version more compatible that Docs to Go.
Native application on the phone
When the publisher of a full-featured office suite ports the product to a mobile device, they can't fit every feature of the full package. However, they are meticulous to ensure that anything in a document prepared using the full version can be handled gracefully in some way on the lightweight version. This is often simply ignoring the unsupported features and finding a user-friendly way to render it and warn about things that won't work. But the lightweight version will open the file. When it saves the file, any unsupported features will still be in the document unaltered.
If you need to use a lightweight app on your phone, you should have good compatibility using one from the publisher for whom the file formats are native. In your case, that would be a Microsoft mobile app.
Attention to the shared file format
If you aren't in a position to use applications on both platforms for which your chosen file format is native, you might improve compatibility with a different file format. Part of the compatibility picture comes from how compliant are third party publishers with a given file format, and some comes from the format, itself. Different formats support different ranges of features, some are more rigorously defined, and some may be more conducive to compliance. Perhaps an even bigger factor is the degree of similarity between the software's native file format and a different format you want to use.
There are a number of widely-used file formats that are commonly supported by office suites to provide general compatibility. The old Microsoft .doc and .xls are legacy formats. The newer Microsoft .docx and .xlsx have become more the "standard" in recent years. SU user Bob suggests in a comment that these may be better specified than the older formats and may be more reliably accessible from third-party applications.
The Open Document Format for Office Applications is the other widely used format (it includes .odt for word processing documents and .ods for spreadsheets). This is an open source format developed by committee specifically to provide "universal" inter-operability. It is the native format of most open source office suites. Microsoft has included support for it, but it isn't a high priority for them and I don't know how well Microsoft products handle these documents.
A big factor in compatibility is similarity between the file formats, which drives how easy it is to convert between them. The .doc and .xls formats were proprietary to Microsoft. Microsoft moved to an XML-based format with .docx and .xlsx, which are structurally different from the legacy formats. Conversion between these formats involves fundamental changes. The Open Document Format is XML based, so it is a much simpler conversion between it and the more recent Microsoft formats.
If you mix software whose native formats are different but XML-based, an XML-based shared format is likely to have fewer compatibility problems. The most problematic combination will be using one application designed around XML and another application designed around the legacy Microsoft formats (which is the situation with OpenOffice and Docs to Go). Whichever file format you choose as your shared format will require fundamental change on one of the applications.
Beyond this general pattern, compatibility will be influenced by the features you include in your documents, and which application does the better job of handling the non-native format. Experimentation may be required.
Web-based application.
There are a number of free or low-cost web-based office suites that rival the computer-based versions and will work with the same file formats. Some of them are outlined in this article. Google's G Suite is well known, but carries a small subscription cost. There is a free cloud-based version of LibreOffice. Another one is Zoho Docs, which is bundled with their free email service.
Web access will cost you phone minutes, but you won't be limited by the phone's resources.
Diagnose and replace the problem component
The above is general guidance that would be a good place to start for somebody getting initially set up (or out of patience and ready for some change). However, there are some simple diagnostics that can narrow down your problem, which may enable you to minimize how much you need to change to fix the problem with an existing set up.
In your case, you're creating files in OpenOffice and some are failing to open in Docs to Go. It's possible that there is some random glitch that's damaging files during transfer, or some other quirky thing. But the most likely explanation is that either OpenOffice is creating some form of corruption when it saves some of the files in the non-native format, or Docs to Go has a shortcoming in its ability to handle something in the files, at least as created by OpenOffice.
Corruption could include OpenOffice taking some shortcuts in file creation so that the file does not totally comply with the Microsoft spec. The problem is recurring, and recurring in the same way, which means it isn't a random hiccup; it's something inherent.
To test this, you will need at least one additional application that reads and writes .doc and .xls files. LibreOffice would be a good one for testing. If you don't have access to any other free office suite, you could use Zoho Docs (the free web-based suite with a link earlier in the answer). Here's the procedure:
- Wait until you have another failure to open the file. Pass the problem file back to the PC to a location that won't conflict with the original source document.
- Try to open the returned file in OpenOffice. Try to open the original file in OpenOffice.
- If the original file opens but the returned one does not, it indicates that the file got corrupted in transfer to the phone. That's a totally different problem that has nothing to do with this one. It will take entirely different diagnostics and could be the subject for a different question.
- If neither file opens, it indicates that OpenOffice corrupted the file when it saved it, so replacing OpenOffice would likely solve the problem.
- If both files open, it means that OpenOffice is happy with whatever it saved, but that might not be a compliant file. Try opening either file with one or more other office suites.
- If any other office suite has a problem with the file, that points to OpenOffice saving files in a form not fully compliant with the spec.
- If no other office suite has a problem with the file, that indicates that Docs to Go has an inadequacy. But before replacing Docs to Go, try one more test. It's possible that Docs to Go relies on more rigid compliance with the spec than the full-featured suites are able to tolerate.
- While the other office suite has the file open, save the file under a new name. Try to open the new file in Docs to Go. If Docs to Go can open it, you could likely solve the problem by replacing OpenOffice with a more compliant application (like the one whose file Docs to Go could open).
