En algunos casos si las fórmulas las había introducido desde PWA luego Project Prfessional no me las mostraba.

El problema se ha solucionado al instalar el SP1 de Project Professional.

Luego postearé, la forma que tenemos de subir Enterprise Custom Fields.

To set up your custom field charges, go to Setup – Custom Fields.

If the price for an add-on charge is for the entire reservation, simply leave the time setting at 0. If the price depends on the length of the reservation, select the time frame that the price is for.

Say for example that the charge for DVD player is $15 per day, enter 1 in the time field and select day(s). Now the price will automatically be calculated based on the length of the reservation.

The problem was brought to light with the release of WordPress 2.1, but circumstances exist in older WP versions that would trigger these issues in some plugins.

The plugins are doing this:

1. A plugin inserts a special form field into the post edit form
2. The plugin monitors the form field by hooking into edit_post
3. When the form value is empty or doesn't exist, the plugin assumes the user deleted what was in it, and procedes to delete all the custom values the plugin had stored for that post

The issue occurs because the plugins assume that every time edit_post is triggered, their inserted form field will be included in $_POST. This isn't the case. edit_post is called for requests that do not originate from the post edit form and for requests that are not initiated by a privileged user. Comment submission in WordPress 2.1 is one of these cases. Editing of a post in 2.1 (and earlier versions) via XML-RPC is another case.

Plugins cannot assume that the absence of a POST field means that POST field existed in an empty state, and plugins cannot assume that all calls to edit_post are performed by privileged users.

Here are the two things that plugins must do:

1. Verify that the user performing the action is authorized to perform the action by using the current_user_can() function or its siblings.
2. Verify intention of the user and the origination of the request by embedding a hidden form field with a nonce value, along with your usual custom field.

Here is an example:

function your_form_hook() {
	echo '<input type="text" name="your-plugin" id="your-plugin"
			value="' . your_get_value() . '" />
		<input type="hidden" name="your-plugin-verify-key" id="your-plugin-verify-key"
			value="' . wp_create_nonce('your-plugin') . '" />';
}

add_action('edit_form_advanced', 'your_form_hook');

function your_edit_post_hook($post_id) {
	// authorization
	if ( !current_user_can('edit_post', $post_id) )
		return $post_id;
	// origination and intention
	if ( !wp_verify_nonce($_POST['your-plugin-verify-key'], 'your-plugin') )
		return $post_id;
	your_update($post_id); // do the actual update here
	return $post_id;
}

add_action('edit_post', 'your_edit_post_hook');

This is a post aimed at plugin authors, so I'd appreciate it if we could save the comment space below for plugin authors who have questions about this topic. If a particular plugin you're using is erasing Custom Fields, please contact its author directly.

Note: I've mentioned the edit_post hook, but there are other similar hooks that the above also applies to. publish_post and save_post are two that come to mind.