Your situation sounds quite bad, for several reasons:
- Your client seems to be short of money, or at least driving a hard bargain. This is never a good thing, and if you are offering decent services, your client(s) should be happy to pay you for it.
- You seem surprised at the contract. Even if there was no contract in place before, clearly your expectations didn't match the client's. At best, you were both slightly naive and there's a large gap in expectations, and at worst, your client maliciously played you on purpose (e.g. if they withhold payment unless you agree to this, and knowingly sprang this on you late).
- The contract seems to include several items which are very difficult to quantify, meaning a large risk for you. It doesn't seem reasonable (even without considering the "for free" part), which is never a good sign.
So in general, I agree with most of the other posts, you should take a hard line here and possibly cut your losses, if it comes to that. Having said that, your post still has some unanswered questions, so I will try to give some insight.
I wanted to hear from professionals how you guys handle / what you charge for documentation, training, warranty, changes in scope etc...
You really have two broad classes of scenarios - either the project is fairly well defined (in terms of requirements), or it isn't. What I'm going to describe below is for the "well defined" route. While this seems very "waterfall" / old school, the simple fact is, clients almost always want a fixed quote before work begins. The simplest alternative would be a "pay-as-you-go" approach where requirements are not fixed, but this doesn't seem to be attractive to clients, and will also make it difficult for you to plan your own availability.
I've always gone with a single hourly rate; this may or may not get communicated to the client (according to their preference for how the project and billing is structured), but it forms the basis of your estimates. Essentially, I mean that the rate charged for training, documentation, bug fixes, or new features is the same. The problem then becomes trying to estimate the level of effort required for each.
It is quite common to offer a fixed duration of training - e.g. "4 days of training", with various conditions attached. Typical conditions might be: specifying that each "day" is 8 hours, whose responsibility it is to set up the training environment, where the training will take place (the client may want you to travel). You are probably assuming: "I will show up, and train some people for a few hours". Your client might think "this guy will set up PCs for 20 people, train them, and give them lunch". It's best to clarify responsibilities early.
Warranty - I have no issue giving a limited warranty; if the scope of the project is clear, with unambiguous requirements. Use your judgement here. I also like to keep the warranty period short, as it can interfere with future projects. E.g. you don't want to be 3 months into your next project when the previous client decides to go live, and starts needing weeks of your time. I normally go with a 1 month period, along the lines of "anything that doesn't work as per the specifications will be fixed for no additional charge, as long as it is reported within 4 weeks of delivery date". Offering warranty is also great motivation to keep yourself honest, and the work to high quality, so I actually like to do it.
It's important to note that the warranty is explicitly tied to the requirements (assuming it is their responsibility to provide those). Don't agree to any requirements that are too ambiguous or broad for you to be comfortable. Even more importantly, never guarantee anything more than this; it's not your job to ensure that they are financially successful in using your software (e.g. that the requirements were good in the first place).
Changes in scope - this is the difficult one. I normally classify these into trivial and non-trivial changes. Trivial changes are things that would take less than 30 minutes to do. I will often let these slip, and do them without charge, because it'd cause more friction to explain to the client why you are not willing to change 1 label.
Include a few hours in your estimates for these, and you won't feel cheated when they come around. Non-trivial changes, in general, are not allowed. If they are critical for the client, they won't mind you whipping up an addendum to your quote (and typically, critical changes will be large enough to warrant an addendum).
Since requirements do tend to change, keep your projects short. I like to split large projects into roughly 1 month iterations, with defined requirements and a testable, executable deliverable at the end of each. Any changes arising out during one iteration can be worked into the next - a modification to the quote and a quick approval from the client is all that it takes. If there's a major ripple effect, the situation is more complicated; but it is in your interest to avoid those. You need to take a very mature, pragmatic approach to these projects, understanding the requirements intimately, so that you can preempt show-stoppers early on.
What you are doing here is estimating things. The more you know about yourself and your client, the easier this becomes. With experience, you will learn to detect problem clients early and avoid them altogether.
When you see risks and unknowns, make sure you pad for them (read up on how to factor risks into your estimates). If I'm pushed into these situations, I tend to err on the side of caution (this also gives the client incentive to minimise unknowns). Do communicate with your client about these things - 99% of the time, they would rather clarify a requirement, or narrow the scope of something in the contract, than be thrown with a hugely padded quote.
Never go into anything that poses a severe financial risk for you - unbounded warranties, etc. When you have a long history with a (reliable) client, you can relax these rules to make things easier, but in general, they still apply.