Простой код, но UpdateConflict, почему?

[sukhanchik]

Ну давайте разберём по порядку.
1. Технологию (платформу, ядро) создают одни, а затем логику (приложение, код на Х++) пишут другие. Т.е. те люди, которые предполагали, что будет цикл по перебору строк в одной транзакции - не предполагали, что другие будут писать логику на purchline.update(). А те, кто писали логику на purchline.update() ... видимо вообще не думали - делали, как им проще закодить.
2. В одной транзакции сделать апдейт всех строк можно. Вопрос лишь ценой каких усилий и каких ограничений Вы же всегда можете написать код вида
ttsbgin;
purchTable = PurchTable::find('MyCurrentPONumber', true);
purchTable.FieldA = 'aa';
purchTable.update();
purchTable = PurchTable::find('MyCurrentPONumber', true);
purchTable.FieldB = 'bb';
purchTable.update();
ttsbegin;

Ну и для PurchLine - аналогично. Другое дело, что это создаст нагрузку на БД при массовом обновлении и могут появиться блокировки опять-таки при обработке большого количества данных, но... сделать же можно
3. В отдельных случаях (когда логика на update небольшая) - можно вынести в код эту логику и написать .doupdate(). Да, это нарушит принцип "не надо дублировать код", но... работать будет. А логику можно вынести в отдельный метод и его просто вызывать в разных ситуациях и тогда проблемы дублирования кода уйдут.
4. В рамках одной транзакции всё должно быть ок, но при условии, что каждый следующий update() получает актуальный курсор. Т.е. если мы выбрали purchLine, затем изменили у него FieldA и сделали update(), то перед обновлением FieldB - нужно, чтобы в переменной purchLine содержался бы курсор с уже обновленным FieldA, а не тот, который был бы на момент начала транзакции (кстати, именно для этого на таблице есть метод reread()).
5. И еще надо учесть такое понятие, как пессимистическая и оптимистическая блокировки. В оптимистической - да, именно так, как Вы описали, и так у многих табличек работает по умолчанию. Однако, если курсор второй раз выбран под пессимистическую блокировку - то вторая выборка на обновление будет "висеть" до завершения транзакции по первому update(). Пессимистическая блокировка - это когда в коде пишется select pessimisticlock purchLine. Либо select forupdate purchLine, а на purchLine установлено свойство optimisticConcurrency = No (такие конструкции встречаются в коде у таблички InventSum). В Вашем случае конечно такого нет, но в общем случае (не с purchLine) момент с блокировками нужно учитывать