Hence, why we still don't have this?! In PDA there should be a tab where real players could put up jobs for other players, like "BUYING 500 SSS ASAP". The employer should have the ability to tell time period and and the salary. The offered job could only be taken by one player.

Yes, player-submitted missions are on the roadmap. It isn't done yet because Everything Takes Forever. This is some kind of fundamental rule of game development, unfortunately.

+1 to the OP

You could post to the station news about it.

Though, I don't know how much people even look at that anymore...

Rather than the job be taken, it should be first to fulfill. Like bounty hunting, only the most efficient will get the payment. Alternatively, it could have an option "first to take" vs "first to fill", but I can see use cases where someone could take other peoples' jobs and then not fulfill them, creating a new form of player harassment.

Alternatively, there could be an option "fill until" where you request a quantity and a combination of players can fill the order incrementally.

If user takes a job and does not fulfill it in time, he should receive a penalty a bit bigger than the salary he was going to get.

If user takes a job and does not fulfill it in time, he should receive a penalty a bit bigger than the salary he was going to get.

I think this is a terrible idea.

Herein lies the problem with any in-game trading mechanism, auction house, or mission board. Everybody's going to want to set their own terms or do business in a different way, and the only way to really accommodate all of that is by not placing restrictions or structure on the process, which is what we have today.

So in other words, the weirdos are already accommodated by the current system and therefor adding additional systems does them no harm. :P

All the resistance to automated transfers that remove the risk from trading only serves to delay any sort of real change in the player economy. As I have argued for in the past, this sort of thing needs to be integrated at some point. However, it should be as bare bones as possible and there should be an appropriate monetary cost to offset the lack of risk.

Insofar as the topic is concerned, I agree that players should be able to post jobs for hauled items. The player should only be able to place the posting when they are physically docked with the station of delivery. The player should indicate how much of an item they want and how much they are willing to pay. They should then be required to pay a non-refundable posting and handling (P&H) fee. No batch jobs should be allowed. Payment upon complete delivery, no partial deliveries.

Under such a system, the hardest question to answer is: How should the P&H be calculated, and what is considered reasonable for such a low-risk service? (Low risk because someone still has to haul the goods even though station acrobatics aren't necessary for the transfer.)

I would probably create a tiered pricing system based on the number of CU being requested. For example:
1-100cu: 1000cr/cu
101-500cu: 900cr/cu
And so on.

Personally I think there may need to be a paradigm shift that won't please the no-risk-no-way crowd. Yes this is a combat game, but it's not just a combat game, and it needs to evolve some more.

The risk problem could be fixed by Employee Reliability System.
If you are low level, you could only take jobs whose salaries are up to 10000 credits lets say. By successfully completing jobs you would work your tier up, and get bigger jobs, which require reliability.
If you are top tier on the system, and don't complete the job for 2 times lets say, your rank resets back to 0.
Employee then would carefully select a job as he doesn't want losing his tier.
Also players should be able to take just one job at a time.
Employee Reliability System and taking one job at a time should cut any chances of player harassment.

Sorry if my English is hardly understandable, I don't live in USA or United Kingdom.

There are many threads on this topic, plus at least one I started. I'm glad to hear it's on the roadmap. I'd love to place a standing order for SSS and other goodies. This would also help to get the noobs involved with the vets. (I'd place these in noob systems.)

I agree with draugath that it should be station-centric.

Bringing the goods to and from the station is sufficient risk. In fact, the job posting being public actually increases the transport risk a bit, since pirates would presumably be able to see it as well. The reliability rating that Rallen brings up could be used to reduce that risk somewhat; pirates wouldn't be able to see the higher end jobs unless they worked legit jobs themselves to build up their reliability or used spies.

Beside the cost of posting a job, there should also be a duration after which the posting either incurs a renewal fee or gets discarded.

There could also be restrictions on what types of transactions a station will mediate. Lawful stations might refuse to host job postings involving contraband, and larger stations might refuse to mediate transactions that don't involve at least a few hundred cu of goods. Conversely, smaller stations might not be able to mediate transactions involving hundreds of cu. Some types of cargo might have higher fees than others (e.g. volatile or dangerous things, a competitor's products, items that go against the faction's morals without quite entering the realm of contraband (sin tax), etc.).

I edited my earlier post, but such a system should not allow partial delivery. No goods should change hands unless a complete delivery can be made.

Draug, I can see situations where a user is in constant market for an item, example: LENBs or SSS. And in each case, the user would be happy with any but wants a large quantity. In this scenario, it makes sense to let partial orders be filled. IMO, there's no reason not to, and to actively prohibit it doesn't really add any benefit.

Hmm, yeah. I suppose it doesn't have to be as complicated as I originally envisioned it trying to use existing mechanics. I don't think this could be shoehorned into the existing mission system very well, and it probably shouldn't be.

On the back-end I can see it needing to store the item to buy/sell, the price per unit, the number currently available/desired, and the station at which the goods can be picked-up/delivered-to.

If a purchase order is being created, the full cost (price/unit * num_desired) plus a non-refundable processing fee should be taken from the character. If the PO is canceled the remaining credits to pay for the items would be returned.

If a sell order is being created, the items to be sold should be taken from the character's inventory and held until sold at the established price/unit or the SO is canceled. Similarly a non-refundable processing fee should be charged for the service.

When items are taken from somebody's inventory after making a sell order, the number that has not yet been sold should continue counting against their station cargo limit until they have been sold.

Similarly, purchase orders should immediately increase the used station cargo by the amount intended to be bought.

Values:

X = quantity of goods.
Y = per unit purchase price.
Z = quantity of goods * CU per item.

Pre-Steps:

1. Buyer places purchase order with local station.
2. Seller accepts purchase order with local station. Alternatively, Seller could accept order from affiliated station, but goods must be delivered to the local station in which order was placed.

Logic for fill until fulfilled:

1. Buyer places order at specific station for X goods at Y.
2. Buyer pays 1.10*Y*Z.
3. Buyer's local storage quantity of Z is increased.
4. Seller delivers X-(delivered quantity) to station.
5. Seller is paid Y*(delivered quantity).
6. X items are deposited into Buyer's local inventory.
7. If Buyer cancels order before fulfilled, Buyer is refunded Y*(X-(delivered quantity)).
8. If Buyer cancels order before fulfilled, local station storage quantity is reduced by Z.
9. If Buyer's order is completely fulfilled or cancelled, order is removed.

Logic for first to fulfill:

1. Buyer places order at specific station for X goods at Y price.
2. Buyer pays 1.10*Y*Z.
3. Buyer's local storage quantity of Z is increased.
4. If Seller delivers X goods, order is removed as fulfilled.
5. If Seller delivers < X goods, no action is taken.
6. If Buyer cancels order before fulfilled, Seller is refunded X.

Post-Steps:

1. Buyer trade XP is increased.
2. Seller trade XP is increased.

I don't really see a scenario where first to accept is advantageous for either the Buyer or the Seller. Any use case where the Buyer benefits from first to accept creates risk for the Buyer if the Seller does not fulfill the order, and a lot of unnecessary logic around how to penalize the Seller, recreate the order, etc.

However the player order mechanic is implemented, this is going to require new functionality. That being said, I don't see a reason the Buyer should not have choices. If we're going to implement it, let's make it complete.

Buyer should be paying 1.10*Y*Z in both scenarios' step 2s, not 1.10*Y.

In step 7 of fill-until-fulfilled, the buyer is the one who should be getting refunded for the undelivered cargo, not the seller.

Fill-until-fulfilled has two step 8s instead of a step 9.

First-to-fill should have a step 7 reading "If Buyer cancels order before fulfilled, Buyer is refunded Y.", as well as a step 8 matching the other's would-be step 9.

Except, Savet, it looks like you're still in the mindset that they are some sort of mission, when really they should be treated as a subset of the Commodities tab.

What if I don't want to post a mission to buy goods. I want to post a mission that says "Kill the Serco blockade in Edras I-2" or "Gunner crew needed for a mining expedition"

Does everything revolve around Trident parts anymore?