Система и способ управления платежом в строительстве с функциональными возможностями обмена документами

СИСТЕМА И СПОСОБ УПРАВЛЕНИЯ ПЛАТЕЖОМ В СТРОИТЕЛЬСТВЕ С ФУНКЦИОНАЛЬНЫМИ ВОЗМОЖНОСТЯМИ ОБМЕНА ДОКУМЕНТАМИ Изобретение относится к системам и способам для управления процессом платежа в строительстве. Одна из конструкций системы включает в себя машиночитаемую память и задействованный программным обеспечением пользовательский интерфейс. Процесс сконфигурирован для отображения получателю платежа посредством пользовательского интерфейса электронного уведомления о предстоящем платеже и запроса документа, подписанного электронным образом,такого как отказ от удержания. Процессор в этой конструкции дополнительно сконфигурирован для приема документа, подписанного электронным образом, сохранения его в машиночитаемой памяти и инициации платежа. В некоторых конструкциях процессор дополнительно сконфигурирован для отображения документа, подписанного электронным образом плательщику только после того, как платеж был инициирован. В некоторых конструкциях процессор дополнительно сконфигурирован для проверки того, что требования удовлетворены до инициации платежа. 015031 Уровень техники В строительной промышленности некоторые компании инвестировали большое количество денежных средств и времени в автоматизацию и/или устранение конкретных аспектов процесса выставления счетов между плательщиком (например, подрядчиком, банком или собственником имущества) и получателем платежей (например, субподрядчиком, продавцом или поставщиком материалов). Сущность вариантов осуществления изобретения Всеобъемлющие автоматизированные системы управления оплатой строительства могут быть необязательными или нежелательными у некоторых участников в строительной промышленности. Однако такие участники все же могут испытывать необходимость или желание в автоматизированных системах для конкретных аспектов проекта или процесса строительства. По существу, остается потребность в автоматизированных системах или модулях, которые фиксируют счета и обрабатывают бюджеты или перечень стоимостей, проверяют соответствие документов стандартам (например, подтверждают получение запрошенных/требуемых документов) и/или обмениваются снабженным электронной подписью отказом от удержания по платежу. Некоторые варианты осуществления изобретения предлагают системы и способы управления процессом платежа в строительстве, задействующим множество участников, связанных со строительным проектом, причем по меньшей мере один документ, который подлежит передаче по меньшей мере между двумя участниками в ходе строительного проекта в обмен на платеж, перечисляемый от участника, получающего документ, участнику, создающему, представляющему или подписывающему документ электронным образом. В некоторых вариантах осуществления способ дополнительно может включать в себя назначение по меньшей мере одного документа на расходование платежа, при этом платеж расходуется автоматически, если по меньшей мере один документ передается по меньшей мере между двумя участниками. В некоторых вариантах осуществления способ дополнительно включает в себя назначение правоприменительного действия приостановки платежа по меньшей мере одному документу, при этом правоприменительное действие приостановки платежа выполняется автоматически, если по меньшей мере один документ не передан по меньшей мере между двумя участниками. В некоторых вариантах осуществления правоприменительное действие приостановки платежа выполняется автоматически, не принимая во внимание обмен иными документами, по меньшей мере между двумя участниками. В некоторых вариантах осуществления способ дополнительно включает в себя создание или подписание по меньшей мере одного документа электронным образом и отправку по меньшей мере одного документа первому участнику по меньшей мере из двух участников, по меньшей мере один документ запрашивает платеж у первого участника. В некоторых вариантах осуществления способ дополнительно может включать в себя прием одобрения по меньшей мере одного документа от первого участника и создание, представление или подписание по меньшей мере одного дополнительного документа электронным образом в обмен на платеж. В некоторых вариантах осуществления способ дополнительно включает в себя создание или подписание по меньшей мере одного документа электронным образом и отправку по меньшей мере одного документа первому участнику по меньшей мере из двух участников, по меньшей мере один документ включает в себя величину платежа. В некоторых вариантах осуществления способ дополнительно может включать в себя прием одобрения по меньшей мере одного документа от первого участника и создание,представление или подписание по меньшей мере одного дополнительного документа электронным образом в обмен на платеж на основании входных данных от первого участника. Краткое описание чертежей Фиг. 1 - схематическая иллюстрация системы управления платежом в строительстве согласно одному из вариантов осуществления изобретения. Фиг. 2 иллюстрирует рабочий процесс обмена отказом от удержания по платежу в системе управления платежом в строительстве по фиг. 1 без управления соответствия стандартам. Фиг. 3 иллюстрирует рабочий процесс обмена отказом от удержания по платежу в системе управления платежом в строительстве по фиг. 1 с управлением соответствия стандартам. Фиг. 4 иллюстрирует рабочий процесс обмена отказом от удержания по платежу в системе управления платежом в строительстве по фиг. 1 без управления соответствия стандартам и без автоматического электронного платежа. Фиг. 5 иллюстрирует рабочий процесс обмена отказом от удержания по платежу в системе управления платежом в строительстве по фиг. 1 с управлением соответствия стандартам и без автоматического электронного платежа. Фиг. 6 - схематическая иллюстрация процесса управления проектом. Фиг. 7 - схематическая иллюстрация процесса управления организацией. Фиг. 8 - схематическая иллюстрация процесса создания организации и/или пользователя. Фиг. 9 - иллюстрация создания формы организации. Фиг. 10 - иллюстрация уведомления обновления системы пользователем. Фиг. 11 - иллюстрация системного уведомления.-1 015031 Фиг. 12 - иллюстрация формы редактирования организации. Фиг. 13 - иллюстрация уведомления активации организации. Фиг. 14 - иллюстрация формы активации организации. Фиг. 15 - иллюстрация уведомления об активированной организации. Фиг. 16 - иллюстрация уведомления о деактивированной организации. Фиг. 17 - схематическая иллюстрация процесса поддержания организации. Фиг. 18 - иллюстрация экрана представления организации. Фиг. 19 - иллюстрация экрана просмотра организации. Фиг. 20 - иллюстрация формы редактирования организации. Фиг. 21 - иллюстрация уведомления об обновленном профиле организации. Фиг. 22 - схематическая иллюстрация процесса создания пользователя. Фиг. 23 - иллюстрация формы создания пользователя. Фиг. 24 - иллюстрация уведомления обновления профиля пользователя. Фиг. 25 - схематическая иллюстрация процесса поддержания пользователя. Фиг. 26 - иллюстрация экрана представления пользователя. Фиг. 27 - иллюстрация экрана представления пользователей. Фиг. 28 - иллюстрация формы редактирования пользователя. Фиг. 29 - иллюстрация уведомления об обновленном профиле пользователя. Фиг. 30 - схематическая иллюстрация процесса создания проекта. Фиг. 31 и 32 - иллюстрации формы создания проекта. Фиг. 33 - иллюстрация формы создания соответствия стандартам. Фиг. 34 - иллюстрация формы управления соответствием стандартам. Фиг. 35 - иллюстрация уведомления о созданном проекте. Фиг. 36 - схематическая иллюстрация процесса назначения ролей пользователя на проект. Фиг. 37 - иллюстрация экрана доступа пользователя по проекту. Фиг. 38 - иллюстрация уведомления об обязанностях по проекту. Фиг. 39 - схематическая иллюстрация процесса обмена отказом от удержания. Подробное описание Прежде чем будут подробно разъяснены варианты осуществления изобретения, следует отметить,что изобретение не ограничено в своем применении деталями конструкции и расположением компонентов, изложенных в последующем описании или проиллюстрированных на последующих чертежах. Изобретение может быть выполнено в соответствии с другими вариантами осуществления и осуществлением на практике или выполнением различными способами. К тому же, должно быть понятно, что фразеология и терминология, используемые в материалах настоящего описания, предназначены для целей описания и не должны рассматриваться в качестве ограничивающих. Использование терминов "включающий в себя", "содержащий" или "имеющий" и их вариантов в материалах настоящего описания подразумевается охватывающим элементы, перечисленные после этого, и их эквиваленты, а также дополнительные элементы. Термины "установленный", "соединенный" и "связанный" используются в широком смысле и охватывают как непосредственную, так и опосредованную установку, соединение и связывание. Кроме того, "соединенный" и "связанный" не ограничены физическими или механическими соединениями или связями и могут включать в себя электрические соединения или связи, непосредственные или косвенные. К тому же, электронные коммуникации и уведомления могут выполняться с использованием любого известного средства, в том числе непосредственных соединений, беспроводных соединений и т.д. Следует отметить, что множество основанных на аппаратных средствах и программном обеспечении устройств, а также множество разных структурных компонентов могут использоваться для реализации изобретения. Более того, и как описано в последующих параграфах, отдельные конфигурации, проиллюстрированные на чертежах, предназначены для приведения примера вариантов осуществления изобретения и возможны другие альтернативные конфигурации. Фиг. 1 иллюстрирует систему 10 управления платежом в строительстве (CPMS) согласно одному из вариантов осуществления изобретения. CPMS 10 включает в себя сервер 12 приложений, сервер 14 баз данных, модуль 16 прикладной логики, веб-сервер 18, сеть 20 (такую как сеть Интернет или другие сети отдельно или в комбинации с сетью Интернет), службу 22 проверки, участвующие организации или физические лица 24 (в дальнейшем "участник" или "организация") и платежную систему 26. Платежная система 26 может включать в себя систему автоматизированной расчетной палаты(АСН), систему банковского перевода, систему дебетовых карт, систему кредитных карт, систему формирования чеков, которая формирует чеки, счета, вексели, простые вексели, IOU (долговые расписки),дебетовые авизо или другие оборотные инструменты либо любую другую пригодную систему электронного перевода средств (EFT). Служба 22 проверки проверяет новые организации и/или пользователей перед тем, как им предоставляется возможность использовать CPMS 10.-2 015031 Сервер 12 приложений хранит и предоставляет доступ к модулю 28 проекта, модулю 30 управления формой, устройству 32 разрешений и авторизации, системе 34 управления базой данных, администратору 38 доступа, администратору 40 уведомлений, модулю 42 организаций, модулю 46 контракта, модулю 50 пользователя, администратору 52 системного окружения и электронному промежуточному бункеру/средству 68 условного депонирования. Администратор 52 системного окружения включает в себя генератор 62 сообщения, модуль 64 помощи и модуль 66 обслуживания системы. Электронный промежуточный бункер/средство 68 условного депонирования может хранить электронные отказы 54 от удержания и другие электронные платежные квитанции 56. Модуль 28 проекта координирует создание проектов и хранит имеющую отношение к проектам информацию. Модуль 30 управления формой создает документы на основании предопределенных шаблонов. Устройство 32 разрешений и авторизации идентифицирует и хранит разрешения и авторизации для пользователей CPMS 10. Например, устройство 32 разрешений и авторизации может хранить разрешения, которые уточняют, каким пользователям предоставлена возможность осуществлять подписание от имени конкретной организации или компании. Подобным образом, администратор 38 доступа управляет доступом к функциям, предусмотренным у CPMS 10. Например, администратор 38 доступа может хранить назначения разрешений и/или проекта. Администратор 40 уведомлений формирует уведомления пользователям CPMS 10. Например, администратор 40 уведомлений может формировать уведомления, когда требуются действия, и/или для целей оповещения. Модуль 42 организаций создает и обслуживает организации с использованием CPMS 10. Модуль 46 контракта обеспечивает функции ведения контрактов и хранит информацию о контрактах. В некоторых вариантах осуществления информация о контрактах является классом данных, используемым для проведения сделок. Модуль 50 пользователя создает и обслуживает отдельные учетные записи пользователей для индивидуумов, осуществляющих доступ к CPMS 10. Как показано на фиг. 1, сервер 12 приложений также включает в себя модуль 88 управления документами. Модуль 88 управления документами функционирует в качестве средства категоризации и хранения электронных документов. В некоторых вариантах осуществления сервер 12 приложений также включает в себя модуль 90 соответствия стандартам. Модуль 90 соответствия стандартам включает в себя устройство, которое хранит требования соответствия стандартам и их статус (например, удовлетворил ли данный подрядчик конкретным требованиям). В некоторых вариантах осуществления требования, хранимые в модуле 90 соответствия стандартам, отслеживают, была ли принята документация по документу (например, контракты,требования уплаты, заявления под присягой, документы страхового покрытия или прикрепления или сертификации, предварительные извещения о праве удержания собственности, отказы от удержания и т.д.) от участников 24, связанных с проектом, и в некоторых вариантах осуществления выдает предупреждения и предлагает варианты выбора для принуждения к соответствию стандартам посредством процесса платежа, вплоть до и включая автоматическую остановку платежа. Документы могут быть связаны с конкретным проектом, конкретным имуществом проекта, конкретным элементом статьи бюджета в проекте или с конкретным участником или организацией. Документы также могут отслеживаться на истечение срока действия, и модуль 90 соответствия стандартам может формировать предупреждения и напоминания о приближающемся истечении срока применяемых приостановок платежей. Предупреждения и напоминания пересылаются подрядчикам посредством администратора уведомлений, и приостановки платежей размещаются и/или выпускаются посредством функций контроля модуля 90 соответствия стандартам. Как показано на фиг. 1, сервер 12 приложений также включает в себя модуль 92 интерфейсов. Модуль 92 интерфейсов служит средством стыковки с внешними системами, такими как системы бухгалтерского учета, системы управления проектами и системы планирования и управления ресурсами предприятия (ERP), и передает информацию в и/или принимает информацию из внешних систем. Должно быть понятно, что компоненты сервера 12 приложений могли бы быть скомбинированы иным образом, чем как показано и описано по фиг. 1. Программное обеспечение, используемое для кодирования различных модулей, администраторов и устройств сервера 12 приложений, может комбинироваться и разделяться любым подходящим способом и может храниться и быть доступным любым подходящим способом. Сервер 12 приложений может быть присоединен к серверу 14 базы данных, модулю 16 логики прикладных программ и службе 22 проверки. Однако в некоторых вариантах осуществления служба 22 проверки может быть присоединена только к сети 20. Модуль 16 прикладной логики может быть присоединен к веб-серверу 18 или в некоторых вариантах осуществления непосредственно к сети 20. Веб-сервер 18 может быть присоединен к сети 20. Участники 24, например, могут включать в себя застройщика 74, инспектора/представителя 76 на месте, одного или более субподрядчиков (субподрядчика А 78, субподрядчика В 80 и т.д.), одного или более поставщиков 82 материалов, продавца 84 и одного или более агентов 86 условного депонирования строительства. Хотя не показано на фиг. 1, другие участники, такие как банк, титульные компании или владельцы собственности, также могут быть включены в состав. Участники 24 могут получать доступ к-3 015031 серверу 12 приложений, для того чтобы использовать различные модули, администраторы и блоки для выполнения способов управления платежом в строительстве согласно нескольким вариантам осуществления изобретения. Участники 24 могут быть соединены с платежной системой 26; однако некоторые из участников 24 могли бы не быть соединены с платежной системой 26 в некоторых вариантах осуществления изобретения. В некоторых вариантах осуществления платежная система 26 может включать в себя систему АСН с одним или более инициирующими депозитарными финансовыми учреждениями (ODFI) и одним или более получающими депозитарными финансовыми учреждениями (RDFI). Фиг. 2 иллюстрирует пример рабочего процесса обмена отказом от удержания, управляемого посредством CPMS 10. В этом примере застройщик 74 является застройщиком жилых зданий; однакоCPMS 10 могла бы применяться к ситуациям, где застройщик 74 занят в строительстве нежилых зданий. Более того, подобные функциональные возможности могли бы быть применены к ситуациям, где обмениваемый документ не является отказом от удержания 54. Как показано на фиг. 2, жилищный застройщик 74 может обеспечивать CPMS 10 требованиями к отказам от удержания проекта. В некоторых вариантах осуществления жилищный застройщик 74 вводит требования к отказам от удержания непосредственно в CPMS 10 (например, с помощью клавиатуры, сенсорного экрана и т.д.). В других вариантах осуществления CPMS 10 служит средством связи с внешней системой жилищного застройщика 74 (например, системой ERP) через модуль 92 интерфейсов для получения требований. Требования к отказам от удержания уточняют тип требуемого отказа от удержания,даты, к которым отказы от удержания должны быть приняты для получения платежа, и т.д. После того как жилищный застройщик 74 выдает требования, жилищный застройщик 74 может снабжать CPMS 10 проектными платежными данными продавца. Проектные платежные данные продавца могут выдаваться непосредственно жилищным застройщиком 74 и/или выгружаться из внешней системы жилищного застройщика 74 (например, системы ERP и/или бухгалтерского учета) через модуль 92 интерфейсов. Платежные данные, выдаваемые жилищным застройщиком 74, связывают элемент статьи с проектом, продавцом 93, которому должна быть произведена оплата, и запрошенным отказом от удержания. Платежные данные включают в себя величину платежа, которая должна быть оплачена конкретному продавцу 93. Когда продавец 93 запрашивает платеж, CPMS 10 может создавать счет, запрашивающий платеж,от имени продавца 93. Жилищный застройщик 74 создает счет (например, с использованием CPMS 10) от имени продавца 93, который включает в себя определенную величину платежа. Продавец 93 просматривает счет и одобряет или отвергает определенную величину платежа через CPMS 10, но не может модифицировать величину платежа. Как только продавец 93 одобряет счет, CPMS 10 приглашает продавца 93 подписать отказ от удержания, для того чтобы инициировать платеж продавцу 93. Этим способом жилищный застройщик 74 определяет величину счета или выставленную в счете к оплате величину, представленную продавцом 93, а потому в данной отрасли промышленности часто называется как "определенное выставление счетов". В некоторых вариантах осуществления CPMS 10 может поддерживать среды "определенного платежа", среды "определенного выставления счетов" и среды "выставления счетов", при этом продавец создает и представляет счет, запрашивающий платеж. В некоторых вариантах осуществления величина платежа определяется или устанавливается продавцом 93 (например, в виде величины в долларах или в виде процента завершения), и жилищный застройщик 74 одобряет величину платежа (например, с помощьюCPMS 10). В некоторых вариантах осуществления продавец 93 представляет счет через CPMS 10. В качестве альтернативы жилищный застройщик 74 или CPMS 10 может формировать счет от имени продавца 93 на основании запрошенной величины платежа. После того как платежные данные введены в CPMS 10, CPMS 10 приглашает продавца 93 (например, посредством уведомления) подписать отказ от удержания с помощью модуля электронной подписиCPMS 10. Отказ от удержания может быть частичным или окончательным отказом от удержания. Как только продавец 93 подписывает отказ от удержания электронным образом и представляет отказ от удержания в CPMS 10, CPMS 10 сохраняет отказ от удержания в электронном промежуточном бункере 68 и автоматически ставит в очередь платеж продавцу 93. Как показано на фиг. 2, CPMS 10 по этому примеру включает в себя модуль 95 готовых к оплате платежей, который хранит поставленные в очередь платежи. Как только платеж готов для выполнения, CPMS 10 инициирует платеж продавцу 93(например, через платежную систему 26). Например, CPMS 10 может инициировать платеж продавцу 93 через АСН.CPMS 10 также предоставляет жилищному застройщику 74 возможность осуществлять доступ к подписанному отказу от удержания. В некоторых вариантах осуществления, однако, CPMS 10 предотвращает просмотр подписи на отказе от удержания жилищным застройщиком 74 до тех пор, пока не подтвержден платеж продавцу 93. Как только платеж подтвержден, CPMS 10 также выдает квитанцию платежа (например, посредством уведомления) продавцу 93. В дополнение, CPMS 10 может создавать регистрационную запись платежа, которую CPMS 10 сохраняет внутри в модуле 96 платежей и выдает жилищному застройщику 74 (например, через внешнюю систему ERP или систему бухгалтерского учета-4 015031 жилищного застройщика 74). В некоторых вариантах осуществления регистрационная запись платежа может включать в себя регистрационную запись или файл АСН. Следует отметить, что CPMS 10, проиллюстрированная на фиг. 2, не включает в себя модуль 88 управления документами или модуль 90 управления соответствием стандартами. Поэтому CPMS 10,проиллюстрированная на фиг. 2, не предусматривает управления соответствием стандартами. Фиг. 3 иллюстрирует рабочий процесс CPMS 10, взаимодействующей с жилищным застройщиком 74 и одним или более продавцами 93, при этом CPMS 10 включает в себя модуль 88 управления документами и модуль 90 управления соответствием стандартами, а потому предусматривает управление соответствием стандартами. Должно быть понятно, что в некоторых вариантах осуществления CPMS 10 может включать в себя модуль 88 управления документами и модуль 90 управления соответствием стандартами, которые могут "включаться" и "выключаться", для того чтобы по выбору обеспечивать управление соответствием стандартами, по необходимости или по желанию.CPMS 10, показанная на фиг. 3, принимает требования к отказу от удержания проекта, как описано выше по фиг. 2. CPMS 10, однако, также получает требования к документам от жилищного застройщика 74. Требования к документам могут включать в себя список документов, которые жилищный застройщик 74 требует от продавца 93, предельные сроки для получения запрошенных документов, действия, которые должны быть предприняты, если запрошенные документы не были получены от конкретного продавца 93, и т.д. Например, жилищный застройщик 74 может определять правоприменительное действие для конкретного запрошенного документа. Правоприменительное действие определяет по меньшей мере одно действие, которое должно автоматически выполняться CPMS 10, если продавец 93 не предоставляет запрошенный документ. Например, правоприменительное действие может включать в себя действие"Только извещать", которое включает в себя автоматическое уведомление жилищного застройщика 74 и/или продавца 93 о недостающем документе. Правоприменительное действие также может включать в себя действие "Приостановить платеж", которое включает в себя автоматическую приостановку платежа продавцу 93, который не предоставляет запрошенный документ. Требования к документам или соответствию стандартам могут быть установлены на уровне организации и/или уровне проекта. В некоторых вариантах осуществления жилищный застройщик 74 может вводить требования к документам непосредственно в CPMS 10. В других вариантах осуществления жилищный застройщик 74 может загружать требования к документам в CPMS 10 через внешнюю систему(например, систему ERP) с использованием модуля 92 интерфейсов CPMS 10. После того как жилищный застройщик 74 выдает требования к документам в CPMS 10, продавец 93 может выгружать запрошенные документы в CPMS 10 для одобрения жилищным застройщиком 74. После того как жилищный застройщик 74 выдает отказ от удержания и требования к документам,жилищный застройщик 74 может снабжать CPMS 10 проектными платежными данными продавца через модуль 92 интерфейсов, как описано выше по фиг. 2. После того как жилищный застройщик 74 вводит платежные данные в CPMS 10, CPMS 10 приглашает продавца 93 (например, посредством уведомления) подписать отказ от удержания электронным образом и, как только продавец 93 подписывает отказ от удержания, сохраняет отказ от удержания в приемнике 68 электронного хранения. В этот момент в последовательности операций обмена отказом от удержания и платежом CPMS 10 также может приглашать продавцов 93 ввести любые недостающие документы соответствия стандартам, которые требуются до того, как продавец может принять платеж. По сравнению с процессом обмена, описанным выше по фиг. 2, если продавец 93 несовместим с требуемыми документами и жилищный застройщик 74 предпочел останавливать платежи, когда продавец 93 не соответствует стандартам, платеж для продавца не формируется автоматически, даже если продавец 93 подписывает запрошенный отказ от удержания. Когда продавец 93 соответствует стандартам требуемых документов, жилищный застройщик 74 обновляет статус требований соответствия стандартам, связанным с продавцом 93, и разблокирует все приостановленные платежи. Платеж затем ставится в очередь для выполнения, как описано выше по фиг. 2. Как только платеж готов для выполнения, CPMS 10 инициирует платеж продавцу 93 (например, через АСН). CPMS 10 также предоставляет жилищному застройщику 74 возможность осуществлять доступ к подписанному отказу от удержания. В некоторых вариантах осуществления, однако, CPMS 10 предотвращает просмотр подписи на отказе от удержания жилищным застройщиком 74 до тех пор, пока не подтвержден платеж продавцу 93. Как только платеж подтвержден, CPMS 10 выдает квитанцию платежа(например, посредством уведомления) продавцу 93. В дополнение, CPMS 10 может создавать регистрационную запись платежа для жилищного застройщика 74, как описано выше по фиг. 2. В дополнительных вариантах осуществления различные аспекты рабочего процесса, проиллюстрированного на фиг. 2 и 3, могут быть модифицированы или удалены в зависимости от конкретных нужд застройщика 74 и строительного проекта. Например, фиг. 4 и 5 иллюстрируют рабочие процессы обмена отказом от удержания, в которыхCPMS 10 не соединена непосредственно с платежной системой 26. Взамен застройщик 74 уведомляется системой, что отказ от удержания был сохранен в электронном промежуточном бункере 68. Застройщик 74 затем выполняет платеж вручную, например посредством выписки чека и физической его доставки продавцу. Застройщик 74 указывает CPMS 10, что платеж был произведен, и CPMS 10 продолжает рабо-5 015031 тать, как проиллюстрировано выше на фиг. 2 или 3. Фиг. 6-39 иллюстрируют обзор последовательностей операций управления платежом в строительстве, которые могут выполняться участниками 24 с использованием различных модулей, администраторов и устройств, хранимых на сервере 12 приложений. Фиг. 6 иллюстрирует процесс 97 управления проектом, который включает в себя процесс 98 интерфейса проект/контракт, процесс 99 создания проекта, процесс 100 поддержания контрактов и процесс 102 поддержания проектов. Фиг. 7 иллюстрирует процесс 104 управления организацией (который может выполняться модулем 42 организаций и/или модулем 50 пользователей), который включает в себя процесс 105 привлечения организации/пользователя, процесс 106 создания организации, процесс 108 поддержания организации,процесс 110 создания пользователя и процесс 112 поддержания пользователя. Фиг. 8 иллюстрирует процесс 106 создания организации, которая может быть включена в процесс 104 управления организацией. Процесс 106 создания организации может выполняться любым из участников 24 с использованием модуля 42 организаций. Процесс 106 создания организации включает в себя задачу 148 создания организации, задачу 150 обновления профиля организации, задачу 152 редактирования организации и задачу 156 активации организации. Задача 162 обновления профиля пользователя также может выполняться, как дополнительно описано по фиг. 22. Фиг. 9 иллюстрирует создание формы организации, которая может быть связана с задачей 148 создания организации. Один или более участников 24 могут осуществлять доступ к форме создания организаций через модуль 42 организаций. Участник 24 затем может вводить запрошенную информацию, такую как деловая информация, информация о первичном контакте, налоговая информация и банковская информация. Например, участник 24 может вводить наименование организации или компании, адрес,город, штат, почтовый индекс, округ, номер банковского счета, код банка, присваиваемый Американской банковской ассоциацией, и идентификационный номер федерального работодателя (FEIN). Участник 24 также может вводить информацию о пользователе, связанную с организацией, такую как имя пользователя (имя и фамилия), должность, адрес электронной почты и номер телефона. В некоторых вариантах осуществления первый пользователь участвующей организации 24, который вводит его или ее персональную информацию в качестве информации о пользователе, связанной с организацией, может считаться администратором для такого участника 24 и может быть наделен большим доступом к информации для участника, чем последующие пользователи. CPMS 10 может использовать всестороннюю основанную на ролях защиту, так что участники проекта видят только информацию, адаптированную к их специфичным нуждам в проекте. В некоторых вариантах осуществления, как только организация зарегистрирована в CPMS 10, организация может принимать платежи для любых проектов, управляемых посредством CPMS 10. Фиг. 10 иллюстрирует уведомление, которое может передаваться в течение задачи 162 обновления профиля пользователя. Если явно не изложено иное, термины "системное уведомление", "уведомление" или "системное сообщение" в качестве используемых в материалах настоящего изобретения и в прилагаемой формуле изобретения относятся к любой форме обмена информацией с участником 24, такой как сообщение электронной почты, экранное извещение, текстовое сообщение и голосовое сообщение и т.д. Системное уведомление по фиг. 8 включает в себя имя пользователя и временный пароль для первого пользователя участника 24. Фиг. 11 иллюстрирует уведомление, которое может передаваться в течение задачи 150 обновления профиля организации. Уведомление по фиг. 11 может отправляться администратору для участника 24. Уведомление включает в себя формулировку, запрашивающую, чтобы получатель обновил профиль организации, добавил пользователей перед участием в проекте и предоставил банковские подробности. Фиг. 12 иллюстрирует форму редактирования организации, которая может быть связана с задачей 152 редактирования организации. Каждый участник 24 может осуществлять доступ к форме редактирования организации через модуль 42 организаций. Участник 24 может модифицировать существующую информацию, такую как деловая информация, информация о первичном контакте, налоговая информация и банковская информация. В некоторых вариантах осуществления первый пользователь участвующей организации 24, который вводил его или ее информацию в качестве информации о пользователе,связанной с организацией, является единственным пользователем, наделенным доступом к форме редактирования организации. Фиг. 13 иллюстрирует уведомление активации организации, которое может передаваться в течение задачи 156 уведомления активации организации. Уведомление по фиг. 13 включает в себя подтверждение того, что подробности об организации были обновлены, и запрос о том, чтобы организация была проверена и активирована. Фиг. 14 иллюстрирует форму активации организации, которая может быть связана с задачей 156 активации организации. Форма по фиг. 14 включает в себя перечень участников 24 (например, включающий в себя наименование организации, ее роль в процессе строительства, возможность выбирать участников 24 и возможность просматривать информацию для участников 24). Форма по фиг. 14 также включает в себя признак "Найти", возможность задавать тип участника 24 и возможность откло-6 015031 нять/деактивировать выбранные организации и выдавать причину для отклонения/деактивации. Фиг. 15 иллюстрирует уведомление об активированной организации, которое может передаваться в течение задачи 160 уведомления об активированной организации. Подобным образом, фиг. 16 иллюстрирует уведомление о деактивированной организации, которое может передаваться в течение задачи 158 деактивированной организации. Фиг. 17 иллюстрирует процесс 108 поддержания организации, которая может быть включена в процесс 104 управления организациями. Процесс 108 поддержания организации может использоваться самими организациями или другими участниками для поддержки точности контактной информации, информации о банковском счете или любого другого типа информации, необходимой для процесса платежа в строительстве. Процесс 108 поддержания организации может выполняться участниками с использованием модуля 42 организаций. Процесс 108 поддержания организации по фиг. 17 включает в себя задачу 164 просмотра организаций, задачу 166 редактирования организации, задачу 168 уведомления об обновленной организации и задачу 120 просмотра организации. Фиг. 18 иллюстрирует экран просмотра организации, который может быть связан с задачей 120 просмотра организации. Экран просмотра организации включает в себя деловую информацию и информацию о первичном контакте для организации. Фиг. 19 иллюстрирует экран просмотра организаций, который может быть ассоциативно связан с задачей 164 просмотра организаций. Экран просмотра организаций включает в себя список участников,включающий в себя наименование организации, роль организации в процессе строительства, первичный контакт и номер телефона. Экран просмотра организаций также включает в себя признак "Найти" и ссылки для просмотра дополнительной информации о каждом участнике. В некоторых вариантах осуществления экран просмотра организаций может использоваться жилищным застройщиком для просмотра своих предпочтительных подрядчиков или поставщиков материалов. Фиг. 20 иллюстрирует форму редактирования организации, которая может быть связана с задачей 166 редактирования организации. Участник 24 может редактировать существующую информацию, такую как деловая информация, информация о первичном контакте, налоговая информация и банковская информация. В некоторых вариантах осуществления первый пользователь организации, который вводил его или ее информацию в качестве информации о первичном контакте, является единственным пользователем, наделенным доступом к форме редактирования организации. Фиг. 21 иллюстрирует уведомление об обновленном профиле организации, которое может передаваться в течение задачи 168 уведомления об обновленной организации. Уведомление по фиг. 21 включает в себя информацию касательно обновленного профиля для участника наряду с именем первого пользователя или администратора для участника. Фиг. 22 иллюстрирует процесс 172 создания пользователя, который может быть включен в процесс 104 управления организацией. Процесс 172 создания пользователя может использоваться каждый раз,когда создается новый пользователь в существующей организации, для того чтобы дать новому пользователю надлежащий доступ к CPMS 10 (например, надлежащие уровни защиты с идентификацией и паролем пользователя). Процесс 172 создания пользователя также может использоваться для обновления профилей пользователей. Процесс 172 создания пользователя может выполняться любым из участников 24 с использованием модуля 42 организаций. Процесс 172 создания пользователя по фиг. 22 включает в себя задачу 174 создания пользователя и задачу 176 уведомления об обновлении профиля пользователя. Фиг. 23 иллюстрирует форму создания пользователя, которая может быть связана с задачей 174 создания пользователя. В некоторых вариантах осуществления форма создания пользователя может использоваться для добавления пользователей после того, как первый пользователь или администратор уже был создан для участника. Новый пользователь может вводить персональную информацию, защитную информацию (например, имя и пароль пользователя), предпочтения уведомления по электронной почте и уровни категорий допуска (например, может ли пользователь управлять проектами и/или подписывать документы). Например, новый пользователь может вводить имя пользователя (например, имя и фамилию), должность, адрес электронной почты и номер телефона. Фиг. 24 иллюстрирует уведомление обновления профиля пользователя, которое может передаваться в течение задачи 176 уведомления обновления профиля пользователя. Уведомление по фиг. 24 включает в себя подтверждение того, что пользователь был добавлен в качестве члена организации, наряду с защитной информацией пользователя (например, именем пользователя и временным паролем). Фиг. 25 иллюстрирует процесс 178 поддержания пользователя, который может быть включен в процесс 104 управления организацией и может продолжаться с фиг. 22 в А. Процесс 178 поддержания пользователя может использоваться для просмотра пользователей в каждой организации и для просмотра, редактирования и обновления пользователей в каждой организации. Процесс 178 поддержания пользователя может выполняться любым из участников с использованием модуля 42 организаций. Процесс 178 поддержания пользователя по фиг. 25 включает в себя задачу 180 просмотра пользователей, задачу 182 редактирования пользователя, задачу 184 уведомления об обновленном профиле пользователя и задачу 186 просмотра пользователя.-7 015031 Фиг. 26 иллюстрирует экран представления пользователя, который может быть связан с задачей 186 представления пользователя. Экран представления пользователя по фиг. 26 включает в себя персональную информацию пользователя, предпочтение уведомления по электронной почте и уровень категории допуска. Фиг. 27 иллюстрирует экран представления пользователей, который может быть связан с задачей 180 представления пользователей. Экран представления пользователей по фиг. 27 включает в себя список из одного или более пользователей для каждого участника и может включать в себя имена, адреса электронной почты и номера телефонов пользователей. Экран представления пользователей также может включать в себя ссылки для редактирования информации для каждого пользователя. Фиг. 28 иллюстрирует форму редактирования пользователя, которая может быть связана с задачей 182 редактирования пользователя. Пользователь может предоставлять персональную информацию, предпочтения уведомления по электронной почте и уровни категорий допуска. Фиг. 29 иллюстрирует уведомление об обновленном профиле пользователя, которое может передаваться в течение задачи 184 уведомления об обновленном профиле пользователя. Возвращаясь к фиг. 6, первый этап процесса 97 управления проектами может включать в себя процесс 98 интерфейса проекта/контракта. Как описано выше по фиг. 2 и 3, процесс 98 интерфейса проект/контракт может включать в себя выгрузку данных проекта и/или данных контракта из внешней системы жилищного застройщика в CPMS 10 через модуль 92 интерфейсов. Например, данные проекта и данные контракта могут выгружаться в CPMS 10 из системы ERP жилищного застройщика 74. Фиг. 30 иллюстрирует процесс 99 создания проекта, который может быть включен в процесс 97 управления проектами. Процесс 99 создания проекта может выполняться жилищным застройщиком 74 с использованием модуля 28 проектов для инициации нового проекта в CPMS 10. Процесс 99 создания проекта по фиг. 30 включает в себя задачу 190 создания проекта, задачу 195 уведомления о создании проекта, задачу 196 доступа пользователей к проекту и задачу 197 обязанностей по проекту. В вариантах осуществления, которые включают в себя функциональные возможности соответствия стандартам документа, такие как описанные выше, задача 190 создания проекта дополнительно может включать в себя создание требований к соответствию стандартам проекта (задача 191), создание стандартов к утверждению проекта (задача 192), создание стандартов к документам проекта (задача 193) и/или создание других стандартов к проекту (задача 194). В некоторых вариантах осуществления CPMS 10 может инициировать новый проект на основании данных проекта и/или данных договора, выгруженных в CPMS 10 из внешней системы жилищного застройщика 74. В других вариантах осуществления вместо выгрузки данных или в дополнение к выгрузке данных в CPMS 10 жилищный застройщик может вручную вводить данные и/или выверять данные. Фиг. 31 и 32 иллюстрируют форму создания проекта, которая может быть связана с задачей 190 создания проекта. Жилищный застройщик 74 может использовать форму создания проекта по фиг. 31 и 32 для выдачи идентификационной информации проекта, информации о финансировании проекта, информации об ответственном за проект, информацию об архитекторе проекта и информацию о стройплощадке. Жилищный застройщик 74 также может использовать форму создания проекта по фиг. 31 и 32,чтобы проверять информацию о проекте и/или договоре, выгруженную из внешней системы. Например,жилищный застройщик 74 может использовать форму создания проекта по фиг. 31 и 32 для ввода и/или проверки шаблона документа для отказа от удержания, описания стройплощадки, адреса стройплощадки,состояния стройплощадки, округа стройплощадки, суммы договора и/или даты заключения договора. Фиг. 33 иллюстрирует форму создания соответствия стандартам. Жилищный застройщик 74 может использовать форму создания соответствия стандартам для идентификации ситуаций, в которых дополнительные документы, информация или одобрения требуются до того, как выполнен платеж. Жилищный застройщик 74 может указывать область действия требования (например, применяется ли требование к отдельному проекту, отдельному продавцу или субподрядчику или ко всем проектам и получателям платежей, связанным с жилищным застройщиком 74). Жилищный застройщик 74 может идентифицировать тип объекта (например, счет, чек, заявление под присягой или отказ от удержания) и может указывать требование, связанное с таким объектом. Жилищный застройщик 74 также может использоватьэту форму для указания периода времени, когда требование будет в действии, такого как дата вступления в силу,дата истечения срока действия или инициирующее событие. Жилищный застройщик 74 также может устанавливать предельные сроки для удовлетворения требований. Как описано выше при ссылке на фиг. 3, CPMS 10 может быть сконфигурирована для приостановки платежа до тех пор, пока не принят дополнительный документ. С использованием формы создания требований соответствия стандартам по фиг. 33 жилищный застройщик 74 может идентифицировать дополнительный документ и помечать галочкой элемент "Требуется для платежа". Форма создания требования соответствия стандартам также может использоваться для установки времени для отправки первого и второго уведомления об элементе, несоответствующем стандартам применимой стороне. К тому же, как описано выше при ссылке на фиг. 3, жилищный застройщик 74 может требовать,чтобы определенные запрошенные документы одобрялись до того, как выполнен платеж. С использованием формы создания требований соответствия стандартам по фиг. 33 жилищный застройщик 74 может-8 015031 идентифицировать документ ("Тип объекта") и устанавливать требование к одобрению. Форма создания требований соответствия стандартам по фиг. 33 также предоставляет жилищному застройщику 74 возможность настраивать процесс одобрения или идентифицировать многочисленных участников, которые должны одобрить документ, перед тем как выполнен платеж. Как только эти формы созданы, требования соответствия стандартам могут контролироваться и управляться через форму управления требованиями соответствия стандартам, такую как проиллюстрированная на фиг. 34. Жилищный застройщик 74 выбирает область действия и/или инициирующее событие,и отображается список всех применяемых требований соответствию стандартам. Жилищный застройщик 74 может добавлять, удалять или редактировать требования из этого списка. Фиг. 35 иллюстрирует созданное проектом уведомление, которое может передаваться во время задачи 195 создания проекта по фиг. 30. Уведомление по фиг. 35 включает в себя подтверждение того, что жилищный застройщик 74 создал новый проект, наряду со ссылкой на экран, который предоставляет пользователям возможность быть назначенными на проект. Фиг. 36 иллюстрирует процесс назначения ролей пользователей на проект и в некоторых вариантах осуществления может перекрываться с задачей 190 создания проекта и задачей 196 доступа пользователей к проекту по фиг. 30. Когда создается новый пользователь (этап 201), пользователь связывается с организацией (этап 203) и наделяется ролью в пределах такой организации (этап 205). Когда создается новый проект (этап 207) и пользователь назначен на такой проект (этап 209), система в этом примере автоматически связывает роль пользователя в пределах организации с ролью, которую пользователь будет иметь в проекте. Фиг. 37 иллюстрирует экран доступа пользователя по проекту, который может быть связан с задачей 196 доступа пользователя к проекту. Экран доступа пользователя к проекту включает в себя наименование проекта, номер проекта, наименование жилищного застройщика и список пользователей для конкретного проекта и/или конкретной организации. Пользователи могут идентифицироваться по имени или имени пользователя и в некоторых вариантах осуществления могут считаться руководителем проекта или подписантом. Этот экран отображает список пользователей, связанных с проектом в настоящее время, и соответственные роли, в настоящее время назначенные пользователям. Этот список пользователей и их назначенные роли могут модифицироваться с этого экрана. Например, если требование соответствия стандартам создано с помощью формы создания требований соответствия стандартам по фиг. 33,"Сэм Дженкинс" может быть назначен на роль "заключения о соответствии стандартам". Если создано требование, которое требует одобрения до того, как выполнен платеж, "Стиву Джонсону" может быть дана роль "одобряющего" для этого проекта. Когда роль или обязанность в проекте создается или изменяется, уведомление отправляется соответствующему пользователю. Фиг. 38 иллюстрирует уведомление об обязанностях по проекту, которое может передаваться во время задачи 197 уведомления об обязанностях по проекту по фиг. 30. Уведомление по фиг. 38 может включать в себя подтверждение, что обязанности пользователя по проекту были модифицированы. Как описано выше по фиг. 2 и 3, жилищный застройщик может использовать CPMS 10 для обмена платежами по подписанным электронным образом отказам от удержания. Фиг. 39 иллюстрирует процесс 200 обмена платежами по отказу от удержания, который может выполняться посредством CPMS 10. Как изложено выше в ссылке на примеры, проиллюстрированные на фиг. 2-5, хотя этот примерный застройщик 74 является жилищным застройщиком, функциональные возможности CPMS 10, описанные на фиг. 39, также могут применяться к застройщикам, занятым в нежилищном строительстве. Кроме того, хотя этот пример описывает обмен между жилищным застройщиком 74 и продавцом, второй участник также может иметь другой тип, такой как субподрядчик или поставщик материалов. Как показано на фиг. 39, для инициации обмена платежами по отказу от удержания CPMS 10 может создавать платежное поручение (этап 202) на основании информации, заданной жилищным застройщиком 74. Как описано выше по фиг. 2 и 3, жилищный застройщик 74 может вручную вводить информацию о платежах в CPMS 10 или информация о платежах может выгружаться из внешней системы жилищного застройщика 74 (например, системы ERP) через модуль 92 интерфейсов. Каждое платежное поручение,управляемое посредством CPMS 10, включает в себя информацию, которая связывает элемент статьи с надлежащим проектом и надлежащим контрактом, который должен быть оплачен. Информация о платеже, связанная с платежным поручением, может включать в себя наименование/разработку проекта, информацию об ответственном за проект, идентификатор проекта, идентификатор деловой операции, идентификатор договора и величину платежа. Платежные поручения затем сохраняются в CPMS 10 в контексте проекта и контракта, к которым они относятся. CPMS 10 поддерживает иерархию организаций/пользователей независимо от платежных операций. Иерархия предусматривает структуру для хранения платежей, а также структуру пользователей/полномочий, которая определяет, какое авторизованное лицо из любой данной организации предназначено для целей подписания и/или заверения, и которая управляет доступом к информации, управляемой посредством CPMS 10. Структуры данных проекта/договора также могут задавать информацию,-9 015031 требуемую для пополнения формы корректировки отказа от удержания для конкретного продавца 93. Как показано на фиг. 39, как только информация о платежном поручении принята CPMS 10, CPMS 10 соотносит платежное поручение с проектом и/или контрактом с использованием информации о проекте и контракте, полученной ранее от жилищного застройщика 74 (например, вручную от жилищного застройщика 74 или выгруженную из внешней системы жилищного застройщика 74) (этап 204). Продавец 93 затем уведомляется (например, посредством администратора 40 уведомлений), что следует подписать частичный или окончательный отказ от удержания с помощью устройства электронной подписи CPMS 10 (этап 206). CPMS 10 формирует необходимый отказ от удержания, и продавец 93 подписывает отказ от удержания электронным образом (этап 208). В некоторых вариантах осуществления CPMS 10 может формировать необходимые документы на основании шаблона отказа от удержания, заданного жилищным застройщиком 74 (например, вручную и/или выгруженного из внешней системы). Как только продавец 93 подписывает отказ от удержания, CPMS 10 сохраняет подписанный отказ от удержания в электронном промежуточном бункере/средстве 68 условного депонирования (этап 210). Как описано выше по фиг. 3, в некоторых вариантах осуществления CPMS 10, по выбору, может включать в себя модуль 88 управления документами и модуль 90 управления соответствием стандартам,который предоставляет CPMS 10 возможность обеспечивать управление соответствием стандартам. Например, когда CPMS 10 включает в себя модуль 88 управления документами и модуль 90 управления соответствием стандартам (или включает в себя активированные или "включенные" модуль 88 управления документами и модуль 90 управления соответствием стандартам), CPMS 10 может получать требования к документам от жилищного застройщика 74. Требования к документам могут включать в себя список документов, которые жилищный застройщик 74 требует от продавцов 93, предельные сроки для приема запрошенных документов, действия, которые должны быть предприняты, если запрошенные документы не были приняты от конкретного продавца 93, и т.д. В некоторых вариантах осуществления требования к документам или соответствию стандартам также предписывают шаблоны или стандарты для запрошенных документов. CPMS 10 может использовать шаблоны или стандарты для формирования запрошенных документов. Как описано выше, требования к документам или соответствию стандартам могут быть установлены на уровне организации и/или уровне проекта. В некоторых вариантах осуществления жилищный застройщик 74 может вводить требования к документам непосредственно в CPMS 10. В других вариантах осуществления жилищный застройщик 74 может загружать требования к документам в CPMS 10 через внешнюю систему (например, систему ERP) с использованием модуля 92 интерфейсов CPMS 10. После того как жилищный застройщик 74 выдает требования к документам в CPMS 10,продавец 93 может выгружать запрошенные документы в CPMS 10 для утверждения жилищным застройщиком 74. После того как жилищный застройщик 74 выдает требования к документам и платежные поручения или данные в CPMS 10, CPMS 10 может приглашать продавцов 93 ввести (подписать, заверить, представить на рассмотрение и т.д.) любые недостающие документы соответствия стандартам, которые требуются до того, как продавец может принимать платеж, в дополнение к приглашению продавца 93 подписать отказ от удержания. В некоторых вариантах осуществления CPMS 10 может формировать документы соответствия стандартам (например, на основании шаблонов и/или стандартов, заданных жилищным застройщиком 74) и может представлять сформированные документы продавцу 93 для утверждения и/или подписания. Поэтому, как показано на фиг. 39, если CPMS 10 обеспечивает управление соответствием стандартам, CPMS 10 может выполнять проверку соответствия стандартам перед инициацией платежа продавцу 93 (этап 212). Как описано выше по фиг. 3, если продавец 93 несовместим с требуемыми документами и жилищный застройщик 74 предпочел приостанавливать платежи, когда продавец 93 считается несовместимым, CPMS 10 может приостанавливать платеж продавцу (например, даже если продавец 93 подписывает запрошенный отказ от удержания). Как только отказ от удержания подписан и сохранен (этапы 208 и 210) и подтверждено соответствие продавца с требованиями к документам или иными требованиями (этап 212), подписанный отказ от удержания ставится в очередь на оплату (этап 214). В некоторых вариантах осуществления CPMS 10 автоматически оплачивает средства продавцу 93 через АСН или другую платежную сеть. После того как платеж поставлен в очередь и/или инициирован, CPMS 10 предоставляет жилищному застройщику 74 возможность просматривать подписанный отказ от удержания. Однако в некоторых вариантах осуществления, как описано выше, CPMS предотвращает просмотр подписи на отказе от удержания жилищным застройщиком 74 до тех пор, пока квитанция платежа продавцу не подтверждена АСН или другой платежной сетью (этап 216). После того как квитанция платежа была подтверждена, CPMS 10 выпускает подписанный отказ от удержания из бункера 68 (этап 218). В некоторых вариантах осуществления CPMS 10 также отправляет квитанцию платежа (посредством электронной почты или CPMS 10, например, администратора 40 уведомлений) продавцу 93. В дополнение, CPMS 10 отправляет жилищному застройщику 74 регистрационную запись платежа (этап 220). В других вариантах осуществления CPMS 10 передает регистрационную запись платежа во внешнюю систему жилищного застройщика 74 (например, систему ERP) через модуль- 10015031 92 интерфейсов. Хотя пример по фиг. 39 имеет отношение к жилищному застройщику, принимающему подписанный отказ от удержания от продавца, участники и документы могут меняться. Например, плательщик может быть владельцем имущества или застройщиком нежилых зданий, а получатель платежа может быть субподрядчиком или поставщиком материалов. Подобным образом, размещение платежа по этапу 214 может быть инициировано посредством автоматизированной расчетной палаты (АСН), как показано на фиг. 39, или посредством некоторой другой формы оплаты. Более того, этапы могут быть добавлены,удалены или размещены в иной очередности, чем та, которая показана на фиг. 39. Например, проверка соответствия стандартам на этапе 212 может быть удалена в некоторых системах или необязательной в некоторых проектах. Подобным образом, некоторые системы могут выпускать подписанный документ(этап 218) непосредственно после того, как инициирован платеж (этап 214), тем самым устраняя задержку этапа 216. Как описано выше по фиг. 2, CPMS 10 может быть сконфигурирована для поддержки среды "определенного выставления счетов" вместо или в дополнение к наличию конфигурации для поддержки среды"определенного платежа", как показано на фиг. 39. Например, вместо жилищного застройщика 74, определяющего платеж продавцу 93, как показано на фиг. 39, жилищный застройщик 74 может использоватьCPMS 10 для формирования счета для продавца 93, который включает в себя запрошенную сумму платежа. Продавец 93 может просматривать и одобрять или отклонять счет посредством CPMS 10, но не может модифицировать счет. Как только продавец 93 одобряет счет, CPMS 10 может приглашать продавца 93 подписать отказ от удержания, для того чтобы инициировать одобренный платеж. Как только продавец 93 подписывает отказ от удержания (и, необязательно, соответствует требованиям документа,определенными жилищным застройщиком 74), CPMS 10 инициирует платеж продавцу 93, как показано на фиг. 39. В дополнение, CPMS 10 может быть сконфигурирована для поддержки среды выставления счетов,при этом продавец 93 использует CPMS 10 для создания счета и представляет счет жилищному застройщику 74 для одобрения. Как только жилищный застройщик 74 одобряет счет, CPMS 10 приглашает продавца 93 подписать отказ от удержания, для того чтобы инициировать одобренный платеж. Как только продавец 93 подписывает отказ от удержания (и, необязательно, соответствует требованиям документа,определенным жилищным застройщиком 74), CPMS 10 инициирует платеж продавцу 93, как показано на фиг. 39. Должно быть понятно, что в некоторых вариантах осуществления проект жилищного строительства может включать в себя многочисленное имущество (например, участки под застройку в едином подразделении). Когда строительный проект включает в себя многочисленное имущество, CPMS 10 может инициировать единый платеж конкретному продавцу 93, при этом единый платеж покрывает многочисленное имущество или может инициировать отдельные платежи за каждое имущество. Подобным образом, CPMS 10 может формировать один отказ от удержания для конкретного продавца, который связан с многочисленным имуществом (например, отказ от удержания на подразделение), или может формировать отдельные отказы от удержания на каждое имущество (например, отказ от удержания на участок под застройку). Также должно быть понятно, что CPMS 10 может создавать проект, который включает в себя многочисленное имущество. Поэтому, когда продавец 93 регистрируется в CPMS 10 и/или проекте, продавец 93 автоматически регистрируется и является доступным для ассоциативного связывания с каждым имуществом, включенным в проект. В некоторых вариантах осуществления, как только продавец 93 зарегистрировался в CPMS 10, жилищный застройщик 74 может использовать CPMS 10 для назначения конкретных продавцов 93 на конкретные проекты. В некоторых вариантах осуществления CPMS 10 также может управлять бюджетами или перечнями стоимостей, связанными с конкретным проектом, имуществом, продавцом 93 и т.д. Например, жилищный застройщик 74 (и/или продавец 93) может вводить данные бюджета с использованием CPMS 10. Жилищный застройщик 74 может вручную вводить информацию о бюджете в CPMS 10 или CPMS 10 может получать информацию о бюджете из внешней системы жилищного застройщика 74 через модуль 92 интерфейсов. Как только CPMS 10 принимает информацию о бюджете, она может использовать информацию о бюджете для формирования документов (например, счетов, отказов от удержания и т.д.),выверять суммы платежей и т.д. Например, как описано выше по фиг. 2, в некоторых вариантах осуществления продавец 93 может использовать CPMS 10 для формирования и представления счета. Для формирования счета продавец 93 может задавать сумму платежа или долю завершенной работы в процентах. Если продавец 93 задает долю завершенной работы в процентах, CPMS 10 может автоматически формировать счет посредством расчета платежа на основании бюджетной суммы и заданной доли завершенной работы в процентах. CPMS 10 также может сверять сумму платежа, заданную жилищным застройщиком 74, с бюджетной суммой. Заявки на изменение в бюджет также могут выдаваться (например, вручную и/или загружаться из внешней системы через модуль 92 интерфейсов) и управляться (например, утверждаться) посредством CPMS 10. В некоторых вариантах осуществления CPMS 10 также может предоставлять инспектору возможность вводить контрольную информацию, такую как информация о доле за- 11015031 вершенной работы в процентах, которую CPMS 10 может использовать для формирования и/или проверки счетов, отказов от удержания, величины платежей и т.д. Специалистом в данной области техники должно осознаваться, что конструкции и способы, описанные выше, являются иллюстративными, а не ограничивающими. Другие конфигурации, конструкции и применения также возможны. Например, различные варианты осуществления CPMS могли бы применяться к "жилищному застройщику", занятому в строительстве жилых зданий, или застройщику, занятому в строительстве нежилых зданий. Более того, плательщик, например, может быть не застройщиком, а предпочтительнее банком или собственником имущества. В таких случаях застройщик 74 мог бы быть получателем платежа. Различные получатели платежа, например, также могут включать в себя продавцов, поставщиков материалов и субподрядчиков. К тому же, хотя вышеприведенные примеры описывают обмен отказом от удержания, может быть возможным применять этот обобщенный способ к другим типам документов. Различные признаки и преимущества изобретения изложены в последующей формуле изобретения. ФОРМУЛА ИЗОБРЕТЕНИЯ 1. Реализуемый компьютером способ выполнения платежа, относящегося к строительному проекту,состоящий в том, что создают регистрационную запись пользователя-получателя платежа для получателя платежа в машиночитаемой памяти; передают электронным образом электронное уведомление получателю платежа о предстоящем платеже и запрос на документ, подписанный электронным образом, от получателя платежа; отмечают регистрационную запись пользователя-получателя платежа как несоответствующую, если все запрошенные документы, в том числе запрошенный документ, подписанный электронным образом,не сохранены в машиночитаемой памяти; отмечают регистрационную запись пользователя-получателя платежа как соответствующую, если все запрошенные документы сохранены в машиночитаемой памяти; принимают документ, подписанный электронным образом, от получателя платежа; сохраняют документ, подписанный электронным образом, в машиночитаемой памяти и инициируют платеж, когда регистрационная запись пользователя-получателя платежа помечена как соответствующая. 2. Способ по п.1, состоящий в том, что дополнительно создают платежное поручение перед передачей электронного уведомления. 3. Способ по п.2, состоящий в том, что дополнительно согласуют платежное поручение с проектом. 4. Способ по п.1, состоящий в том, что дополнительно выдают документ, подписанный электронным образом, плательщику только после того, как был инициирован платеж. 5. Способ по п.1, в котором действие по инициации платежа выполняется процессором компьютера автоматически по получению документа, подписанного электронным образом, от получателя платежа. 6. Способ по п.1, в котором дополнительно определяют список требуемой информации, которая должна быть сохранена в машиночитаемой памяти, перед тем, как будет инициирован платеж, при этом список требуемой информации включает в себя все запрошенные документы; передают электронным образом второе уведомление получателю платежа, идентифицирующее, какая требуемая информация в настоящее время не сохранена в машиночитаемой памяти; и отмечают регистрационную запись пользователя-получателя платежа как соответствующую после подтверждения, что вся требуемая информация сохранена в машиночитаемой памяти. 7. Способ по п.6, в котором список требуемой информации включает в себя по меньшей мере один предварительно запрошенный документ, подписанный электронным образом. 8. Способ по п.1, состоящий в том, что дополнительно принимают настройку соответствия стандартам от плательщика, указывающую, следует ли задерживать действие по инициации платежа до тех пор,пока регистрационная запись пользователя-получателя платежа не помечена как соответствующая. 9. Способ по п.1, состоящий в том, что дополнительно принимают электронное платежное требование от получателя платежа; отображают платежное требование плательщику и принимают одобрение от плательщика платежного требования,при этом действие по созданию платежного поручения выполняется в ответ на прием одобрения платежного требования. 10. Способ по п.1, в котором электронное уведомление о предстоящем платеже включает в себя электронный счет. 11. Способ по п.1, в котором действие по инициации платежа заключается в том, что электронным образом поддерживают связь с автоматизированной расчетной палатой. 12. Способ по п.1, в котором действие по инициации платежа заключается в том, что автоматически- 12015031 выполняют электронный перевод средств. 13. Способ по п.1, в котором действие по инициации платежа заключается в том, что печатают чек,который должен быть доставлен получателю платежа. 14. Способ по п.1, состоящий в том, что дополнительно формируют электронную квитанцию и передают квитанцию получателю платежа. 15. Способ по п.1, состоящий в том, что дополнительно формируют регистрационную запись электронного платежа и передают регистрационную запись электронного платежа плательщику. 16. Способ по п.1, в котором плательщик является генеральным подрядчиком. 17. Способ по п.1, в котором получатель платежа является субподрядчиком или поставщиком строительных материалов. 18. Способ по п.1, в котором документ, подписанный электронным образом, является отказом от удержания. 19. Система управления платежом в строительстве, содержащая по меньшей мере одну машиночитаемую память; задействованный программным обеспечением пользовательский интерфейс и процессор, сконфигурированный для создания регистрационной записи пользователя-получателя платежа по меньшей мере в одной машиночитаемой памяти; отображения получателю платежа посредством пользовательского интерфейса электронного уведомления о предстоящем платеже и запроса на документ, подписанный электронным образом; отметки регистрационной записи пользователя-получателя платежа как несоответствующей, если все запрошенные документы, в том числе запрошенный документ, подписанный электронным образом,не сохранены по меньшей мере в одной машиночитаемой памяти; отметки регистрационной записи пользователя-получателя платежа как соответствующей, если все запрошенные документы сохранены по меньшей мере в одной машиночитаемой памяти; приема посредством пользовательского интерфейса документа, подписанного электронным образом от получателя платежа; сохранения документа, подписанного электронным образом, по меньшей мере в одной машиночитаемой памяти и инициации платежа, когда регистрационная запись пользователя-получателя платежа помечена как соответствующая. 20. Система управления платежа в строительстве по п.19, в которой процессор дополнительно сконфигурирован для создания платежного поручения перед отображением электронного уведомления о предстоящем платеже. 21. Система управления платежом в строительстве по п.19, в которой задействованный программным обеспечением пользовательский интерфейс является видимым на устройстве отображения и редактируемым через клавиатуру, причем устройство отображения и клавиатура являются удаленными от системы управления платежом в строительстве и связанными с получателем платежа. 22. Система управления платежом в строительстве по п.19, в которой задействованный программным обеспечением пользовательский интерфейс доступен на множестве сетевых компьютерных терминалов. 23. Система управления платежом в строительстве по п.22, в которой задействованный программным обеспечением пользовательский интерфейс является основанным на веб-технологиях приложением,доступным на множестве компьютерных терминалов, присоединенных к сети Интернет. 24. Система управления платежом в строительстве по п.19, в которой процессор дополнительно сконфигурирован для согласования платежного поручения с проектом. 25. Система управления платежом в строительстве по п.19, в которой процессор дополнительно сконфигурирован для отображения документа, подписанного электронным образом, плательщику посредством пользовательского интерфейса только после того, как был инициирован платеж. 26. Система управления платежом в строительстве по п.19, в которой процессор сконфигурирован для автоматической инициации платежа при получении документа, подписанного электронным образом. 27. Система управления платежом в строительстве по п.19, в которой процессор дополнительно сконфигурирован для осуществления доступа к списку, указывающему, какие данные должны быть сохранены по меньшей мере в одной машиночитаемой памяти перед тем, как регистрационная запись пользователяполучателя платежа будет отмечена в качестве совместимой; отображения второго уведомления получателю платежа через пользовательский интерфейс, описывающего, какие данные из списка в настоящее время не сохранены в машиночитаемой памяти; и отметки регистрационной записи пользователя-получателя платежа в качестве совместимой после подтверждения, что все данные из списка сохранены по меньшей мере в одной машиночитаемой памяти. 28. Система управления платежом в строительстве по п.27, в которой список включает в себя по меньшей мере один предварительно запрошенный документ, подписанный электронным образом.- 13015031 29. Система управления платежом в строительстве по п.19, в которой процессор дополнительно сконфигурирован для создания регистрационной записи пользователя-получателя платежа по меньшей мере в одной машиночитаемой памяти; отметки регистрационной записи пользователя-получателя платежа как несоответствующей, если запрошенный документ не сохранен по меньшей мере в одной машиночитаемой памяти; и отметки регистрационной записи пользователя-получателя платежа в качестве соответствующей,если все запрошенные документы сохранены по меньшей мере в одной машиночитаемой памяти. 30. Система управления платежом в строительстве по п.29, в которой процессор дополнительно сконфигурирован для приема настройки соответствия стандартам от плательщика, указывающей, следует ли задерживать действие по инициации платежа до тех пор, пока регистрационная запись пользователяполучателя платежа не помечена как соответствующей. 31. Система управления платежом в строительстве по п.19, в которой процессор дополнительно сконфигурирован для приема электронного платежного требования от получателя платежа посредством пользовательского интерфейса; отображения платежного требования плательщику посредством пользовательского интерфейса и приема одобрения платежного требования от плательщика посредством пользовательского интерфейса перед созданием платежного поручения. 32. Система управления платежом в строительстве по п.19, в которой электронное уведомление о предстоящем платеже включает в себя электронный счет. 33. Система управления платежом в строительстве по п.19, дополнительно содержащая интерфейс связи между процессором и автоматизированной расчетной палатой, при этом процессор сконфигурирован для инициации платежа посредством автоматизированной расчетной палаты посредством интерфейса связи. 34. Система управления платежом в строительстве по п.33, в которой интерфейс связи включает в себя телефонную линию. 35. Система управления платежом в строительстве по п.33, в которой интерфейс связи включает в себя соединение сети Интернет. 36. Система управления платежом в строительстве по п.19, дополнительно содержащая электронный интерфейс между процессором и банком, при этом процессор сконфигурирован для инициации платежа посредством запроса электронного перевода средств в банке. 37. Система управления платежом в строительстве по п.19, дополнительно содержащая принтер,при этом процессор сконфигурирован для инициации платежа посредством печати чека, подлежащего оплате получателю платежа. 38. Система управления платежом в строительстве по п.19, в которой процессор сконфигурирован для инициации платежа посредством отображения инструкций платежа плательщику посредством пользовательского интерфейса. 39. Система управления платежом в строительстве по п.19, в которой процессор дополнительно сконфигурирован для формирования электронной квитанции и отображения квитанции получателю платежа посредством пользовательского интерфейса. 40. Система управления платежом в строительстве по п.39, в которой процессор дополнительно сконфигурирован для сохранения электронной квитанции по меньшей мере в одной машиночитаемой памяти. 41. Система управления платежом в строительстве по п.19, в которой процессор дополнительно сконфигурирован для формирования регистрационной записи электронного платежа и отображения регистрационной записи электронного платежа плательщику посредством пользовательского интерфейса. 42. Система управления платежом в строительстве по п.41, в которой процессор дополнительно сконфигурирован для сохранения регистрационной записи электронного платежа по меньшей мере в одной машиночитаемой памяти. 43. Система управления платежом в строительстве по п.19, в которой плательщик является генеральным подрядчиком. 44. Система управления платежом в строительстве по п.19, в которой получатель платежа является субподрядчиком или поставщиком снабжения. 45. Система управления платежом в строительстве по п.19, в которой документ, подписанный электронным образом, является отказом от удержания. 46. Система управления платежом в строительстве, содержащая по меньшей мере одну машиночитаемую память; задействованный программным обеспечением пользовательский интерфейс и процессор, сконфигурированный для создания платежного поручения; отображения получателю платежа посредством пользовательского интерфейса электронного уве- 14015031 домления о предстоящем платеже и запроса на документ, подписанного электронным образом; приема документа, подписанного электронным образом, от получателя платежа посредством пользовательского интерфейса; сохранения документа, подписанного электронным образом, по меньшей мере в одной машиночитаемой памяти и временного предотвращения от осуществления доступа плательщика к документу, подписанному электронным образом; приема подтверждения от плательщика посредством пользовательского интерфейса, что платеж был инициирован; и предоставления плательщику возможности осуществлять доступ к документу, подписанному электронным образом. 47. Реализуемый компьютером способ выполнения платежа в строительном проекте, состоящий в том, что создают платежное поручение; передают электронным образом электронное уведомление получателю платежа о предстоящем платеже и запрос документа, подписанного электронным образом, от получателя платежа; принимают документ, подписанный электронным образом, от получателя платежа; сохраняют документ, подписанный электронным образом, в машиночитаемой памяти; временно предотвращают доступ плательщика к документу, подписанному электронным образом; принимают подтверждение от плательщика, что платеж был инициирован; и предоставляют плательщику возможность осуществлять доступ к документу, подписанному электронным образом. 48. Способ по п.47, состоящий в том, что дополнительно инициируют платеж посредством чека. 49. Способ по п.47, состоящий в том, что дополнительно инициируют платеж посредством банковского перевода.