Пара-тройка наводящих вопросов:

1. Если 9.1, то почему вы правите ini файлы напрямую, а не через Server Manager?
2. Почему вы решили, что транзакция отменяется из-за таймаута?
3. В каком приложении|форме и при выполнении каких действий (нажатии такой-то кнопки, переходе со строчки и т. д.) возникает ошибка?
4. Повторяется ли ошибка в других средах, например в DV910 или на других данных?
5. Не проводились ли модификации BSFN F4311EndDoc и связанных с ней?
6. Что означает фраза "вылетаем в манагере"?

Теперь о действиях
1. Необходимо перед возникновением самой ошибки включить debuglog для того процесса CALL OBJECT, в котором будет выполняться F4311EndDoc, и проанализировать содержимое соответствующего файла jdedebug_xxxx.log
2. Можно попробовать повторить ошибку на разработческой машине, когда функция будет выполняться локально

andolini100ляров,

Ответы на вопросы
1) Правили и на Server Manager и на прямую в .ini файле.
2) Рекомендованные http://ipohtech.blogspot.com/2013/10/recommended-timeout-for-e1-bsfn.html посоветовали сделать так.
3) p4310 approval(Сведения заказа) возникает при сохранении стоимости.
4) на DV и PD не пробовали потому что они еще не используются(только запускаем).
5) модификаций не проводились.
6) называем манагер server manager))


1. Править напрямую ini файлы, вне ServerManager - нельзя - это приведет к путанице и бесконтрольным изменениям.
Руководствуйтесь, пожалуйста, рекомендациями поставщика решения (в данном случае, Оракл), а не каких-то сторонних специалистов. Тот блог, в котором рекомендуют править параметры относится к более древним версиям JDE.
Вот, что написано по этому поводу у Оркала:
http://docs.oracle.com/cd/E24902_01/doc.91/e23434/understand_server_manager.htm#EOHLU00002
"Beginning with the availability of Server Manager, it is strongly advised that all changes to configuration files (such as jde.ini, jas.ini, jdbj.ini, jdelog.properties, etc.) for any JD Edwards EnterpriseOne server managed by Server Manager be accomplished using only the Management Console interface of Server Manager".
Но, это так, к слову. Опытный CNC-администратор, конечно, может править INI - файлы вручную. Но вы же говорите, что только запускаетесь

2. Вы не ответили на вопрос. ПОЧЕМУ вы решили, что ваша проблема связана с ТАЙМАУТОМ? При тайм ауте так и будет написано Timeout, да еще и время в милисекундах будет, например вот так:

*ERROR* CallObject@517e4191: COSE#1000 Request timeout: timeout after 90000ms host XXX:6016(52462) SocID:36444 PID:1816 BSFN:F4311EndDoc user:XXX Env:JPY910

А у вас совсем другое. TM_TRAN_CANCELLED - это не таймаут. Это может быть связано с разными причинами: блокировка записей внешним приложением, наложенные ROW Security - запрет на правку/вставку по каким-то критериям - и еще куча причин.
Для этого я и говорю: jdedebug.log в студию.
А то, что вы привели в качестве совета при такой ошибке не поможет - только внесет еще больший сумбур.

3. P3410|ФОРМА - нужно знать название формы (не только приложения) (название формы будет таким: W4310X, где X - буква) и какую кнопку вы нажали

4. Как это, интересно, вы запускаете без DV? Это невозможно. Может быть, у вас нет доступа к DV - попросите проверить. Опять же, запустите локально - на разработческой машине - попросите разработчиков/админов

К сожалению, я тоже не волшебник, и не могу знать что происходит на вашем сервере Enterprise в кернеле CALL OBJECT, в котором выполняется функция XT4311Z1.F4311EndDoc (вы прислали не совсем тот файл)
Есть 2 пути
1. Вы выкладываете debuglog процесса CALL OBJECT, где выполняется функция XT4311Z1.F4311EndDoc.
2. Чаще всего TM_TRAN_CANCELLED - это Row Security, то есть кто-то наложил запрет на обновление или вставку каких-то записей в какую-то таблицу, участвующую в обновлении при данной операции. Вот именно имя это таблицы я и хочу узнать из пункта 1. Скорее всего, это таблица F4311, но в процессе участвует с десяток других таблиц и запрет на запись в одну из них приведет к отмене транзакции.
Для устранения этого фактора необходимо (если вы по каким-то причинам не можете выполнить пункт 1) убрать все записи Row security дать соответствующие права пользователю, который выполняет данную функцию - какие именно права и на какие строки каких таблиц нужно дать я смогу определить только после выполнения вами пункта 1.
Как еще проверить, что это Row Security.

Если вы не знаете - как выполнить пункт 1, я могу подробно об этом рассказать.
Если вы не знаете как работать с Row security, я могу подробно об этом рассказать.
Однако этот форум - не очень подходящее место для проведения обучения по работе в JDE

Вкратце по пункту 1 (все делается в Server Manager):
а) Найти процесс на Enterprise сервере, в котором для пользователя выполняется логика (CALL OBJECT)
б) перед самым моментом нажатия кнопки (после которого вылетает ошибка) включить для данного процесса debug logging (не забыть потом выключить)
в) Нажать кнопку и повторить ошибку
г) скачать файл jdedebug_xxxx.log для этого процесса


Вкратце по пункту 2:
Приложение P00950 - только будьте осторожны. При неаккуратной работе с данным приложением можно систему уронить навсегда, или, по крайней мере, очень надолго.

моя почта: quantumer@gmail.com

andolini,

зачем же вы говорите не правду - не было доработок?
Были. И именно в вашу кастомную таблицу (при чем названную совершенно не правильно) F4311L не проходит запись - нарушение ограничения уникальности:

Строки присланного лога, начиная с 242288 (выделения курсивом и болдом - мои):

Вы уж как-нибудь сами теперь разбирайтесь - кто, откуда, для чего и что пишет в эту таблицу - скорее всего из какого-то триггера другой таблицы.
За такие доработки нужно руки отрывать - F4311L - это ж надо так назвать!!!

andolini,
Вы не торопитесь руки отрывать.
Вина разработчиков в том, что они назвали объект так, как его может назвать сам Оракл, что приведет к конфликту.
Напрямую это не влияет на ситуацию.
Проблема возникает при отсутствии контроля при записи в эту таблицу.
Либо (я не знаю назначения этой таблицы) при не удалении из нее старых данных.