
You are missing trading opportunities:
- Free trading apps
- Over 8,000 signals for copying
- Economic news for exploring financial markets
Registration
Log in
You agree to website policy and terms of use
If you do not have an account, please register
In fact, we all (the Administration, the Developer, and the Customer) are on different sides of the service. And everyone sees his own nuances and difficulties. The dialogue box that you cited I just saw - it is a significant and important step forward in bringing all the necessary information to the Customer. I listed the questions that 99% of customers ask when they come to the service for the first time. And each customer has to give a link to the Step-by-Step Guide and to the Account Calculations section with enviable consistency and persistence. This state of affairs suggests that the informativeness in the key issues - Step-by-Step Guide and Calculations - is clearly insufficient.
Hello I am new to mt5.com .I have ordered an EA from jobs section and while going through the step by step process of the work i have face difficulties in the 'Negotiation of requirements' step. Both of us, me and the developer confirms the step but I can not access the next step Prototype/Model . The column Negotiation of requirements is still in green color and i am not able to go the next section . Anyone there experienced Please help me...
I'M HAVING THE SAME PROBLEM, SEE IMAGES ATTACHED
You have idea of what is happening, how we could resolve this situation?
Good afternoon to all. I have a question on this topic. The situation is often repeated that the work is taken, you start to do and then it turns out that either the indicator provided by the customer as a source of signals to open trades is not correct and it needs to be improved, or the customer's wishes after passing the stage of approval of the TOR have increased, which leads to an increase in the cost of work. The customer agrees with this and is ready to pay extra, but the price of the project is fixed and as I understand it cannot be changed even with mutual consent. As a result, the extra payment has to run either past the site or make some other work, which is not always convenient. The question is the following - is there still no way to change the cost of work after signing the TOR. In real life, everything is simple - issue an addendum to the contract, in which. prescribe changes in the TOR and the price of the contract - cotton stamps and signatures on both sides and drove on. But here I didn't find anything like that. Or maybe I didn't look hard enough? )))
So far there is no such possibility, but we will think about the implementation.
And only upwards and only if the customer has enough money.
We don't have this possibility yet, but we will think about realising it.
And only upwards and only if the customer has enough money.
We don't have this possibility yet, but we will think about realising it.
And only upwards and only if the customer has enough money.
We don't have this possibility yet, but we will think about realising it.
And only upwards and only if the customer has enough money.
Right when:
1) the performer has the possibility to refuse the work
2) the performer has the possibility to reduce the cost of the work
3) the customer has the possibility to increase the cost of the work
There is a flaw in the stages of work performance:
clause 3.2.7. of the Rules "After confirmation of the step "Approval of TOR" by both parties, the amount of the Order is blocked on the Customer's account in the Payment System."
It turns out that the parties discuss the TOR - namely - the Contractor delves into the TOR, spends his time, corrects the Customer's TOR, actually consults the Customer - and as a result the Customer has the opportunity to "escape" and/or choose another one. As a result, it is often necessary to accept superficially studied TOR with all the consequences in the form of "underestimated the complexity/cost/realisability of the work".
The stage of "TOR approval" should take place in two stages:
1. The customer confirms the TOR - the amount is blocked.
2. There is a discussion of the TOR and BEFORE the confirmation of the stage "Approval of the TOR" the performer should be able to: refuse the TOR, change the cost.
Or the possibility to refuse the TOR by the Contractor and change the cost to realise at the stage "Prototype/Mockup".
Correct when:
1) the contractor has the ability to refuse the work
2) the contractor has the ability to reduce the cost of the work
3) the customer has the ability to increase the cost of the work
There is a flaw in the steps of work execution:
clause 3.2.7. of the Rules "After confirmation of the step "Approval of TOR" by both parties, the amount of the Order is blocked on the Customer's account in the Payment System."
It turns out that the parties discuss the TOR - namely - the Contractor delves into the TOR, spends his time, corrects the Customer's TOR, actually consults the Customer - and as a result the Customer has the opportunity to "escape" and/or choose another one. As a result, it is often necessary to accept superficially studied TOR with all the consequences in the form of "underestimated the complexity/cost/realisability of the work".
The stage of "TOR approval" should take place in two stages:
1. The customer confirms the TOR - the amount is blocked.
2. There is a discussion of the TOR and BEFORE the confirmation of the stage "Approval of the TOR" the performer should be able to: refuse the TOR, change the cost.
Or the possibility to refuse the TOR by the Contractor and change the cost to realise at the stage "Prototype/Mockup".
I confirm, several times on such rakes stepped on such rakes, chew up the customer his own TOR. You spend 3-4 days on it. Spread it all on the shelves, and he leaves with this already rolled out TOR, and orders its execution for a smaller amount.
Make a sensible TOR lion's share of the work, and this share turns out to have no guaranteed payment in the service "Work" !!!!.
These are your risks as a contractor. After all, when you choose a refrigerator, you do not buy one that is very well described by the manager. You take note of the manager's story and can go to another shop and buy a cheaper refrigerator. And the manager will get nothing for his quality story. But it is impossible not to tell at all. The manager understands this and takes a risk every time.
You, as well as other apologists of free use of a programmer's skilled labour, constantly and persistently confuse:
a) the sale of already produced ready-made goods, the price of which already includes a penalty in the form of unproductive work of a manager-consultant, shop rent and so on,
b) with research, development and technical works - in this case the purpose of the "Approval" stage is to understand what the Customer wants, to formalise his initially vague task, etc. etc. - it is worth the cost of professional labour, which should certainly be paid.
If in the first case the manager-consultant does not create a new value - the product is already produced and ready for sale, in the second case the programmer who discusses with the customer his own TOR creates a new TOR for the customer - and this labour must be paid.
If the manager in your case is certainly paid a salary, in the second case - on what grounds do you think that the programmer should remain without pay? Revised, parsed TOR costs not less than the cost of writing a programme - and the customer's leaving to another programmer is natural and justified by the desire to pay less.
In reality, no KB will even undertake to analyse a problem without guaranteed payment. So why should it be a norm in the Work service not to pay (or not to guarantee) payment for analysing/revising/writing TOR?
Most arbitration situations in the Work service are "unclear TOR", "underestimated complexity of work". And the reason is that the developer is completely unprotected from an unscrupulous customer at the "TOR approval" stage.
papaklass:
It is the same in your case. If you refuse to work on the TOR with the customer, you will definitely lose him. And if you competently help the customer to draw up the TOR, there is a very high probability that this work will be given to you and in the future the customer will return to you. Take it as a cost of working with people.
It is time to stop looking at a programmer as a certain unemployed person who has nothing to do, who sits and waits and is happy with every customer and every order. A programmer has a main job, has his own interests and free time. And it is unlikely that a programmer will be happy to spend his free time on an order that may take place only with some probability.