Система и способ управления платежом в строительстве
Номер патента: 11312
Опубликовано: 27.02.2009
Авторы: Флинн Майкл Л., Педерсен Ричард П.Мл., Багли Мэттью Р., Эйкхорн Уилльям Х., Черри Чарльз К., Найден Ховард Л., Аллин Патрик Дж.
Формула / Реферат
1. Способ управления процессом платежа в строительстве, включающий в себя действия по
выработке бюджета для строительного проекта посредством по меньшей мере одной электронной формы;
получению величины счета от по меньшей мере одного участника строительного проекта посредством по меньшей мере одной компьютерной сети;
выработке по меньшей мере одного из автоматизированного счета и автоматизированного заявления под присягой на основании величины счета и бюджета;
выработке по меньшей мере одного автоматизированного отказа от удержания на основании по меньшей мере одного из автоматизированного счета и автоматизированного заявления под присягой;
электронному выполнению по меньшей мере одного из автоматизированного счета и автоматизированного заявления под присягой и по меньшей мере одного автоматизированного отказа от удержания для создания по меньшей мере одного из юридически обязывающего счета, юридически обязывающего заявления под присягой и юридически обязывающего отказа от удержания.
2. Способ по п.1, дополнительно включающий в себя действие по передаче уведомления в отношении одобрения автоматизированного счета.
3. Способ по п.1, в котором выработанный бюджет включает в себя множество статей, а выработанный автоматизированный счет включает в себя по меньшей мере одну из множества статей.
4. Способ по п.1, в котором выработанный бюджет включает в себя по меньшей мере одну из стоимостей от организации, не нанятой генеральным подрядчиком строительного проекта, и стоимостей организации, нанятой генеральным подрядчиком.
5. Способ по п.1, дополнительно включающий в себя действие по обеспечению того, что автоматизированное заявление под присягой и по меньшей мере один автоматизированный отказ от удержания соответствуют по меньшей мере одному автоматизированному счету.
6. Способ по п.1, дополнительно включающий в себя действие по обеспечению того, что сумма величин в долларах по счету, содержащаяся в автоматизированном счете, равна величине в долларах по заявлению под присягой, содержащейся в автоматизированном заявлении под присягой.
7. Способ по п.1, дополнительно включающий в себя действие по обеспечению того, что величина в долларах по счету, содержащаяся в автоматизированном счете, равна величине в долларах по отказу от удержания, содержащейся по меньшей мере в одном автоматизированном отказе от удержания.
8. Способ по п.1, в котором действия по выработке по меньшей мере одного из автоматизированного счета и автоматизированного заявления под присягой и выработке по меньшей мере одного автоматизированного отказа от удержания включает в себя выработку автоматизированного счета, одобрение автоматизированного счета, последующую выработку автоматизированного заявления под присягой, одобрение автоматизированного заявления под присягой и последующую выработку по меньшей мере одного отказа от удержания.
9. Способ по п.1, дополнительно включающий в себя действие по автоматическому снятию юридически обязывающего отказа от удержания после получения участником платежа от платежной системы.
10. Система управления платежом в строительстве, включающая в себя сервер приложений, сохраняющий электронный промежуточный бункер и модуль выделения средств, причем электронный промежуточный бункер получает отказ от удержания от участника строительного проекта, а модуль выделения средств передает платеж участнику в ответ на получение отказа от удержания и снимает отказ от удержания в ответ на платеж.
11. Система управления платежом в строительстве по п.10, в которой электронный промежуточный бункер сохраняет отказ от удержания.
12. Система управления платежом в строительстве по п.10, в которой модуль выделения средств передает платеж участнику посредством передачи платежной системе автоматизированной инструкции - заплатить участнику.
13. Система управления платежом в строительстве по п.12, в которой модуль выделения средств снимает отказ от удержания посредством получения формы подтверждения от платежной системы, что участник получил фонды и, по существу, одновременно снимает отказ от удержания после получения подтверждения.
14. Система управления платежом в строительстве по п.10, в которой электронный промежуточный бункер получает множество отказов от удержания от множества участников и сохраняет каждый из множества отказов от удержания, пока не получено все множество отказов от удержания; причем модуль выделения средств передает автоматизированную инструкцию - заплатить множеству участников, когда получено все множество отказов от удержания.
15. Система управления платежом в строительстве по п.10, в которой электронный промежуточный бункер получает множество отказов от удержания от множества участников и сохраняет каждый из множества отказов от удержания, а модуль выделения средств передает автоматизированную инструкцию - заплатить каждому из множества участников, когда получен каждый из множества отказов от удержания.
16. Система управления платежом в строительстве по п.10, в которой электронный промежуточный бункер получает множество отказов от удержания от множества участников и сохраняет каждый из множества отказов от удержания, а модуль выделения средств передает первую инструкцию - заплатить по меньшей мере одному из множества участников, когда получен по меньшей мере один из множества отказов от удержания, и вторую инструкцию - заплатить по меньшей мере одному другому из множества участников, когда получено все множество отказов от удержания.
17. Система управления платежом в строительстве по п.12, в которой платежная система включает в себя по меньшей мере одно из автоматизированной системы расчетной палаты, системы банковского перевода, системы дебетовой карты и системы кредитной карты.
18. Система управления платежом в строительстве по п.10, в которой электронный промежуточный бункер и модуль выделения средств получают и снимают отказ от удержания, соответствующий работе, выполненной для текущего выделения средств.
19. Система управления платежом в строительстве по п.10, в которой сервер приложений сохраняет модуль бюджета, вырабатывающий бюджет для строительного проекта и модуль выделения средств, вырабатывающий по меньшей мере один автоматизированный счет, автоматизированное заявление под присягой и по меньшей мере один автоматизированный отказ от удержания на основании бюджета.
20. Система управления платежом в строительстве по п.10, дополнительно включающая в себя службу электронной подписи для выполнения электронным образом отказа от удержания.
Текст
011312 Приоритет истребуется по Пар.119 Раздела 35 СЗ США. 119 на основании заявки, регистрационный номер 60/583,782, на выдачу патента США, поданной 29 июня 2004. Уровень техники Проекты жилого и коммерческого строительства требуют, чтобы несколько организаций взаимодействовали друг с другом для распределения платежей. Обычный процесс управления платежом в строительстве начинается с устного уведомления, что будет иметь место выделение средств со строительного кредита или счета владельца собственности. Генеральный подрядчик (ГП) строительного проекта уведомляет по телефону, факсу или на совещании субподрядчиков (или любых других лиц, фирму или корпорацию, задействованные ГП, таких как поставщиков материалов) о выделении средств. Субподрядчики подготавливают счета и посылают их ГП почтой, факсом, курьерской доставкой или передают на совещании с ГП. ГП и субподрядчики часто должны договариваться о величине в долларах финального счета по телефону или на встречах. ГП подтверждает счета, вводит реквизиты в бухгалтерскую систему проекта ГП и готовит свой собственный счет. Как только счета окончательно сформированы, ГП также вручную готовит заявление под присягой. В заявлении под присягой ГП подтверждает, что субподрядчики, задействованные ГП, выполнили конкретные услуги по строительству или ремонту собственности. В заявлении под присягой, ГП также подтверждает величину в долларах, на которую имеет право каждый субподрядчик. ГП направляет выполненное заявление под присягой титульной компании и заимодателю (кредитору строительного займа (кредита и/или владельцу собственности. Заимодатель, владелец собственности или титульная компания уведомляет инспектора, что должен быть выполнен осмотр собственности, и посылает инспектору заявление под присягой. Инспектор собирает предыдущие отчеты инспекции по собственности. Инспектор производит новую инспекцию и вручную готовит отчет инспекции. Инспектор передает отчет инспекции заимодателю, владельцу собственности и/или титульной компании посредством факса, почты или курьерской доставкой. Заимодатель, владелец собственности и/или титульная компания получают заявление под присягой и отчет инспекции по почте, факсу, при курьерской доставке или на встрече с ГП и/или инспектором. Заимодатель, владелец собственности и/или титульная компания должны обратиться к предшествующему выделению средств и проектной документации. Заимодатель, владелец собственности и/или титульная компания часто должны договариваться о величинах оплаты и деталях проекта с ГП по телефону, с использованием факса или на встрече. Заимодатель, владелец собственности и/или титульная компания одобряют заявление под присягой и передают одобрение по телефону, с использованием факса или на встрече. Заимодатель или владелец собственности затем одобряют расходование величины в долларах,определенной в заявлении под присягой. Заимодатель строительного займа или банк владельца собственности обычно передают фонды, необходимые для оплаты всем субподрядчикам, на счет условного депонирования. Часто титульная компания после этого выплачивает ГП фонды со счета условного депонирования. ГП и/или титульная компания готовят чеки для субподрядчиков. В это время, субподрядчики в основном осуществляют отказы от удержания по предыдущему выделению фондов из строительного кредита или для работы, завершенной в течение предыдущего месяца. В результате отказы от удержания по текущему выделению средств или текущему месяцу фактически не снимаются, пока не будет произведено последующее выделение средств из строительного кредита, или до следующего месяца. Кроме того, субподрядчики могут иметь своих собственных субподрядчиков, которым они должны заплатить после получения платежа от ГП. Обычный процесс платежа в строительстве может занять 90 дней или дольше от даты устного уведомления о выделения средств до той даты, когда субподрядчики фактически получат платеж. Обычный процесс платежа в строительстве, как правило, предполагает ненадежное устное уведомление о событиях, от которого зависит ход процесса. Например, если один субподрядчик недоступен для подготовки счета или представления отказа от удержания, процесс платежа для всех других субподрядчиков может быть задержан. Обычный процесс платежа в строительстве также предполагает огромные объемы ввода данных. Например, для одного большого строительного проекта, ГП часто должен вводить сотни счетов в свою бухгалтерскую систему каждый месяц. Кроме того, ГП каждый месяц должен собирать сотни отказов от удержания. Дополнительно, ГП должен каждый месяц готовить, одобрять, подписывать и распределять сотни чеков субподрядчикам. Далее, ГП должен сохранять все бумажные документы, собранные в ходе каждого процесса выделения средств. Согласование уведомлений о выделении средств, одобрений и обменов отказами от удержания для платежа требует сотен факсов, телефонных звонков и встреч ежемесячно. Сущность изобретения Варианты осуществления изобретения обеспечивают систему и способ для управления процессом платежа в строительстве. Один способ осуществления изобретения может включать в себя получение информации регистрации для участника, хранение информации регистрации и перевод участнику платежа, связанного со строительным проектом, посредством выполнения доступа к информации регистрации. Система управления платежом в строительстве, осуществляющая изобретение, может включать в-1 011312 себя сервер приложений, который сохраняет модуль организации, и систему управления базами данных,модуль организации получает информации регистрации организации для участника. Система может также включать в себя сервер баз данных, связанный с системой управления базами данных, причем сервер баз данных сохраняет информацию регистрации организации, а система управления базами данных выполняет доступ к информации регистрации информации организации, для передачи участнику платежа,связанного со строительным проектом. Другая система управления платежом в строительстве, осуществляющая изобретение, может включать в себя сервер приложений, который сохраняет модуль организации и систему управления базами данных, причем модуль организации получает информацию регистрации организации от участника. Система может также включать в себя сервер баз данных, связанный с системой управления базами данных,причем сервер баз данных сохраняет информацию регистрации организации, а система управления базами данных выполняет доступ к информации регистрации организации, для передачи участнику платежа,связанного со строительным проектом. Один способ осуществления изобретение может включать в себя установление связи со множеством участников строительного проекта, выработку уведомления о выделении средств и передачу электронным образом в реальном времени уведомления множеству участников. Другая система, осуществляющая изобретение, может включать в себя сервер приложений, на котором хранится администратор уведомлений и модуль выделения средств, причем администратор уведомлений и модуль выделения средств вырабатывают уведомление о выделении средств, и администратор уведомлений электронным образом передает в реальном времени уведомление множеству участников. Некоторые варианты осуществления изобретения включают в себя выработку бюджета для строительного проекта и выработку по меньшей мере одного автоматизированного счета, автоматизированного заявления под присягой и по меньшей мере одного автоматизированного отказа от удержания на основании бюджета. Один вариант осуществления изобретения включает в себя получение по меньшей мере одного счета от по меньшей мере одного субподрядчика и автоматическую выработку заявления под присягой генерального подрядчика, включающего в себя величину в долларах каждого по меньшей мере из одного счета. Еще одна другая система, осуществляющая изобретение, может включать в себя сервер приложений, который сохраняет модуль бюджета и модуль выделения средств, причем модуль бюджета, вырабатывает бюджет для строительного проекта, модуль выделения средств вырабатывает по меньшей мере один автоматизированный счет, автоматизированное заявление под присягой и по меньшей мере один автоматизированный отказ от удержания на основании бюджета. Другой способ по изобретению включает в себя получение отказа от удержания от участника строительного проекта, сохранение отказа от удержания, передачу платежной системе инструкции заплатить участнику и получение от платежной системы подтверждения, что участник получил фонды и,по существу, одновременное снятие отказа от удержания. Еще один способ по изобретению включает в себя получение отказа от удержания от участника строительного проекта и передачу платежной системе инструкции заплатить участнику и, по существу,одновременное снятие отказа от удержания. Еще одна другая система, осуществляющая изобретение, включает в себя сервер приложений, сохраняющий электронный промежуточный бункер и модуль выделения средств, причем электронный промежуточный бункер получает и сохраняет отказ от удержания от участника строительного проекта,модуль выделения средств вырабатывает и передает платежной системе автоматизированную инструкцию заплатить участнику, модуль выделения средств получает от платежной системы подтверждение,что участник получил капитал и, по существу, одновременно снимает отказ от удержания. Еще один способ по изобретению включает в себя создание первичного бюджета для строительного проекта, включающего в себя по меньшей мере один вторичный бюджет по меньшей мере от одного из генерального подрядчика по меньшей мере одного субподрядчика, и по меньшей мере одного поставщика материалов, причем по меньшей мере один из вторичных бюджетов, каждый включает в себя по меньшей мере одну статью; и согласование первичного бюджета и по меньшей мере одного вторичного бюджета, включающего в себя по меньшей мере одну статью, перед управлением выделением средств. Программное обеспечение, осуществляющее изобретение, может включать в себя модуль проекта для создания и управления проектом, модуль бюджета для создания и поддержания бюджета для проекта и модуль выделения средств для создания, планирования и управления выделениями средств для проекта на основании бюджета. Графический пользовательский интерфейс, осуществляющий изобретение, может включать в себя по меньшей мере один из следующих элементов: индикатор хода расписания проекта, индикатор хода расходования фондов и индикатор хода процентного завершения, причем индикатор хода расписания проекта указывает ход в отношении календарных дат, индикатор хода расходования фондов указывает ход в отношении величины в долларах бюджета, и индикатора хода процентного завершения указывает-2 011312 ход в отношении процента работы, законченной по строительному проекту. Краткое описание чертежей Фиг. 1 - схематическая иллюстрация системы управления платежом в строительстве, в соответствии с одним вариантом осуществления изобретения. Фиг. 2 - схематическая иллюстрация процессов управления платежом в строительстве, которые могут быть выполнены с использованием системы по фиг. 1. Фиг. 3 - схематическая иллюстрация процесса управления проектом. Фиг. 4 - схематическая иллюстрация процесса управления организацией. Фиг. 5 - схематическая иллюстрация процесса управления выделением средств. Фиг. 6 - схематическая иллюстрация процесса управления распоряжением об изменении. Фиг. 7 - схематическая иллюстрация задач управления системным окружением. Фиг. 8 - схематическая иллюстрация процесса создания организации. Фиг. 9 - иллюстрация создания формы организации. Фиг. 10 - иллюстрация уведомления обновления системы пользователя. Фиг. 11 - иллюстрация системного уведомления. Фиг. 12 - иллюстрация формы редактирования организации. Фиг. 13 - иллюстрация уведомления активации организации. Фиг. 14 - иллюстрация формы активации организации. Фиг. 15 - иллюстрация уведомления об активированной организации. Фиг. 16 - иллюстрация уведомления о деактивировании организации. Фиг. 17 - схематическая иллюстрация процесса поддержания организации. Фиг. 18 - иллюстрация экрана представления организации. Фиг. 19 - иллюстрация экрана просмотра организации. Фиг. 20 - иллюстрация формы редактирования организации. Фиг. 21 - иллюстрация уведомления об обновленном профиле организации. Фиг. 22 - схематическая иллюстрация процесса 172 создания пользователя. Фиг. 23 - иллюстрация формы создания пользователя. Фиг. 24 - иллюстрация уведомления обновления профиля пользователя. Фиг. 25 - схематическая иллюстрация процесса поддержания пользователя. Фиг. 26 - иллюстрация экрана представления пользователя. Фиг. 27 - иллюстрация просмотра экрана пользователей. Фиг. 28 - иллюстрация формы редактирования пользователя. Фиг. 29 - иллюстрация уведомления об обновленном профиле пользователя. Фиг. 30 - схематическая иллюстрация процесса создания проекта. Фиг. 31 и 32 - иллюстрации формы создания проекта. Фиг. 33 - иллюстрация уведомления о созданном проекте. Фиг. 34 - иллюстрация экрана доступа пользователя по проекту. Фиг. 35 - иллюстрация уведомления об обязанностях по проекту. Фиг. 36 - схематическая иллюстрация процесса поддержания бюджета. Фиг. 37 - иллюстрация формы ввода бюджета высокого уровня. Фиг. 38 - иллюстрация формы ввода дат выделения средств. Фиг. 39 - иллюстрация формы установки кода счета. Фиг. 40 - иллюстрация формы присвоения кодов счета. Фиг. 41 - иллюстрация уведомления принятия проекта. Фиг. 42 - иллюстрация формы принятия проекта. Фиг. 43 - иллюстрация уведомления об отклоненном проекте. Фиг. 44 - иллюстрация уведомления о принятом проекте. Фиг. 45 - иллюстрация домашней страницы проекта. Фиг. 46 - иллюстрация уведомления добавления пользователей. Фиг. 47 - иллюстрация формы доступа пользователя по проекту. Фиг. 48 - иллюстрация уведомления об обязанностях по проекту. Фиг. 49 - иллюстрация экрана представления бюджета проекта. Фиг. 50 - иллюстрация формы ввода бюджета. Фиг. 51 - схематическая иллюстрация процесса прекращения статьи бюджета. Фиг. 52 - иллюстрация формы ввода бюджета высокого уровня. Фиг. 53 - иллюстрация экрана прекращения бюджета. Фиг. 54 - схематическая иллюстрация процесса выделения средств. Фиг. 55 - иллюстрация уведомления о создании запланированного выделения средств. Фиг. 56 - иллюстрация формы инициирования выделения средств. Фиг. 57 - иллюстрация уведомления о вводе счета. Фиг. 58 - иллюстрация формы ввода счета. Фиг. 59 - иллюстрация уведомления о подписи счета.-3 011312 Фиг. 60 - иллюстрация формы подписи счета. Фиг. 61 - иллюстрация уведомления об обновленных деталях счета. Фиг. 62 - иллюстрация экрана представления находящегося на рассмотрении запроса выделения средств. Фиг. 63 - иллюстрация уведомления об отклоненных деталях счета. Фиг. 64 - иллюстрация счета, не включенного в уведомление о выделении средств. Фиг. 65 - иллюстрация автоматически выработанной формы счета. Фиг. 66 - иллюстрация формы заявления под присягой. Фиг. 67 - иллюстрация уведомления о сделанных доступными фондах. Фиг. 68 - иллюстрация экрана представления запроса выделения средств. Фиг. 69 - иллюстрация уведомления о подписанном отказе от удержания. Фиг. 70 - иллюстрация формы отказа от удержания. Фиг. 71 - иллюстрация уведомления о подписанном отказе от удержания. Фиг. 72 - иллюстрация экрана представления запроса выделения средств. Фиг. 73 - иллюстрация уведомления о подписании всех отказов от удержания. Фиг. 74 - иллюстрация формы представления запроса выделения средств. Фиг. 75 - иллюстрация уведомления о выплаченном платеже. Фиг. 76 - схематическая иллюстрация задач поддержания системных экранов. Фиг. 77 - иллюстрация формы поддержания кодов фазы. Фиг. 78 - иллюстрация экрана администрирования логина пользователя. Фиг. 79 - иллюстрация формы дополнения/редактирования списка выбора. Фиг. 80 - иллюстрация формы добавления/редактирования роли организации. Фиг. 81 - иллюстрация формы задания по умолчанию/конфигурирования параметров настройки. Фиг. 82 - иллюстрация формы редактирования уведомления. Фиг. 83 - иллюстрация формы задания по умолчанию/конфигурирования процесса. Фиг. 84 - иллюстрация формы дополнения/редактирования роли пользователя. Фиг. 85 - схематическая иллюстрация процессов выполнения инспекции и связанных задач. Фиг. 86 - иллюстрация уведомления о подготовке к проведению инспекции. Фиг. 87 - иллюстрация уведомления о требуемой инспекции. Фиг. 88 - иллюстрация экрана требования инспекции. Фиг. 89 - иллюстрация уведомления ввода отчета инспекции. Фиг. 90 - иллюстрация формы ввода отчета инспекции. Фиг. 91 - иллюстрация экрана ввода отчета инспекции. Фиг. 92 - иллюстрация уведомления о неуспешном отчете инспекции. Фиг. 93 - иллюстрация экрана представления предыдущих инспекций. Фиг. 94 - схематическая иллюстрация процесса одобрения запроса выделения средств. Фиг. 95 - иллюстрация формы Авторизации Запроса Выделения Средств Один. Фиг. 96 - иллюстрация уведомления отклоненной Авторизации Запроса Выделения Средств Один. Фиг. 97 - иллюстрация уведомления подтвержденной инспекции. Фиг. 98 - иллюстрация уведомления о модифицированных деталях платежа. Фиг. 99 - иллюстрация уведомления об авторизованной инспекции. Фиг. 100 - иллюстрация уведомления Авторизации Запроса Выделения Средств Два. Фиг. 101 - иллюстрация формы Авторизации Запроса Выделения Средств Два. Фиг. 102 - иллюстрация уведомления отклоненной Авторизации Запроса Выделения Средств Два. Фиг. 103 - иллюстрация уведомления одобренной Авторизации Запроса Выделения Средств Два. Фиг. 104 - иллюстрация уведомления о выдаче отказа от удержания. Фиг. 105 - схематическая иллюстрация процесса запроса изменения. Фиг. 106 - иллюстрация формы запроса изменения. Фиг. 107 - иллюстрация уведомления о выданном запросе изменения. Фиг. 108 - иллюстрация уведомления авторизации запроса изменения. Фиг. 109 - схематическая иллюстрация процесса обработки запроса изменения. Фиг. 110 - иллюстрация экрана отображения ожидающего запроса изменения. Фиг. 111 - иллюстрация формы авторизации запроса изменения. Фиг. 112 - иллюстрация уведомления об отклоненном запросе изменения. Фиг. 113 - иллюстрация уведомления об одобренном запросе изменения. Фиг. 114 - схематическая иллюстрация процесса изменения участника проекта. Фиг. 115 - иллюстрация экрана изменения участника. Фиг. 116 - иллюстрация экрана проверки удаления участника. Фиг. 117 - иллюстрация экрана изменения аффидавита. Фиг. 118 - схематическая иллюстрация задач поддержания экранов проекта. Фиг. 119 - иллюстрация формы профиля проекта. Фиг. 120 - иллюстрация экрана контактной информации по проекту.-4 011312 Фиг. 121 - иллюстрация экрана информации по проекту. Фиг. 122 - иллюстрация экрана закрытия проекта. Фиг. 123 - схематическая иллюстрация задач управления экраном доступа. Фиг. 124 - иллюстрация экрана входа. Фиг. 125 - иллюстрация экрана выхода. Фиг. 126 - иллюстрация экрана домашней страницы проекта. Фиг. 127 - иллюстрация экрана сброса пароля. Фиг. 128 - иллюстрация основного экрана для конкретного пользователя. Фиг. 129 - иллюстрация экрана просмотра проектов. Фиг. 130 - иллюстрация экрана забытого пароля. Фиг. 131 - иллюстрация уведомления о Вашем пароле. Фиг. 132 - схематическая иллюстрация процесса управления экранами сообщений. Фиг. 133 - иллюстрация экрана представления сообщений. Фиг. 134 - иллюстрация особого сообщения, просматриваемого пользователем. Фиг. 135 - иллюстрация экрана создания/отправки сообщений. Фиг. 136 - иллюстрация экрана сообщения состояния. Фиг. 137-153 - блок-схемы, иллюстрирующие способ управления процессом платежа в строительстве, в соответствии с другим вариантом осуществления изобретения. Фиг. 154-179 диаграммы ввода/вывода, иллюстрирующие способ управления процессом платежа в строительстве, в соответствии с еще одним другим вариантом осуществления изобретения. Прежде чем перейти к подробному описанию вариантов осуществления изобретения следует отметить, что признается очевидным то, что изобретение по настоящей заявке не ограничено деталями конструкции и расположением компонентов, раскрытых в этом описании или представленных на соответствующих фигурах чертежей. Изобретение может быть выполнено в соответствии с другими вариантами осуществления и может обеспечивать достижение результата различными путями. Кроме того, очевидным является, что фразеология и терминология, используемые в настоящих материалах, приведены в целях описания и не могут быть истолкованы, как ограничения. Использование выражений включающий в себя, содержащий или имеющий и их разновидностей в настоящих материалах предназначено для охвата элементов, перечисленные после них, а также их эквивалентов и дополнительных элементов. Термины установленный, связанный и соединенный используются в широком смысле и охватывают как непосредственную, так и косвенную установку, соединение и связь. Кроме того, соединенный и связанный не ограничены физическими или механическими связям или соединениями и могут включать в себя электрические соединения и связи, прямые и косвенные. Кроме того, электронные коммуникации и уведомления могут быть выполнены с использованием любых известных средств, в том числе непосредственных соединений, беспроводных соединений и т.д. Следует отметить, что для осуществления изобретения можно использовать множество аппаратно и программно-управляемых устройств, а также множество различных структурных компонентов. Кроме того, как это описано далее, конкретные конфигурации, представленные на фигурах чертежей, предназначены для иллюстрации вариантов осуществления изобретения, причем возможны и другие альтернативные конфигурации. Фиг. 1 - схематическая иллюстрация системы 10 управления платежом в строительстве (СУПС) в соответствии с одним вариантом осуществления изобретения. СУПС 10 может включать в себя сервер 12 приложений, сервер 14 баз данных, модуль 16 прикладной логики, веб-сервер 18, сеть 20 (такую как Интернет или другие сети отдельно или в совокупности с Интернет), службу 22 проверки, участвующие организации или физические лица 24 (в дальнейшем участник или организация) и платежную систему 26. Платежная система 26 может включать в себя систему автоматизированной расчетной палаты(АРП), систему банковского перевода, систему дебетовой карты, систему кредитной карты или любую другую подходящую систему электронного перевода фондов (ЭПФ). Сервер 12 приложений может сохранять модуль 28 проекта, модуль 30 управления формой, устройство 32 разрешений и авторизации, систему 34 управления базами данных, модуль 36 бюджета, администратор 38 доступа, администратор 40 уведомлений, модуль 42 организации, модуль 44 выделения средств, модуль 46 контракта, модуль 48 распоряжения об изменении, модуль 50 пользователя, администратор 52 системного окружения и электронный промежуточный бункер/средство 54 условного депонирования. Модуль 44 выделения средств может включать в себя основной модуль 56, модуль 58 инспекции и модуль 60 одобрения выделения средств. Администратор 52 системного окружения может включать в себя генератор 62 сообщения, модуль 64 помощи и модуль 66 обслуживания системы. Электронный промежуточный бункер/средство 54 условного депонирования может сохранять один или большее число отказов 68 от удержания. Очевидным является, что компоненты сервера 12 приложений могут быть объединены иным образом, чем показано и описано со ссылкой на фиг. 1. Программное обеспечение, используемое для кодирования различных модулей, диспетчеров и устройств сервера 12 приложений, может быть объединено или разнесено любым подходящим образом, оно может быть сохранено и к нему может быть обеспечен доступ любым подходящим образом.-5 011312 Сервер 12 приложений может быть связан с сервером 14 баз данных, модулем 16 прикладной логики и службой 22 проверки. Однако в некоторых вариантах осуществления, служба 22 проверки может быть связана только с сетью 20. Модуль 16 прикладной логики может быть связан с веб-сервером 18 или,в некоторых вариантах осуществления, непосредственно с сетью 20. Веб-сервер 18 может быть связан с сетью 20. Участники 24 могут включать в себя владельца 70 собственности (и/или представителя 72 владельца), генерального подрядчика (ГП) 74, инспектора 76, одного или нескольких субподрядчиков (Субподрядчик А 78, Субподрядчик В 80, и т.д.), одного или нескольких поставщиков 82 материалов, одного или нескольких заимодателей 84 (и/или одного или нескольких должностных лиц 86 заимодателя), одну или несколько титульных компаний 86 и одного или нескольких архитекторов 88. Участники 24 могут также включать в себя одного или нескольких проектировщиков интерьера (и/или изготовителей мебели) и одного или нескольких владельцев недвижимого имущества (то есть, владельца земли, который продает строительную площадку владельцу 70 собственности). Участники 24 могут включать в себя организации и/или физических лиц, которых рассматривают выше линии (то есть, выше в процессе строительства,чем ГП) или ниже линии (то есть, нанимаемых ГП). Участники 24 выше линии могут включать в себя заимодателей, архитекторов, проектировщиков интерьера, владельцев собственности, представителей владельцев собственности, титульные компании и владельцев недвижимого имущества. Участники 24 ниже линии могут включать в себя субподрядчиков и поставщиков материалов. СУПС 10 может быть использована для облегчения процесс платежа в строительстве между любым из этих типов участников 24, выше или ниже линии ГП. СУПС 10 часто описывают в настоящих материалах, как используемую для облегчения платежа между ГП и субподрядчиками. Однако, очевидным является, что СУПС 10 может быть использована для облегчения платежа между любыми типами участников, а не только между ГП и субподрядчиками. В дополнение к классификации участников, как являющихся выше или ниже линии ГП, стоимости,связанные с процессом строительства, могут быть классифицированы как мягкие стоимости или твердые стоимости. Мягкие стоимости могут включать в себя оплату инспектора, оплату архитектора,оплату по планировке интерьера, оплату титульной компании, оплату разрешения, коммунальные счета за собственность в ходе процесса строительства, стоимость мебели, аудио/визуального оборудования,компьютеров и т.д. Твердые стоимости могут включать в себя все затраты, понесенные организациями или физическими лицами, нанятыми ГП, включая все затраты субподрядчиков и поставщиков материалов, нанятых ГП. Каждый строительный проект может включать в себя полный бюджет (с точки зрения владельца); который включает в себя все мягкие и твердые затраты. Каждый строительный проект может также включать в себя бюджет ГП. СУПС 10 может быть использована для облегчения всех платежей,сделанных в пределах полного бюджета и бюджета ГП. Однако в некоторых вариантах осуществления изобретения, СУПС 10 может быть использована только для облегчения платежа по твердым затратам,регулируемым ГП (то есть, только по бюджету ГП). Для среднего специалиста очевидным является, что СУПС 10 может быть использована для облегчения платежа только по твердым стоимостям ГП, только мягким стоимостям участниками выше линии ГП или совокупности твердых и мягких стоимостей участниками выше и ниже линии ГП. СУПС 10 часто описывается в настоящих материалах в отношении твердых стоимостей, но также может быть использована для мягких стоимостей или совокупности твердых и мягких стоимостей. Каждый из участников 24 может быть связан с платежной системой 26; однако, некоторые из участников 24 могут не быть связаны с платежной системой 26 в некоторых вариантах осуществления изобретения. В некоторых вариантах осуществления, платежная система 26 может включать в себя систему АРП с одним или несколькими инициирующими депозитарными финансовыми учреждениями (ИДФУ) и одним или несколькими получающими депозитарными финансовыми учреждениями (ПДФУ). Участники 24 могут получить доступ к серверу 12 приложений, чтобы использовать различные модули, администраторов и блоки для выполнения способов управления платежом в строительстве в соответствии с несколькими вариантами осуществления изобретения. В некоторых вариантах осуществления СУПС 10 может соединять всех участников проекта, по существу, с однородной, построенной на основе сети, работающей в реальном времени системой, могут организовать бюджетирование для строительного проекта, позволяет облегчить электронное предъявление и одобрение счетов, и позволяет автоматизировать и ускорить процесс платежа и снятия отказа от удержания с помощью электронных платежей и выработки электронным образом соответствующих снятий отказов от удержания. Хотя и могут иметь место изменения в деталях (например, в публично финансируемом проекте,инициирование проекта и надзор за ним могут быть выполнены лицом, выдающим поручительскую гарантию, а не банком), один из вариантов осуществления СУПС 10 может быть использован следующим образом. Должностное лицо по займам (кредитам) может войти в Интернет и зайти на веб-сайт СУПС. После проверки на разрешение доступа, должностное лицо по займам (кредитам) может войти в портфель заимодателя и получить доступ к ряду экранов для создания нового проекта, посредством ввода всех деталей проекта. Должностное лицо по займам (кредитам) может включать детали по участникам-6 011312 для каждого проекта, например, по владельцу, архитектору, генеральному подрядчику и титульной страховой компании. Каждый участник может получить уведомление электронной почты о своей причастности к проекту и может проверить детали своего профиля. ГП может добавить субподрядчиков и поставщиков материалов. Субподрядчики и поставщики материалов могут получить уведомление, что они были добавлены к проекту и могут пройти процесс проверки и получения доступа. ГП может выбрать количество выделений средств и даты выделения средств по проекту. СУПС 10 может уведомить в реальном времени участников о предстоящей дате выделения средств. Каждый из участников может заполнить свою форму запроса выделения средств путем ввода деталей своих счетов за материалы и труд. ГП может рассмотреть запросы выделения средств и разрешить их, а СУПС 10 может выработать заявление под присягой. Затем могут последовать серии инспекций строительной площадки, одобрений, снятий отказов от удержания, выработка заявлений и т.д., о которых могут быть сделаны напоминания СУПС 10 посредством уведомлений электронной почты в реальном времени. Как только все формы заполнены и проверены, СУПС 10 может обеспечить выполнение платежей. Платежи могут быть депонированы непосредственно на банковский счет участника посредством электронной платежной системы. Этот процесс может быть повторен для всех выделений средств. Бюджет проекта может поддерживаться в балансе путем выполнения выплат, сбора отказов от удержания и одобрения инспекций. Ход проекта может быть отслежен при помощи СУПС 10 посредством графических индикаторов хода. СУПС 10 может иметь следующие функциональные особенности: разовую регистрацию участвующих организаций в СУПС 10; уведомление в реальном времени о выделении средств; автоматизированную выработку счета; автоматизированную выработку заявления под присягой; автоматизированную выработку отказа от удержания; скоординированные платеж/снятие отказа от удержания; и прямое распределение фондов участвующим организациям. Разовая регистрация участвующих организаций в СУПС 10 может понизить стоимость участия в обслуживании, потому что участник должен зарегистрироваться только один раз. Разовая регистрация также снижает количество потенциальных ошибок, потому что вход должен быть выполнен только один раз. Это делает более вероятным то, что потенциальные участники будут участвовать фактически, и когда они будут это делать, они получат хороший (свободный от ошибок) результат. Разовая регистрация позволяет гарантировать, что стороне, желающей быть участницей процесса, и онлайновому сообществу,использующему процесс, нужно один раз зарегистрироваться, чтобы получить возможность участвовать в любом из проектов, платежи по которым выполняют через СУПС 10. СУПС 10 может улучшить эффективность регистрации участвующих организаций в процессе платежа в строительстве, путем создания устойчивого сообщества, которое со временем облегчает процесс участия в многочисленных проектах, посредством однократного сбора информации об организации и персональной информации. Способ позволяет организациям быть зарегистрированными в качестве потенциального участника любого проекта, который инициируется членом сообщества хозяйствующих субъектов, использующим СУПС 10. В дополнение к своей значимости при участии в многочисленных проектах, одноразовая регистрация также ценна для участников при выполнении доступа к информации относительно многочисленных владельцев ГП, заимодателей, субподрядчиков, и т.д. Например, одноразовая регистрация дает владельцам,заимодателю и ГП возможность узнать через СУПС 10 о новых субподрядчиках. Кроме того, владелец,имеющий несколько подлежащих выполнению проектов, каждый с различным ГП, может получить доступ к информации о каждом отдельном ГП. Уведомление в реальном времени о выделении средств позволяет гарантировать, что все участники выделения средств: 1) уведомлены своевременным и единообразным способом; и 2) обеспечены шаблоном для предоставления информации, необходимой для оплаты. СУПС 10 помогает устранять ошибки(без уведомления или путаницы в том, из какого проекта пришел запрос), которые задерживают процесс платежа. СУПС 10 улучшает эффективность уведомления в реальном времени о процессе выделения средств, давая ГП возможность поддержания расписания выделения средств на СУПС 10, путем уменьшения усилия, затрачиваемого на уведомления участников выделения средств, посредством автоматизации процесса построения списка участников для выделения средств, путем автоматического уведомления участников выделения средств о выделении средств, как только о нем было объявлено, посредством обеспечения легко доступных связей так, чтобы субподрядчики могли получить доступ к СУПС 10 для представления документации, которая требуется при выделении средств. СУПС 10 может быть использована владельцем, представителем владельца, заимодателем, ГП или титульной компанией для создания и поддержания бюджета проекта. Как было отмечено выше, бюджет проекта может включать в себя мягкие затраты выше линии ГП, твердые затраты ниже линии ГП или совокупность твердых и мягких затрат. Некоторые варианты осуществления СУПС 10 могут также использоваться для создания и управления распоряжениями об изменении, которыми изменяют бюджет(обычно расширяя бюджет), и измененный бюджет одобряется соответствующими участниками. Бюджет может включать в себя общую стоимость для строительного проекта, наряду с затратами по статьям для каждой фазы или работы, которые должны быть выполнены для окончания строительного проекта. СУПС 10 может структурировать бюджет для облегчения платежей субподрядчикам, чтобы позволить эффективно отслеживать ход и обеспечить автоматизированное выставление счетов.-7 011312 СУПС 10 может создавать автоматизированные счета, которые точно соответствуют полному бюджету проекта и также точно соответствуют отказам от удержания и заявлениям под присягой. СУПС 10 автоматизированным образом создает счета, которые являются во времени снимком деятельности, уже имевшей место в отношении полного бюджета проекта. СУПС 10 может быть использована для создания автоматизированным образом счетов, которые точно соответствуют статьям в полном бюджете. Это приводит к формированию счетов и сообщений, которые согласуются с путем, которым представлен строительный проект в финансовых целях, целях отслеживания и т.д. При использовании СУПС 10 экран счета может быть использован для ввода информации, необходимой для создания счета; однако, не вся информация, необходимая для создания счета, должна вводиться повторно, потому что информация может быть собрана посредством обращения к полному бюджету проекта. Это также гарантирует, что счета (и документы G702/703) будут согласованы с полным бюджетом проекта и будут согласованы между выделениями средств или любыми другими периодами времени (если только участник, такой как владелец, не захочет, чтобы счета изменились). СУПС 10 может также быть использована для настройки автоматизированным образом подготавливаемых (автоматизированных) счетов (или документов G702/703) в соответствии с требованиями заимодателя, владельца, представителя владельца, ГП и т.д. Бюджет и автоматизированный счет могут быть использованы для единообразного сбора и непрерывного обеспечения ссылок на информацию, которая будет использована во всем процессе управления платежом в строительстве. Собранную информацию не нужно повторно вводить в процессе платежа, что позволяет гарантировать, что не будут внесены ошибки (из-за неверного нажатия клавиши или неправильного истолкования данных). Обычно, участникам обеспечена видимость в процессе платежа, проводимого с использованием СУПС 10. Это помогает снизить усилие, необходимое для определения статуса проекта и понимания того, какую работу каждый участник должен сделать, чтобы облегчить процесс платежа. Это также помогает выделять организации или персоналии, которые могут обычно вносить задержки или ошибки в процесс, облегчая исправление поведения или устранение участника. Точное выставление счета минимизирует усилия по разрешению пересмотра и выставления счета, способствует вынесению полных и точных заявлений под присягой, минимизирует несоответствия между заявлениями под присягой и инспекциями и позволяет выполнить своевременный платеж. СУПС 10 может повысить эффективность нескольких действий позднее в процессе платежа в строительстве, посредством обеспечения своевременным образом ввода полной и согласованной информации по счету. СУПС 10 может быть использована для выработки автоматизированным образом (автоматизированных) заявлений под присягой и автоматизированным образом (автоматизированных) отказов от удержания. Используя СУПС 10 ГП знает, кто был уведомлен в отношении выделения средств и кто ответил путем предоставления счета. Как только счета одобрены ГП (и любым другим участником выше линии ГП, таким как владелец, представитель владельца, заимодатель, титульная компания и т.д., который должен одобрить счета), СУПС 10 может использовать одобренные счета для автоматической выработки заявления под присягой и отказов от удержания. СУПС 10 может автоматически вырабатывать заявление под присягой и отказы от удержания по счетам, представленным субподрядчиками и поставщиками материалов, позволяя гарантировать, что никакие опечатки не будут внесены, и что заявление под присягой и отказы от удержания будут включать в себя только те статьи, которые были представлены субподрядчиками и поставщиками материалов. СУПС 10 может позволить уменьшить риск погрешностей в заявлении под присягой и отказах от удержания, посредством привлечения деталей счета, уже сохраненных в системе, для автоматического создания содержимого заявления под присягой и отказов от удержания. Эта обработка помогает устранять ошибки, которые возможны из-за нестандартных, непоследовательных и несвоевременных счетов и опечаток, которые могут произойти при перезаписи или перепечатке. В целом, это понижает уровень риска в процессе платежа в строительстве, путем увеличения точности и своевременности критичной для строительного проекта информации. СУПС 10 позволяет создавать автоматизированные отказы от удержания в соответствии с действующими юридическими стандартами тех мест, где расположена строительная площадка. СУПС 10 позволяет вырабатывать заявления под присягой, которые точно соответствуют счетам. Счета часто разбивают по типам выполняемой работы (например, электрика, сантехника и т.д.), в то время как заявления под присягой часто разбивают по участникам, выполняющим работу (например, ГП,субподрядчикам и поставщикам материалов). СУПС 10 могут быть использованы для обеспечения равенства суммы величин по счету общей сумме в заявлении под присягой. Кроме того, СУПС 10 могут также быть использованы, для того, чтобы гарантировать равенство величин в отказах от удержания величинам в счетах, поскольку информацию для автоматизированных отказов от удержания собирают из одобренных счетов, которые были сохранены в СУПС 10. В дополнение, отказы от удержания будут совместимы с заявлением под присягой, поскольку заявление под присягой также было выработано СУПС 10 с использованием информации из одобренных счетов. Это особенно ценно, когда ГП и субподрядчики(или владельцы, заимодатель и ГП) оспаривали сумму по счету и договорились об окончательной величине по прошествии периода времени. Окончательная величина будет отражена в автоматизированном и одобренном счете, который сохранен в СУПС 10 и используется для выработки отказов от удержания и заявления под присягой. СУПС 10 гарантирует, что только одобренная величина счета будет отражена в-8 011312 документах заявления под присягой и отказа от удержания. Также используя сохраненный бюджет как рамочную структуру для всех автоматизированных документов, СУПС 10 в дальнейшем гарантирует,что счета, отказы от удержания и заявления под присягой будут точны и непротиворечивы. СУПС 10 может быть также использована для настройки заявления под присягой и отказов от удержания, на основании требований заимодателя, владельца, представителя владельца, ГП и т.д. СУПС 10 также помогает повысить эффективность выработки заявлений под присягой и отказов от удержания посредством мигрирующего сохранения документов счета, заявления под присягой и отказа от удержания в электронной среде, уменьшая время и усилия, необходимые для сохранения и обеспечения доступа к ним. Это повышает полную эффективность процесса платежа в строительстве, посредством выполнения этих документов доступными для авторизованных сторон, нуждающихся в них для выполнения своих обязанностей. База данных СУПС 10 может сохранять библиотеку подписанных электронным образом счетов, заявлений под присягой и отказов от удержания. В случае необходимости участники могут использовать СУПС 10 для выработки копий документов любого из электронным образом подписанных документов. В одном варианте осуществления, СУПС 10 может создавать автоматизированные счета, заявление под присягой и отказы от удержания, как только вся информация была введена, и все аспекты были учтены. В других вариантах осуществления, СУПС 10 может, во-первых, создавать автоматизированные счета, обеспечивать одобрение счетов, во-вторых, создавать автоматизированное заявление под присягой, обеспечивать подписание заявления под присягой и, в третьих, создавать автоматизированные отказы от удержания. Как только вся информация (счета, инспекционные отчеты, банковская информация и т.д.) введена и все аспекты учтены, владелец, представитель владельца, заимодатель, титульная компания или ГП может заплатить участникам выделения средств. Субподрядчики, поставщики материалов или любые другие участники могут обеспечить свои отказы от удержания в обмен на платеж. СУПС 10 может организовать этот процесс и может автоматически выполнить обмен без риска того, что любая сторона выполнит свою часть, а другие не выполнят свои. СУПС 10 также помогает устранить потребность в дорогих и отнимающих много времени встречах, для влияния на обмен отказами от удержания на платеж. СУПС 10(которая строго отслеживает документы) также помогает гарантировать сбор всех отказов от удержания. Это уменьшает риск того, что плохое ведение учета приведет к отсутствию снятия отказов от удержания при завершении строительного проекта. СУПС 10 позволяет повысить эффективность процесса выполнения платежа/снятия отказа от удержания посредством осуществления способа в сетевой компьютерной системе. Это позволяет всем сторонам надежно подготовить как платеж, так и снятие отказа от удержания в доверительным образом реализованной среде. СУПС 10 обеспечивает эффективный обмен платежа на отказ от удержания, потому что СУПС 10 позволяет организовать многостадийную подготовку платежа и отказа от удержания для автоматизированного обмена, таким образом уменьшая риск, связанный с проектом. ГП может быть уверен в том, что он получит соответствующие отказы от удержания, совпадающие с платежом, и что субподрядчики не будут рисковать в связи с долгими задержками платежа. СУПС 10 может облегчить обмен отказами от удержания и платежными поручениями. В некоторых вариантах осуществления, СУПС 10 может снимать отказ(ы) от удержания по существу одновременно с подтверждением от платежной системы 26 того, что участник(и) получил(и) платеж. Термин по существу одновременно, в том смысле, как он использован в настоящем описании и формуле изобретения,включает в себя любой период времени, меньший, чем время, необходимое для запроса, обработки и перевода фондов при платеже автоматизированной расчетной палатой (АРП) (что может занять приблизительно до 72 ч). Например, по существу одновременное снятие отказов от удержания может включать в себя незамедлительное снятие отказов от удержания, снятие пакета отказов от удержания в конце рабочего дня или снятие отказов от удержания после типичного периода времени, который требуется для перевода фондов посредством системы АРП. В одном варианте осуществления, СУПС 10 может получать и сохранять отказы от удержания в электронном промежуточном бункере/средстве 54 условного депонирования, пока не получены все отказы от удержания от участников выделения средств. Как только все отказы от удержания получены, СУПС 10 может послать инструкции для платежной системы 26, для передачи фондов каждому участнику выделения средств. Например, как только все субподрядчики электронным образом подписали и представили свои отказы от удержания в СУПС 10, СУПС 10 может проинструктировать платежную систему 26 произвести оплату каждому субподрядчику. СУПС 10 может снимать отказы от удержания либо когда платежное поручение передано платежной системе 26, либо только после получения подтверждения, что участники фактически получили фонды. Если платежная система 26 включает в себя систему АРП, платежные поручения обычно обрабатываются пакетами так, что участники не получают фонды незамедлительно. В системе АРП, платежное поручение обычно может быть возвращено ПДФУ в течение 48-часового периода. В течение этого 48 часового периода, ПДФУ может уведомить СУПС 10 и ИДФУ, что фонды не могут быть переданы (например, из-за недостаточности фондов, недействительности номера счета и т.д.). После этого 48 часового периода, СУПС 10 может предположить, что ПДФУ обработало платежное поручение, если СУПС 10 не уведомлена об ином. ИДФУ обычно имеет 24-часовую границу для сбора платежных пору-9 011312 чений от ПДФУ и выполнения платежа по счетам участников выделения средств. В результате может пройти приблизительно 72 ч со времени, когда в СУПС 10 передают платежные поручения до перевода ИДФУ фондов на счета участников. В некоторых вариантах осуществления СУПС 10 может сигнализировать определенным участникам, чтобы они удалили этих участников из пакетной обработки системы АРП, и может оплатить этим участникам отдельно, другим способом, таким как прямой перевод фондов, или с помощью другого типа мгновенной электронной передачи фондов. В других вариантах осуществления большинству участников может быть оплачено по типу мгновенной электронной передачи фондов (такому как прямой перевод), а некоторые участники могут быть объединены для одного или нескольких пакетных переводов АРП. В других вариантах осуществления СУПС 10 может передавать каждое платежное поручение платежной системе 26, поскольку СУПС 10 получает каждый отказ от удержания от каждого участника, и фонды могут незамедлительно быть переданы участнику, от которого был получен отказ от удержания, обычно,СУПС 10 может сгруппировать платежные поручения любым подходящим образом и может использовать любой подходящий тип платежного метода. В каждом варианте осуществления изобретения СУПС 10 может установить связь между текущим отказом от удержания и текущим платежом, соответствующим текущему выделению средств, вместо того, чтобы обменивать предыдущий отказ от удержания на текущий платеж текущего выделения средств. Например, СУПС 10 может снять отказ от удержания за текущий месяц для текущего выделения средств, вместо снятия отказа от удержания за предыдущий месяц для текущего выделения средств. Таким образом, на субподрядчика не возлагается ответственность, если СУПС 10 снимает его отказ от удержания перед осуществлением платежа, и на владельца (или ГП, титульную компанию, заимодателя и т.д.) не возлагается ответственность, если СУПС 10 выполняет платеж перед тем, как сняты отказы от удержания. Вместо того, чтобы произвести оплату ГП, который платит своим субподрядчикам, которые затем платят своим субподрядчикам, участникам СУПС 10 можно произвести оплату непосредственно, используя электронное распределение фондов (например, любой подходящий тип ЭПФ, АРП или банковского перевода фондов). Это ускоряет процесс платежа (снижая затраты) и уменьшает риск неоплаты сторонам (по иерархии). Прямое распределение фондов делает возможным СУПС 10 использовать для сбора всею информацию, которая является необходимой для выполнения платежей. Информации, собранной с использованием СУПС 10, можно доверять, в силу строгости, с которой способы могут быть осуществлены программным обеспечением. В результате, прямое распределение фондов может быть эффективным (не нужно никаких переделок или повторного ввода необходимой информации) и свободным от ошибок. СУПС 10 может улучшить эффективность процесса оплаты субподрядчика/поставщика материалов, уменьшая время, необходимое для завершения процесса платежа. СУПС 10 может уменьшать операционные затраты, заменяя иерархический процесс платежа прямыми платежами, при улучшении финансового и административного управления. СУПС 10 может заменить использование чеков электронным переводом фондов, уменьшая затраты на связь и улучшая видимость статуса платежей, а также уменьшая риск несвоевременного или неполного платежа всем сторонам, вовлеченным в процесс строительства (особенно низовым в цепи снабжения). На фиг. 2-7 представлен краткий обзор процессов управления платежом в строительстве, которые могут быть выполнены участниками 24, использующими различные модули, администраторы и машины,сохраненные на сервере 12 приложений. На фиг. 2 представлен процесс 94 управления проектом (который может быть выполнен модулем 28 проекта и/или модулем 36 бюджета), процесс 96 управления выделением средств (который может быть выполнен модулем 44 выделения средств), процесс 98 управления распоряжением об изменении (который может быть выполнен модулем 48 управления распоряжением об изменении), процесс 100 управления организацией (который может быть выполнен модулем 42 организации и/или модулем 50 пользователя), процесс 102 управления системным окружением (который может быть выполнен администратором 38 доступа, администратором 40 уведомлений и/или администратором 52 системного окружения). На фиг. 3 представлен процесс 94 управления проектом, который может включать в себя задачу 104 создания проекта, задачу 106 поддержания проекта и задачу 108 создания бюджета. На фиг. 4 представлен процесс 100 управления организацией, который может включать в себя задачу 112 создания организации, задачу 114 поддержания организации, задачу 116 создания пользователя и задачу 118 поддержания пользователя. На фиг. 5 представлен процесс 96 управления выделением средств, который может включать в себя задачу 120 инициирования выделения средств, задачу 122 создания запроса выделения средств, задачу 124 расходования фондов, задачу 126 выполнения инспекции, и задачу 128 одобрения запроса выделения средств. На фиг. 6 представлен процесс 98 управления распоряжением об изменении,который может включать в себя задачу 130 создания запроса изменения, задачу 132 обработки запроса изменения и задачу 134 изменения участника. На фиг. 7 представлены задачи 102 управления системным окружением, которые могут включать в себя задачу 136 управления доступом, задачу 138 управления сообщениями, задачу 140 создания отчетов, задачу 142 обеспечения помощи и задачу 144 поддержания системы. Задача 140 создания отчетов может быть выполнена любым участником выше или ниже линии- 10011312 ГП для того, чтобы создавать специальным образом сформированные сообщения относительно продвижения строительного проекта, включая возможность контроля частей строительного проекта, конкретных участников, полного проекта и т.д. На фиг. 8-136 представлены способы управления платежом в строительстве, в соответствии с несколькими вариантами осуществления изобретения. На фиг. 8 представлен процесс 146 создания организации, который может быть включен в процесс 100 управления организацией. Процесс 146 создания организации может быть выполнен любым из участников 24, использующим модуль 42 организации. Процесс 146 создания организации может включать в себя задачу 148 создания организации, задачу 150 обновления профиля организации, задачу 152 редактирования организации, задачу 154 активации уведомления организации, задачу 156 активации организации и либо задачу 158 отклонения организации, либо задачу 160 активированной организации. Задача 162 обновления профиля пользователя может также быть выполнена, как описано далее со ссылкой на фиг. 22. На фиг. 9 представлена форма создания организации, которая может быть связана с задачей 148 создания организации. Каждый участник 24 может получить доступ к форме создания организации посредством модуля 42 организации. Участник 24 может ввести требуемую информацию, такую как деловая информация, первичная контактная информация, налоговая информация и банковская информация. В некоторых вариантах осуществления, первый пользователь участвующей организации 24, который вводит свою информацию, как первичную контактную информацию, может считаться администратором для этого участника 24, и ему может быть предоставлено больше доступа к информации для участника,чем последующим пользователям. СУПС 10 может использовать всестороннюю ролевую безопасность так, чтобы участники проекта видели только информацию, соответствующую их определенным потребностям в проекте. Как только организация зарегистрирована в СУПС 10, эта организация может получать платежи по любым проектам, управляемым СУПС 10. На фиг. 10 представлено уведомление, которое может быть передано в ходе задачи 162 обновления профиля пользователя. Термины уведомление системы или уведомление или сообщение системы,так, как они использованы в настоящем описании и формуле изобретения, относятся к любой форме связи с участником 24, такой как сообщение электронной почты, экранное уведомление, текстовое сообщение, речевое сообщение и т.д. Системное уведомление по фиг. 10 может включать в себя имя пользователя и временный пароль для первого пользователя участника 24. На фиг. 11 представлено уведомление, которое может быть передано в ходе задачи 150 обновления профиля организации. Уведомление по фиг. 11 может быть послано администратору для участника 24. Уведомление может включать в себя заявление, требующее от получателя обновить профиль организации, добавить пользователей перед участием в проекте и обеспечить сведения о банке. На фиг. 12 представлена форма редактирования организации, которая может быть связана с задачей 152 редактирования организации. Каждый участник 24 может получить доступ к форме редактирования организации посредством модуля 42 организации. Участник 24 может изменить существующую информацию, такую как деловая информация, первичная контактная информация, налоговая информация и банковская информация. В некоторых вариантах осуществления, первый пользователь участвующей организации 24, который ввел свою информацию, как первичную контактную информацию, является единственным пользователем, которому предоставлен доступ к форме редактирования организации. На фиг. 13 представлено уведомление активации организации, которое может быть передано в ходе задачи 156 уведомления активации организации. Уведомление по фиг. 13 может включать в себя заявление, что детали организации были обновлены, и запрос на подтверждение и активацию организации. На фиг. 14 представлена форма активации организации, которая может быть связана с задачей 156 активации организации. Форма по фиг. 14 может включать в себя список участников 24 (например,включающий в себя название организации, ее роль в процессе строительства, возможность выбирать участников 24 и возможность просматривать информацию для участников 24). Форма по фиг. 14 может также включать в себя функциональную возможность Найти, возможность определить тип участника 24 и возможности отклонить/дезактивировать выбранные организации и представить причину отклонения/дезактивации. На фиг. 15 представлено уведомление об активированной организации, которое может быть передано в ходе задачи 160 активированной организации. Подобным образом, на фиг. 16 представлено уведомление об отклоненной организации, которое может быть передано в ходе задачи 158 отклонения организации. На фиг. 17 представлен процесс 162 поддержания организации, который может быть включен в процесс 100 управления организацией. Процесс 162 поддержания организации может использоваться организациями непосредственно или другими участниками, для поддержания точности контактной информации, информации о банковском счете или любого другого типа информации, необходимой для процесса платежа в строительстве. Процесс 162 поддержания организации может быть выполнен любым из участников, использующих модуль 42 организации. Процесс 162 поддержания организации может включать в себя задачу 164 просмотра организации, задачу 166 редактирования организации, задачу 168 обновленной организации и задачу 170 представления организации.- 11011312 На фиг. 18 показан экран представления организации, который может быть связан с задачей 170 представления организации. Экран представления организации может включать в себя деловую информацию и первичную контактную информацию для организации. На фиг. 19 показан экран просмотра организации, который может быть связан с задачей 164 просмотра организации. Экран просмотра организации может включать в себя список участников, включающий в себя название организации, роль организации в процессе строительства, первичный контакт и телефонный номер. Экран просмотра организации может включать в себя функциональную возможность Найти и связи для представления дополнительной информации о каждом участнике. В одном варианте осуществления, экран просмотра организации может быть использован ГП для отображения его предпочтительных субподрядчиков или поставщиков материалов. На фиг. 20 представлена форма редактирования организации, которая может быть связана с задачей 166 редактирования организации. Участник может редактировать существующую информацию, такую как деловая информация, первичная контактная информация, налоговая информация и банковская информация. В некоторых вариантах осуществления, первый пользователь организации, который ввел свою информацию, как первичную контактную информацию, является единственным пользователем,которому предоставлен доступ к форме редактирования организации. На фиг. 21 представлено уведомление об обновленном профиле организации, которое может быть передано в ходе задачи 168 обновленной организации. Уведомление по фиг. 21 может включать в себя информацию относительно обновленного профиля для участника наряду с именем первичного пользователя или администратора для участника. На фиг. 22 представлен процесс 172 создания пользователя, который может включать в себя в процесс 100 управления организацией. Процесс 172 создания пользователя может быть использован каждый раз, когда создают нового пользователя в существующей организации, чтобы предоставить новому пользователю соответствующий доступ к СУПС 10 (например, соответствующие уровни безопасности с пользовательской идентификацией и паролем). Процесс 172 создания пользователя может быть также использован для обновления пользовательских профилей. Процесс 172 создания пользователя может быть выполнен любым из участников 24, использующих модуль 42 организации. Процесс 172 создания пользователя может включать в себя задачу 174 создания пользователя и задачу 176 обновления профиля пользователя. На фиг. 23 представлена форма создания пользователя, которая может быть связана с задачей 174 создания пользователя. В некоторых вариантах осуществления, форма создания пользователя может быть использована для добавления пользователей после того, как первичный пользователь или администратор уже создан для участника. Новый пользователь может ввести в личную информацию, информацию безопасности (например, имя пользователя и пароль), предпочтения в отношении уведомления электронной почты и уровни проверки на разрешение доступа (например, может ли пользователь управлять проектами и/или подписывать документы). На фиг. 24 представлено уведомление обновления профиля пользователя, которое может быть передано в ходе задачи 176 обновления профиля пользователя. Уведомление по фиг. 24 может включать в себя заявление, что пользователь был добавлен как член организации, а также информацию безопасности пользователя (например, имя пользователя и временный пароль). На фиг. 25 представлен процесс 178 поддержания пользователя, который может быть включен в процесс 100 управления организацией и может продолжаться от фиг. 22. Процесс 178 поддержания пользователя может быть использован для просмотра пользователей в каждой организации и представления,редактирования и обновления пользователей в каждой организации. Процесс 178 поддержания пользователя может быть выполнен любым из участников, использующих модуль 42 организации. Процесс 178 поддержания пользователя может включать в себя задачу 180 просмотра пользователя и задачу 182 редактирования пользователя, задачу 184 обновленного профиля пользователя и задачу 186 представления пользователя. На фиг. 26 показан экран представления пользователя, который может быть связан с задачей 186 представления пользователя. Экран представления пользователя по фиг. 26 может включать в себя персональную информацию пользователя, предпочтение в отношении уведомления электронной почты и уровень проверки на разрешение доступа. На фиг. 27 показан экран просмотра пользователей, который может быть связан с задачей 180 просмотра пользователей. Экран просмотра пользователей по фиг. 27 может включать в себя список из одного или нескольких пользователей для каждого участника, и может включать в себя имена пользователей, адреса электронной почты и телефонные номера. Экран просмотра пользователей может также включать в себя связи для редактирования информации для каждого пользователя. На фиг. 28 представлена форма редактирования пользователя, которая может быть связана с задачей 182 редактирования пользователя. Пользователь может обеспечить персональную информацию,предпочтения в отношении уведомления электронной почты и уровни проверки на разрешение доступа. На фиг. 29 представлено уведомление об обновленном профиле пользователя, которое может быть передано в ходе задачи 184 обновленного профиля пользователя.- 12011312 На фиг. 30 представлен процесс 188 создания проекта, который может быть включен в процесс 94 управления проектом. Процесс 188 создания проекта может быть выполнен ГП, заимодателем, владельцем или представителем владельца, использующим модуль 28 проекта для инициирования нового проекта в СУПС 10. Процесс 188 создания проекта может включать в себя задачу 190 создания проекта, задачу 192 созданного проекта, задачу 194 доступа пользователя по проекту и задачу 196 обязанностей по проекту. На фиг. 31 и 32 представлена форма создания проекта, которая может быть связана с задачей 190 создания проекта. ГП, заимодатель, владелец или представитель владельца могут предоставить информацию идентификации проекта, информацию о финансировании проекта, информацию о владельце проекта, информацию об архитекторе проекта и информацию о площадке. На фиг. 33 представлено уведомление о созданном проекте, которое может быть передано в ходе задачи 192 созданного проекта. Уведомление по фиг. 33 может включать в себя заявление о том, что ГП,заимодатель, владелец или представитель владельца создали новый проект, а также с связь с экраном,которая позволяет пользователям из участников быть приписанными к проекту. На фиг. 34 показан экран доступа пользователя по проекту, который может быть связан с задачей 194 доступа пользователя по проекту. Экран доступа пользователя по проекту может включать в себя название проекта, номер проекта, название ГП и список пользователей для конкретного проекта и/или конкретной организации. Пользователи могут быть идентифицированы по имени и имени пользователя и могут считаться менеджером проектов или подписывающим лицом. На фиг. 35 представлено уведомление об обязанностях по проекту, которое может быть передано в ходе задачи 196 обязанностей по проекту. Уведомление по фиг. 35 может включать в себя заявление, что обязанности пользователя в отношении проекта были изменены. На фиг. 36 представлен процесс 198 поддержания бюджета, который может быть включен в процесс 94 управления проектом. Процесс 198 поддержания бюджета может быть использован для создания и представления бюджета высокого уровня для строительного проекта, назначения статей участникам и возложения обязанностей на участников. Используя модуль 36 бюджета, процесс 198 поддержания бюджета может быть выполнен ГП для субподрядчиков или субподрядчиком для субподрядчика второго уровня или поставщика материалов. Процесс 198 поддержания бюджета может включать в себя задачу 200 ввода бюджета высокого уровня, задачу 202 принятия проекта, задачу 204 формы принятия бюджета,задачу 206 отклоненного бюджета, задачу 208 добавления пользователей, задачу 210 принятого проекта,задачу 211 домашней страницы проекта, задачу 212 доступа пользователя по проекту, задачу 214 обязанностей по проекту и задачу 216 представления бюджета проекта. Если проект отклонен, процесс 198 поддержания бюджета может включать в себя задачу 218 ввода бюджета и может вернуться к задаче 202 принятия проекта. После задачи 200 ввода бюджета высокого уровня, процесс 198 поддержания бюджета может включать в себя задачу 220 установки кода счета, задачу 222 ввода дат выделения средств и задачу 224 присвоения кода счета. На фиг. 37 представлена форма ввода бюджета высокого уровня, которая может быть связана с задачей 200 ввода бюджета высокого уровня. Форма ввода бюджета высокого уровня может включать в себя название проекта, номер проекта и стоимость контракта. ГП или субподрядчик могут представить значение процента удержания, коды фаз, описания кодов фазы, названия организаций, величины бюджета и коды банковских счетов. ГП или субподрядчик могут определить, является ли организация только обеспечивающей материалы. Форма ввода бюджета высокого уровня может также включать в себя связи с экранами/формами установки дат выделения средств и установки кода счета. Коды фаз и описания кодов фаз могут быть использованы для определения требований по контракту в отношении каждой конкретной работы, которая должна быть завершена для завершения проекта. Коды фаз и описания фаз могут быть предоставлены, например, Американским Институтом Архитекторов (АИА, AIA), Институтом Строительных Спецификаций (ИСС, CSI) или их можно получить путем переделки кодов фаз и описаний фаз АИА или ИСС. В некоторых вариантах осуществления, коды фаз и описания фаз могут быть полностью переделаны участниками. Под бюджетом высокого уровня можно также понимать перечень стоимостей, обязательных затрат (после того, как ГП получил предложения от субподрядчиков) или оценку проекта. В некоторых вариантах осуществления, коды фаз, включенные в бюджет высокого уровня,обеспечивают основание для запросов выделения средств, в которых каждый запрос выделения средств включает в себя определенные статьи, связанные с определенными кодами фаз. В некоторых вариантах осуществления, ГП может использовать внешнюю программу для выработки бюджета, и модуль 36 бюджета может взаимодействовать с внешней программой для импорта бюджета в сервер 12 приложений или сервер 14 баз данных. На фиг. 38 представлена форма ввода дат выделения средств, которая может быть связана с задачей 222 ввода дат выделения средств. ГП или субподрядчик могут ввести день месяца, на который должно иметь место выделения средств, а также определенные даты для выделений средств (например, каждый месяц в конкретный день). Форма ввода дат выделения средств может также включать в себя кнопку Calculate Draw Dates (Вычислить Даты Выделения Средств) для автоматического вычисления дат выделения средств и/или кнопку Add Draw Date (Добавить Дату Выделения Средств) для ручного ввода дат выделе- 13011312 ния средств. На фиг. 39 представлена форма установки кода счета, которая может быть связана с задачей 220 установки кода счета. ГП или субподрядчик могут выбрать код счета (например, коды по зданиям - Здание 1, 2, или 3), ввести новый код счета, создать код счета, ввести предпочтение для отображения строк бюджета (например, по кодам фаз), и ввести предпочтение для вариантов распечатки. Форма установки кода счета позволяет облегчить автоматизированную выработку счетов и заявлений под присягой посредством СУПС 10. Коды счета могут быть использованы для специально настроенных сообщений или для взаимодействия с другими типами существующего программного обеспечения. Коды счета могут позволить участникам сортировать статьи бюджета на основании требований архитектора, владельца и т.д. СУПС 10 могут также использовать коды банковского счета в бюджете для взаимодействия с существующими системами учета. Коды банковского счета могут быть использованы для поддержания бюджета, записи результатов выделения средств и облегчения выставления счета и платежа. На фиг. 40 представлена форма присвоения кода счета, которая может быть связана с задачей 224 присвоения кода счета. ГП или субподрядчик могут предоставить код счета (например, Здание 1, 2 или 3) и могут использовать связи для доступа к подбюджетам для каждого кода фазы. Форма присвоения кода счета может включать в себя название проекта, адрес проекта, коды фаз, описания кодов фаз, организацию, с которой имеется контракт на работу, и величину бюджета. Форма присвоения кода счета может также облегчить автоматизированную выработку счетов и заявлений под присягой посредством СУПС 10. На фиг. 41 представлено уведомление принятия проекта, которое может быть связано с задачей 202 принятия проекта. Уведомление по фиг. 41 может включать в себя заявление, что субподрядчик или поставщик материалов был добавлен, как участник по проекту, описание проекта и детали участия субподрядчика или поставщика материалов. Субподрядчик или поставщик материалов могут использовать связь, чтобы обратиться к форме принятия проекта, как показано на фиг. 42, чтобы принять или отклонить проект. На фиг. 42 показана форма принятия проекта, которая может быть связана с задачей 204 формы принятия бюджета. Форма принятия проекта может включать в себя номер проекта ГП, системный номер проекта, название ГП, название проекта, адрес проекта и статью бюджета. Форма принятия проекта позволяет обеспечить субподрядчика или поставщика материалов проектной информацией и статьей бюджета. Субподрядчик или поставщик материалов могут использовать кнопки Accept (Принять) илиDecline (Отклонить) для принятия или отклонения проекта, связанного со статьей бюджета. Субподрядчик или поставщик материалов могут также представить причину отклонения проекта. Статьи из форм принятия проекта могут быть также использованы для облегчения автоматизированной выработки счетов и заявлений под присягой посредством СУПС 10. На фиг. 43 показано уведомление об отклоненном проекте, которое может быть передано в ходе задачи 206 отклоненного проекта. Уведомление по фиг. 43 может включать в себя название субподрядчика или поставщика материалов, который отклонил проект, отклоненную статью бюджета и причину отклонения. Уведомление по фиг. 43 может обеспечить возможность назначить другого участника на организационную роль. На фиг. 44 представлено уведомление о принятом проекте, которое может быть передано в ходе задачи 210 принятого проекта. Уведомление по фиг. 44 может включать в себя название субподрядчика или поставщика материалов, который принял проект и принятую статью бюджета. Уведомление по фиг. 43 позволяет обеспечить возможность доступ к деталям проекта. На фиг. 45 представлена домашняя страница проекта, которая может быть связана с задачей 211 домашней страницы проекта. Домашняя страница проекта может включать в себя название проекта, информацию о завершенных выделениях средств и информацию о выделениях средств, находящихся на рассмотрении. Домашняя страница проекта может включать в себя обзор проекта с индикатором хода расписания проекта, индикатором хода расходования фондов и индикатором хода завершения в процентах. Домашняя страница проекта может включать в себя одну или несколько связей с конкретными действиями, которые могут быть выполнены в отношении проекта (например, профиль проекта, бюджет проекта, представление участников проекта, установка кодов счета, управления пользователями проекта,инициирование незапланированных выделений средств и т.д.). На фиг. 46 показано уведомление добавления пользователей, которое может быть передано в ходе задачи 208 добавления пользователей. Уведомление по фиг. 46 может включать в себя заявление, подтверждающее, что субподрядчик или поставщик материалов присоединились к проекту. Уведомление по фиг. 46 может включать в себя запрос о субподрядчике или поставщике материалов, для добавления пользователей (например, членов организации) в систему. На фиг. 47 показана форма доступа пользователя по проекту, которая может быть связана с задачей 212 доступа пользователя по проекту. Субподрядчик или поставщик материалов могут выбрать проверку на разрешение доступа каждого пользователя (например, менеджера проекта или подписывающего лица). Форма доступа пользователя проекта может включать в себя название проекта, название ГП и список пользователей в организации-поставщике материалов или субподрядчике.- 14011312 На фиг. 48 представлено уведомление об обязанностях по проекту, которое может быть связано с задачей 214 обязанностей по проекту. Уведомление по фиг. 48 может включать в себя заявление, что обязанности пользователя были изменены, а также новые проверки на разрешение доступа. Уведомление по фиг. 48 может включать в себя связь для доступа к бюджету проекта. На фиг. 49 показан экран представления бюджета проекта, который может быть связан с задачей 216 представления бюджета проекта. ГП или субподрядчик могут обращаться к экрану представления бюджета проекта посредством модуля 36 бюджета. Экран представления бюджета проекта может включать в себя название проекта, название ГП, адрес проекта и список статей бюджета. Список статей бюджета может включать в себя коды фаз, описания кодов фаз, субподрядчика или поставщика материалов,с которым имеется контракт по статье бюджета, величину бюджета, платежи, удержание, баланс и связь с любым из подбюджетов. На фиг. 50 представлена форма ввода бюджета, которая может быть связана с задачей 218 ввода бюджета. ГП или субподрядчик могут обращаться к форме ввода бюджета посредством модуля 36 бюджета. ГП или субподрядчик могут ввести в требуемую информацию, такую как коды фаз, описания кодов фаз и величину бюджета. ГП или субподрядчик могут изменить организацию, связанную с конкретной статьей бюджета. ГП или субподрядчик могут выбрать, является ли организация только обеспечивающей материалы. На фиг. 51 представлен процесс 226 прекращения статьи бюджета, который может быть включен в процесс 94 управления проектом. Процесс 226 прекращения статьи бюджета может быть выполнен ГП или субподрядчиком. Процесс 226 прекращения статьи бюджета может включать в себя задачу 228 ввода бюджета высокого уровня и задачу 230 прекращения бюджета. На фиг. 52 представлена форма ввода бюджета высокого уровня, которая может быть связана с задачей 228 ввода бюджета высокого уровня. ГП или субподрядчик могут обращаться к форме ввода бюджета высокого уровня посредством модуля 36 бюджета. Форма ввода бюджета высокого уровня может включать в себя название проекта, номер проекта, стоимость контракта и список организаций. ГП или субподрядчик могут вводить требуемую информацию, такую как процент удержания, коды фаз, описания кодов фаз, код банковского счета, и то, является ли организация только поставляющей материалы. ГП или субподрядчик могут также выбрать добавление новых статей или прекращение конкретной статьи. Форма ввода бюджета высокого уровня может включать в себя связи с формой установки дат выделения средств и/или формой установки кодов счетов. На фиг. 53 представлен экран прекращения бюджета, который может быть связан с задачей 226 прекращения бюджета. После того, как ГП или субподрядчик выбирает статью для прекращения, экран прекращения бюджета обеспечивает подтверждение и заявление, что любой неоплаченный баланс может быть сделан доступным для переназначения. На фиг. 54 представлен процесс 232 выделения средств, который может быть включен в процесс 96 управления выделением средств. Процесс 232 выделения средств может быть использован для создания расписания для выделений средств по проекту; для инициирования каждого выделения средств; для ввода и подписи счетов; для просмотра находящихся на рассмотрении выделений средств; для выработки счетов, заявлений под присягой и отказов от удержания; для определения, доступны ли фонды; и расходования фондов. Процесс 232 выделения средств может быть выполнен несколькими из участников, использующих модуль 44 выделения средств. Процесс 232 выделения средств может включать в себя задачу 234 создания расписания выделения средств, задачу 236 инициирования выделения средств, задачу 238 ввода счета, задачу 240 ввода формы счета, задачу 242 подписания счета, задачу 244 обновления деталей счета, задачу 246 просмотра ожидающих запросов выделения средств, задачу 248 выработки счета,задачу 250 формирования заявления под присягой, задачу 252 доступных фондов, задачу 254 просмотра запроса выделения средств, задачу 256 подписания отказа от удержания, задачу 258 формирования отказа от удержания, задачу 260 подписания всех отказов от удержания, задачу 262 кнопки просмотра запроса выделения средств с расходуемыми фондами, задачу 266 подписания отказа от удержания, задачу 268 просмотра запроса выделения средств. Процесс 232 выделения средств может также включать в себя задачу 270 принятия деталей платежей, задачу 272 счета, не включенного в выделение средств и задачу 274 не принятия деталей платежа. Процесс232 выделения средств может быть выполнен так, чтобы отказы от удержания были сняты для текущего выделения средств, а не для предыдущего выделения средств. На фиг. 55 представлено уведомление о создании запланированного выделения средств, которое может быть передано в ходе задачи 234 создания расписания выделения средств. Уведомление по фиг. 55 может быть передано в реальном времени всем участникам выделения средств и может включать в себя заявление, что запланированное выделение средств находится на рассмотрении и что участники для выделения средств еще не выбраны. На фиг. 56 показана форма инициирования выделения средств, которая может быть связана с задачей 236 инициирования выделения средств. ГП может обращаться к форме инициирования выделения средств посредством модуля 44 выделения средств. Форма инициирования выделения средств может включать в себя название проекта, номер проекта, адрес проекта, номер выделения средств, дату выделения средств и список потенциальных участников для выделения средств. Список потенциальных участ- 15011312 ников может включать в себя коды фаз, описания кодов фаз, название организации, величину бюджета,величину платежа, препятствие, накопленные удержания и остаточный баланс. ГП может выбрать каждого участника для выделения средств. На фиг. 57 представлено уведомление о вводе счета, которое может быть передано в ходе задачи 238 ввода счета. Уведомление по фиг. 57 может включать в себя заявление, что для проекта запланировано выделение средств и что субподрядчик или поставщик материалов могут ввести детали соответствующих платежей. Уведомление может также включать в себя роль организации и конкретную статью бюджета для субподрядчика или поставщика материалов. Уведомление может быть передано в реальном времени всем участникам выделения средств. На фиг. 58 представлена форма ввода счета, которая может быть связана с задачей 240 формы ввода счета. Субподрядчик или поставщик материалов могут использовать форму ввода счета для обеспечения величины счета для выделения средств. Форма ввода счета может также включать в себя название проекта, номер проекта, адрес проекта, номер выделения средств, дату выделения средств и конкретную статью для этого субподрядчика или поставщика материалов. На фиг. 59 показано уведомление о подписи счета, которое может быть передано ГП в ходе задачи 242 подписи счета. Уведомление по фиг. 59 может включать в себя заявление, что субподрядчик или поставщик материалов одобрили счет на конкретное выделение средств и что заявление под присягой должно быть подписано. СУПС 10 может быть использована для назначения ролей обеспечения безопасности/полномочия каждому пользователю, таких как управление, учет или наличие полномочия подписывать. СУПС 10 может уведомить о пользователе с полномочием подписывать заявление под присягой так, чтобы должностное лицо организации подписывало заявление под присягой, в случае необходимости. СУПС 10 может быть использована для изменения ролей обеспечения безопасности/полномочия,которые являются необходимыми для подписи заявления под присягой (например, заимодатель может требовать, чтобы заявление под присягой подписало должностное лицо, а не администратор для организации). На фиг. 60 представлена форма подписи счета, которая может быть связана с задачей 242 подписи счета. ГП может обращаться к форме подписи счета посредством модуля 44 выделения средств. ГП позволяет просмотреть детали счета, такие как конкретная организации, величина запроса, величина бюджета, величина платежа, накопленное удержание и остаточный баланс. ГП затем может выбрать подпись заявления о счете. Форма подписи счета может включать в себя связь с формой автоматизированного заявления под присягой. На фиг. 61 представляет уведомление об обновленных деталях счета, которое может быть передано ГП в ходе задачи 244 обновленных деталей счета. Уведомление по фиг. 61 может включать в себя заявление, что субподрядчик или поставщик материалов обновили детали платежа для выделения средств на конкретную дату для конкретного проекта. Уведомление может обеспечить связь для того, чтобы представить детали счета. На фиг. 62 показан экран представления находящегося на рассмотрении запроса выделения средств,который может быть связан с задачей 246 представления находящегося на рассмотрении запроса выделения средств. ГП может получить доступ к экрану представления находящегося на рассмотрении запроса выделения средств с помощью модуля 44 выделения средств. ГП может выбрать каждого участника для включения в выделение средств, подтвердить выделение средств и послать уведомление в реальном времени подписывающему лицу каждой организации. Однако ГП также может отклонить ожидающий запрос выделения средств, уведомить выбранных участников о необходимости повторно ввести счет и сообщить причину отклонения запроса выделения средств. Экран представления находящегося на рассмотрении запроса выделения средств может включать в себя название проекта, номер проекта, адрес проекта, номер выделения средств, дату выделения средств, список участников, которые представили счета, и список участников, которые не представили счета. Участники могут быть организованы по кодам фаз. Для каждого кода фазы, экран представления находящихся на рассмотрении запросов выделения средств может включать в себя требуемую величину, величину бюджета, величину платежа, накопленное удержание и остаточный баланс. На фиг. 63 представлено уведомление об отклоненных деталях счета, которое может быть передано в ходе задачи 274 не принятых деталей платежа. Уведомление по фиг. 63 может включать в себя заявление, что детали платежа и счета, введенные конкретным пользователем для выделения средств, которое проводится на некоторую дату для конкретного проекта, не были приняты, и причины отклонения. Уведомление может включать в себя запрос к субподрядчику или поставщику материалов на повторный ввод деталей платежа перед тем, как выделение средств закроется. На фиг. 64 представлен счет, не включенный в уведомление о выделении средств, которое может быть передано в ходе задачи 272 не включенного в выделение средств счета. Уведомление по фиг. 64 может включать в себя заявление, что участник не представлял одобренное заявление под присягой для выделения средств для проекта, и что участник и все его субподрядчики не будут включены в выделение средств. Уведомление может констатировать, что все представленные заявления под присягой и счета были уничтожены.- 16011312 На фиг. 65 представлена автоматически выработанная форма счета (например, форма, которая является совместимой с промышленной практикой, такая как форма G702/703), которая может быть связана с задачей 248 выработки счета (маркирован G702/703 на фиг. 54). ГП, субподрядчики и поставщики материалов могут обращаться к формам счета посредством модуля 44 выделения средств. Субподрядчики,поставщики материалов и/или архитектор могут подписать форму счета с электронным образом (например, с использованием поставщика программного обеспечения электронной подписи, такого, как AlphaTrust Corporation). На фиг. 66 показана автоматически выработанная форма заявления под присягой, которая может быть связана с задачей 250 формы заявления под присягой. ГП может обращаться к форме заявления под присягой посредством модуля 44 выделения средств. ГП может подписывать форму заявления под присягой электронным образом (например, с использованием поставщика программного обеспечения электронной подписи, такого, как AlphaTrust Corporation). На фиг. 67 представлено заявление о сделанных доступными фондах, которое может быть передано в ходе задачи 252 доступных фондов. Уведомление по фиг. 67 может включать в себя инструкции, следовать по связи для запроса отказов от удержания и высвобождения фондов, когда фонды свободны к высвобождению для выделения средств по проекту. На фиг. 68 показан экран представления запроса выделения средств, который может быть связан с задачей 254 представления запроса выделения средств. ГП может получить доступ к экрану представления запроса выделения средств с помощью модуля 44 выделения средств. ГП может просмотреть детали выделения средств, разрешить использование фондов и запросить отказы от удержания. Экран представления запроса выделения средств может включать в себя название проекта, номер проекта, адрес проекта, номер выделения средств, дату выделения средств и список участников выделения средств. Список участников может включать в себя имя участника, код фазы, сведения о том, был ли получен отказ от удержания, затребованную величину, величину бюджета, величину платежа, накопленное удержание и остаточный баланс. Список участников может также включать в себя любого субподрядчика и его отказы от удержания. На фиг. 69 представлено уведомление о подписи отказа от удержания, которое может быть передано в ходе задачи 256 подписи отказа от удержания. Уведомление по фиг. 69 может быть передано в реальном времени всем участникам выделения средств и может включать в себя заявление, что выделение средств, запланированное для проекта, было разрешено, и что от субподрядчика или поставщика материалов требуется подписать свой отказ от удержания, чтобы получить платежи по выделению средств. На фиг. 70 представлена автоматически выработанная форма отказа от удержания, которая может быть связана с задачей 258 формы отказа от удержания. Субподрядчики и поставщики материалов могут обращаться к форме отказа от удержания посредством модуля 44 выделения средств. Форма отказа от удержания может быть автоматически выработана на основании бюджета, с учетом статей для каждого субподрядчика или поставщика материалов. Субподрядчики и поставщики материалов могут подписать формы отказа от удержания электронным образом (например, используя продукты AlphaTrust Corporation, обеспечивающие электронную подпись). После того, как они подписаны, отказы 68 от удержания могут быть сохранены в электронном промежуточном бункере/средстве 54 условного депонирования. На фиг. 71 показано уведомление о подписанном отказе от удержания, которое может быть передано в ходе задачи 266 подписанного отказа от удержания. Уведомление по фиг. 71 может включать в себя заявление, что субподрядчик или поставщик материалов подписал свой отказ от удержания для выделения средств по проекту. Уведомление может включать в себя доступ к деталям выделения средств и отказов от удержания, полученных в настоящий момент. На фиг. 72 показан экран представления запроса выделения средств, который может быть связан с задачей 268 представления запроса выделения средств. ГП, субподрядчик или поставщик материалов могут обращаться к экрану представления запроса выделения средств с помощью модуля 44 выделения средств. Экран прадставления запроса выделения средств может включать в себя название проекта, номер проекта, адрес проекта, номер выделения средств, дату выделения средств и список участников выделения средств. Список участников может включать в себя имя участника, код фазы, сведения о том,был ли получен отказ от удержания, затребованную величину, величину бюджета, величину платежа,накопленное удержание и остаточный баланс. Список участников может также включать в себя любого субподрядчика и его отказы от удержания. На фиг. 73 представлено уведомление о подписании всех отказов от удержания, которое может быть передано в ходе задачи 260 подписания всех отказов от удержания. Уведомление по фиг. 73 может включать в себя заявление, что все отказы от удержания для выделения средств по проекту были подписаны. Уведомление может включать в себя связь для представления деталей выделения средств и расходования фондов. На фиг. 74 показана форма представления запроса выделения средств, которая может быть связана с задачей 262 представления запроса выделения средств с кнопкой выплаты фондов. ГП (или архитектор,владелец, представитель владельца, заимодатель или титульная компания) могут обращаться к форме представления запроса выделения средств и одобрять выделение средств с помощью модуля 44 выделе- 17011312 ния средств и/или модуля 60 одобрения выделения средств. Экран представления запроса выделения средств может включать в себя название проекта, номер проекта, адрес проекта, номер выделения средств, дату выделения средств и список участников выделения средств. Список участников может включать в себя имя участника, код фазы, сведения о том, был ли получен отказ от удержания, затребованную величину, величину бюджета, величину платежа, накопленное удержание и остаточный баланс. Список участников может также включать в себя любого субподрядчика и его отказы от удержания. Когда ГП выплачивает фонды, отказы от удержания по существу одновременно снимаются, и платежное поручение посылают в систему 26 АРПА. На фиг. 75 показано уведомление о выплаченном платеже, которое может быть передано в ходе задачи 264 выплаченных платежей. Уведомление по фиг. 75 может быть передано в реальном времени всем участникам выделения средств и может включать в себя заявление, что платежи выплачены по выделению средств, запланированному на конкретную дату по проекту. На фиг. 76 представлены задачи 276 поддержания системных экранов, которые могут быть включены в процесс 102 управления системным окружением. Задачи 276 поддержания системных экранов могут быть использованы каждым пользователем или каждой организацией для настройки программного окружения в соответствии с конкретными потребностями. Например, организация может настроить коды фаз для своих проектов. Задачи 276 поддержания системных экранов могут быть выполнены любым из участников, использующим администратора 52 системного окружения. Задачи 276 поддержания системных экранов могут включать в себя задачу 278 поддержания кодов фаз, задачу 280 администратора логина пользователя, задачу 282 дополнения/редактирования списка выбора, задачу 284 дополнения/редактирования роли организации, задачу 286 параметров настройки по умолчанию, задачу 288 редактирования уведомлений, задачу 290 конфигурации по умолчанию и задачу 292 дополнения/редактирования роли пользователя. На фиг. 77 представлена форма поддержания кодов фаз, которая может быть связана с задачей 278 поддержания кодов фаз. Каждый участник может обратиться к форме поддержания кодов фаз посредством администратора 52 системного окружения. Участник может добавить новую или удалить выбранную статьи бюджета. На фиг. 78 представлен экран администрирования логина пользователя, который может быть связан с задачей 280 администратора логина пользователя. Каждый участник может обратиться к экрану администратора логина пользователя с помощью администратора 52 системного окружения. Пользователь в организации может ввести в имя пользователя и использовать экран для входа в систему, как любой пользователь в системе. На фиг. 79 показана форма дополнения/редактирования списка выбора, которая может быть связана с задачей 282 дополнения/редактирования списка выбора. Администратор СУПС 10 может добавлять новые или удалять выбранные записи списка выбора (например, списки состояний, типы проектов и т.д.) в различных выпадающих меню, обеспечиваемых СУПС 10. На фиг. 80 представлена форма дополнения/редактирования роли организации, которая может быть связана с задачей 284 дополнения/редактирования роли организации. ГП может обращаться к форме дополнения/редактирования роли организации посредством администратора 52 системного окружения. ГП может выбрать проверку на разрешение доступа для каждого типа организации (например, банка, титульной компании, ГП, субподрядчика или архитектора). На фиг. 81 показана форма задания по умолчанию/конфигурирования параметров настройки, которая может быть связана с задачей 286 параметров настройки по умолчанию. ГП может обращаться к форме задания по умолчанию/конфигурирования параметров настройки посредством администратора 52 системного окружения. ГП может ввести свои предпочтительные параметры настройки, такие как дни напоминания о близком выделении средств, дни напоминания о начале выделения средств, минимальное время выполнения запроса выделения средств, идентификация безопасности, сведения о том, нужно ли инспектору заплатить через систему АРПА, нужно ли ожидать все отказы от удержания, сведения о том,кто платит инспектору (например, банк, титульная компания, владелец, представитель владельца или ГП). На фиг. 82 представлена форма редактирования уведомления, которая может быть связана с задачей 288 редактирования уведомлений. ГП может обращаться к форме редактирования уведомления посредством администратора 52 системного окружения. ГП может изменить уведомления, которые переданы в ходе различных процессов. ГП может выбрать конкретное уведомление и редактировать уведомление по умолчанию по мере необходимости. ГП может также определить, необходимы ли конкретные авторизации, такие как авторизация банка, для изменения уведомления. На фиг. 83 представлена форма задания по умолчанию/конфигурирования процесса, которая может быть связана с задачей 290 конфигураций по умолчанию. ГП, владелец, представитель владельца, заимодатель и т.д. могут обращаться к форме задания по умолчанию/конфигурирования процесса посредством администратора 52 системного окружения для настройки частей процесса платежа в строительстве или изменять правила для частей процесса платежа в строительстве. Например, ГП может определять и сохранять свои собственные коды фаз. ГП, владелец, представитель владельца, заимодатель и т.д. могут- 18011312 выбирать, активировать ли им конкретные задачи в каждом процессе, и могут обращаться к связи для редактирования каждого из уведомлений, связанных с задачами. На фиг. 84 представлена форма дополнения/редактирования роли пользователя, которая может быть связана с задачей 292 дополнения/редактирования роли пользователя. ГП может обращаться к форме дополнения/редактирования роли пользователя посредством администратора 52 системного окружения. ГП может выбирать роли для конкретного пользователя, такие как администратор системы, пользователь справочной службы системы, локальный администратор, регулярный пользователь и доступ только для просмотра. ГП может добавить новые роли или удалить выбранные роли. На фиг. 85 представлены задачи 294 выполнения инспекций, которые могут быть включены в процесс 96 управления выделением средств. Задачи 294 выполнения инспекции могут быть использованы для планирования и облегчения инспекций строительного проекта, если они необходимы перед каждым выделением средств. Задачи 294 выполнения инспекций могут быть выполнены ГП и инспектором с использованием модуля 58 инспекции модуля 94 выделения средств. Задачи 294 выполнения инспекций могут включать в себя задачу 296 требуемой инспекции, задачу 298 формы требуемой инспекции, задачу 300 подготовки к проведению инспекции, задачу 302 представления предыдущих инспекций, задачу 304 ввода инспекции, задачу 306 ввода отчета инспекции, задачу 308 формы отчета инспекции и задачу 310 неуспешного отчета инспекции. На фиг. 86 представлено уведомление о подготовке к проведению инспекции, которое может быть передано в ходе задачи 300 уведомления о подготовке к проведению инспекции. Уведомление по фиг. 86 может включать в себя заявление, что выделение средств запланировано для проекта на некоторую дату,и что от инспектора требуется подготовиться к проведению инспекции для выделения средств. Уведомление может констатировать, что инспекция должна быть проведена только после получения подтверждения. На фиг. 87 представлено уведомление о требуемой инспекции, которое может быть передано в ходе задачи 296 уведомления о требуемой инспекции. Уведомление по фиг. 87 может включать в себя заявление, что запланированное выделение средств находится на рассмотрении для проекта, и связь для определения, требуется ли инспекция для выделения средств. На фиг. 88 представлен экран требуемой инспекции, который может быть связан с задачей 298 требуемой инспекции. ГП (или владелец, представитель владельца, заимодатель или титульная компания) может обращаться к экрану требуемой инспекции посредством модуля 58 инспекции модуля 44 выделения средств. Экран требуемой инспекции может включать в себя название проекта, номер проекта, номер выделения средств, название владельца, дату выделения средств, адрес проекта и список участников. Список участников может включать в себя величину запроса, название организации, роль организации,статью бюджета, величину бюджета, величину платежа, накопленное удержание и остаточный баланс. Экран требуемой инспекции может также включать в себя общие комментарии, комментарии инспектору, и сведения о том, должна ли инспекция быть запланированной. На фиг. 89 представлено уведомление ввода отчета инспекции, которое может быть передано в ходе задачи 304 ввода инспекции. Уведомление по фиг. 89 может включать в себя заявление, что расписание выделения средств на некоторую дату по проекту было авторизовано, и что получатель должен выполнить инспекцию. Уведомление может включать в себя связь для представления деталей проекта и выработки контрольного списка инспекции. На фиг. 90 представлена форма ввода отчета инспекции, которая может быть связана с задачей 306 ввода отчета инспекции. Инспектор может вводить детали инспекции в форму отчета инспекции. Форма отчета инспекции может включать в себя название проекта, номер проекта, номер выделения средств,дату выделения средств, название владельца, адрес проекта, дату инспекции и общие комментарии инспекции. На фиг. 91 представлен экран формы отчета инспекции, который может быть связан с задачей 308 формы отчета инспекции. ГП, владелец, представитель владельца, титульная компания или инспектор могут обращаться к экрану формы отчета инспекции посредством модуля 58 инспекции модуля 44 выделения средств. На фиг. 92 представлено уведомление о неуспешном отчете инспекции, которое может быть передано в ходе задачи 310 неуспешного отчета инспекции. Уведомление по фиг. 92 может включать в себя заявление, что имеется высокий уровень обеспокоенности о проекте после инспекции, проведенной на конкретную дату. Уведомление может включать в себя связь для получения доступа к форме отчета инспекции. На фиг. 93 показан экран представления предыдущих инспекций, который может быть связан с задачей 302 представления предыдущих инспекций. ГП, владелец, представитель владельца, титульная компания или инспектор могут обращаться к экрану представления предыдущих инспекций с помощью модуля 58 инспекции модуля 44 выделения средств и могут выбрать инспекцию, выполненную на конкретную дату. На фиг. 94 представлен процесс 312 одобрения запроса выделения средств, который может быть включен в процесс 96 управления выделением средств. Процесс 312 одобрения запроса выделения- 19011312 средств может быть использован для подтверждения, что необходимые инспекции были выполнены,одобрения каждого выделения средств в процессе платежа в строительстве и выдачи отказов от удержания. Процесс 312 одобрения запроса выделения средств может быть выполнен ГП и/или любым участником выше линии ГП (таким как владелец, представитель владельца, титульная компания, архитектор и т.д.), с использованием модуля 60 одобрения выделения средств модуля 44 выделения средств. Как только проект был инициирован, СУПС 10 может быть использована для одобрения любого типа платежа,связанного с процессом строительства. СУПС 10 позволяет облегчить параллельные одобрения (например, как ГП, так и владелец должны одобрить выделение средств) или последовательность одобрений(например, одобрить выделение средств должен архитектор, затем владелец, затем заимодатель). СУПС 10 может быть использована для конфигурирования процесса одобрения для каждого проекта. СУПС 10 может быть использована для одобрения распоряжения об изменении для бюджета или конкретных величин, которые по контракту определены между сторонами. Например, СУПС 10 может быть использована для получения одобрения от ГП и/или любого участника выше линии ГП для распоряжения об изменении, которое превышает определенную величину, или для одобрения всех распоряжений об изменении после того, как предел был превышен. Процесс 312 одобрения запроса выделения средств может включать в себя задачу 314 Авторизации Запроса Выделения Средств Один, задачу 316 Авторизации Запроса Выделения Средств Один отклонено, задачу 318 подтвержденных инспекций, задачу 320 авторизованной инспекции, задачу 322 модифицированных деталей платежа, задачу 324 уведомления - Авторизации Запроса Выделения Средств Два, задачу 326 Авторизации Запроса Выделения Средств Два, задачу 328 отклонения Авторизации Запроса Выделения Средств Два, задачу 330 разрешения Авторизации Запроса Выделения Средств Два и задачу 332 выдачи отказа от удержания. На фиг. 95 представлена форма Авторизации Запроса Выделения Средств Один или форма авторизации заявления под присягой, которая может быть связана с задачей 314 Авторизации Запроса Выделения Средств Один. ГП, владелец, представитель владельца или титульная компания могут обращаться к форме Авторизации Запроса Выделения Средств Один посредством модуля 44 выделения средств. Форма Авторизации Запроса Выделения Средств Один может включать в себя название проекта, номер проекта, владельца, адрес проекта, номер выделения средств и дату выделения средств. Форма Авторизации Запроса Выделения Средств Один может включать в себя любые вводимые данные для каждой организации, включая величину запроса, название организации, роль организации, статью бюджета, величину бюджета, величину платежа, накопленное удержание и остаточный баланс. Форма Авторизации Запроса Выделения Средств Один может включать в себя полученные авторизации, предстоящие авторизации,сведения о том, требуется ли инспекция, возможность ввести пароль для авторизации и возможность отказать в авторизации и указать причину. На фиг. 96 представлено уведомление отклоненной авторизации первого выделения средств, которое может быть передано в ходе задачи 316 Авторизации Запроса Выделения Средств Один отклонено. Уведомление по фиг. 96 может включать в себя заявление, что в авторизации выделения средств для проекта было отказано, и связь для представления и/или изменения деталей выделения средств. На фиг. 97 представлено уведомление подтвержденной инспекции, которое может быть передано в ходе задачи 318 подтвержденных инспекций. Уведомление по фиг. 97 может включать в себя заявление,что выделение средств, запланированное для проекта, было авторизовано, и инструкции, выполнить инспекцию площадки, а также связь для представления деталей проекта и выработки контрольного списка. На фиг. 98 представлено уведомление о модифицированных деталях платежа, которое может быть передано в ходе задачи 322 модифицированных деталей платежа. Уведомление по фиг. 98 может включать в себя заявление, что детали платежа для выделения средств по проекту не были приняты. В уведомлении могут быть перечислены детали проектного участия и платежей, относящихся к выделению средств, роль организации, статья бюджета и величина платежа. На фиг. 99 представлено уведомление об авторизованной инспекции, которое может быть передано в ходе задачи 320 авторизованной инспекции. Уведомление по фиг. 99 может включать в себя заявление,что инспекция площадки по проекту была авторизована. На фиг. 100 представлено Уведомление Авторизации Запроса Выделения Средств Два, которое может быть передано в ходе Задачи 324 уведомления - Авторизации Запроса Выделения Средств Два. Уведомление по фиг. 100 может включать в себя заявление, что от получателя требуется проверить отчет инспекции, введенный в проект, что разрешение получателя требуется прежде, чем выделение средств может перейти к следующей фазе (например, опрос получателей выделения средств в отношении отказов от удержания), и связь для представления отчета инспекции и предоставления разрешения на выделение средств или отказа от него. На фиг. 101 показана форма Авторизации Запроса Выделения Средств Два, которая может быть связана с задачей 326 Авторизации Запроса Выделения Средств Два. ГП, владелец, представитель владельца или титульная компания могут обращаться к форме Авторизации Запроса Выделения Средств Два с помощью модуля 60 одобрения выделения средств модуля 44 выделения средств. Форма Авторизации Запроса Выделения Средств Два может включать в себя название проекта, номер проекта, владельца, адрес проекта, номер выделения средств и дату выделения средств. Форма Авторизации Запроса- 20011312 Выделения Средств Два может включать в себя любые вводимые данные для каждой организации,включая величину запроса, название организации, роль организации, статью бюджета, величину бюджета, величину платежа, накопленное удержание и остаточный баланс. Форма Авторизации Запроса Выделения Средств Два может включать в себя полученные авторизации, предстоящие авторизации, сведения о том, требуется ли инспекция, возможность ввести пароль для авторизации и возможность отказать в авторизации и указать причину. На фиг. 102 представлено уведомление отклоненной Авторизации Запроса Выделения Средств Два,которое может быть передано в ходе задачи 328 отклоненной Авторизации Запроса Выделения Средств Два. Уведомление по фиг. 102 может включать в себя заявление, что в авторизации выделения средств,запланированного для проекта, отказано участником, и что выделение средств не может произойти без этой авторизации. На фиг. 103 представлено уведомление разрешенной Авторизации Запроса Выделения Средств Два,которое может быть передано в ходе задачи 330 Авторизации Запроса Выделения Средств Два. Уведомление по фиг. 103 может включать в себя заявление, что выделение средств по проекту было авторизовано участником. На фиг. 104 представлено уведомление выдачи отказа от удержания, которое может быть передано в ходе задачи 332 выдачи отказа от удержания. Уведомление по фиг. 104 может включать в себя заявление, что выделение средств, запланированное по проекту, было авторизовано участником, и что от получателя требуется выдать отказ от удержания, чтобы получить платежи по выделению средств, а также связь, позволяющая получателю выдать отказ от удержания. На фиг. 105 представлен процесс 334 запроса изменения, который может быть включен в процесс 98 управления распоряжением об изменении. Процесс 334 запроса изменения может быть использован для изменения полного бюджета проекта (обычно, чтобы расширить бюджет), добавления новых статей,изменения существующих статей или прекращения отношений с субподрядчиками и высвобождения остаточных фондов для других участников. Процесс 334 запроса изменения может быть выполнен ГП,архитектором, владельцем, представителем владельца, заимодателем или субподрядчиком с использованием модуля 48 распоряжения об изменении. Процесс 334 запроса изменения может включать в себя задачу 336 запроса изменения, задачу 338 выданного запроса изменения 338 и задачу 340 авторизации запроса изменения. На фиг. 106 представлена форма запроса изменения, которая может быть связана с задачей 336 запроса изменения. ГП или субподрядчик могут обращаться к форме запроса изменения посредством модуля 48 распоряжения об изменении. Форма запроса изменения может включать в себя название проекта,номер проекта, адрес проекта, название владельца и список величин для изменения. Список величин для изменения может включать в себя величину изменения, название организации, роль организации, статью бюджета, величину бюджета, величину платежа и остаточный баланс. Форма запроса изменения может включать в себя поле описания изменения. Форма запроса изменения может включать в себя сведения,является ли форма платежа займом или платежом владельца, а также является ли способ платежа заемным, чеком владельца или кредитной картой. Форма запроса изменения может включать в себя в настоящее время предполагаемую дату завершения и новую предполагаемую дату завершения. На фиг. 107 представлено уведомление о выданном запросе изменения, которое может быть передано в ходе задачи 338 выданного запроса изменения. Уведомление по фиг. 107 может включать в себя заявление, что по проекту был выдан запрос изменения, и он ожидает авторизации. Уведомление может включать в себя детали запроса изменения, название организации, статью бюджета, текущую величину бюджета и величину изменения. На фиг. 108 представлено уведомление авторизации запроса изменения, которое может быть передано в ходе задачи 340 авторизации запроса изменения. Уведомление по фиг. 108 может включать в себя заявление, что по проекту был выдан запрос изменения и что для запроса изменения требуется одобрение получателя. Уведомление может включать в себя связь для представления деталей запроса изменения, а также для одобрения или отклонения запроса изменения. На фиг. 109 представлен процесс 342 обработки запроса изменения, который может быть включен в процесс 98 управления распоряжением об изменении. Процесс 342 обработки запроса изменения может быть использован для обеспечения гарантии авторизации изменений, сделанных в бюджете, соответствующим участником, таким как архитектор, заимодатель, титульная компания, владелец, представитель владельца или ГП. Процесс 342 обработки запроса изменения может быть выполнен ГП, архитектором,владельцем, представителем владельца, заимодателем или субподрядчиком с использованием модуля 48 распоряжения об изменении. Процесс 342 обработки запроса изменения может включать в себя задачу 344 представления находящихся на рассмотрении запросов изменения, задачу 346 авторизации запроса изменения, задачу 348 отклоненного запроса изменения и задачу 350 одобренного запроса изменения. На фиг. 110 показан экран представления находящегося на рассмотрении запроса изменения, который может быть связан с задачей 344 представления находящегося на рассмотрении запроса изменения. ГП, субподрядчик, владелец, представитель владельца, заимодатель или архитектор могут обращаться к экрану представления находящегося на рассмотрении запроса изменения посредством модуля 48 распо- 21011312 ряжения об изменении. Экран представления находящегося на рассмотрении запроса изменения может включать в себя название проекта, номер проекта, адрес проекта, название владельца и список величин для изменения. Список величин для изменения может включать в себя величину изменения, название организации, роль организации, статью бюджета, величину бюджета, величину платежа и остаточный баланс. Экран представления находящегося на рассмотрении запроса изменения может включать в себя поле описания изменения. Экран представления находящегося на рассмотрении запроса изменения может включать в себя сведения о том, является ли способ платежа заемным, чеком владельца или кредитной картой. Экран представления находящегося на рассмотрении запроса изменения может включать в себя новую предполагаемую дату завершения, полученные авторизации и предстоящие авторизации. На фиг. 111 представлена форма авторизации запроса изменения, которая может быть связана с задачей 346 авторизации запроса изменения. ГП, субподрядчик, владелец, представитель владельца, заимодатель или архитектор могут обращаться к форме авторизации запроса изменения посредством модуля 48 распоряжения об изменении. Форма авторизации запроса изменения может включать в себя название проекта, номер проекта, адрес проекта, название владельца и список величин для изменения. Список величин для изменения может включать в себя величину изменения, название организации, роль организации, статью бюджета, величину бюджета, величину платежа и остаточный баланс. Форма авторизации запроса изменения может включать в себя поле описания изменения. Форма авторизации запроса изменения может включать в себя сведения о том, является ли способ платежа заемным, чеком владельца или кредитной картой. Форма авторизации запроса изменения может включать в себя новую предполагаемую дату завершения, полученные авторизации и предстоящие авторизации. Форма авторизации запроса изменения может включать в себя возможность ввода пароля и авторизации запроса изменения, а также возможность отказаться от запроса изменения и ввести причину отказа. На фиг. 112 представлено уведомление об отклоненном запросе изменения, которое может быть передано в ходе задачи 348 отклоненного запроса изменения. Уведомление по фиг. 112 может включать в себя заявление, что запрос изменения, выданный на некоторую дату по проекту, был отклонен участником. На фиг. 113 представлено уведомление об одобренном запросе изменения, которое может быть передано в ходе задачи 350 одобренного запроса изменения. Уведомление по фиг. 113 может включать в себя заявление, что запрос изменения, выданный на некоторую дату по проекту, был одобрен участником (например, заимодателем). Только запрос изменения может быть использован для изменения полного бюджета проекта (обычно, чтобы расширить бюджет) посредством добавления новых статей, изменения существующих статей или прекращения отношений с субподрядчиками и высвобождения остаточных фондов для других участников. СУПС 10 может быть использована для обеспечения гарантии авторизации изменений, сделанных в бюджете, соответствующим участником, таким как архитектор, заимодатель, титульная компания, владелец, представитель владельца или ГП. Уведомление по фиг. 113 может быть передано, когда соответствующий участник одобрил запрос изменения. На фиг. 114 представлен процесс 352 изменения участника проекта, который может быть включен в процесс 98 управления распоряжением об изменении. Процесс 352 изменения участника проекта может быть использован для того, чтобы, например, прекратить отношения с одним субподрядчиком и сделать остаточные фонды доступными другому участнику (такому как замещающий субподрядчик). Процесс 352 изменения участника проекта может быть выполнен ГП или субподрядчиком с использованием модуля 48 распоряжения об изменении. Процесс 352 изменения участника проекта может включать в себя задачу 354 изменения участника, задачу 356 проверки удаления участника и задачу 358 изменения аффидавита. На фиг. 115 представлен экран изменения участника, который может быть связан с задачей 354 изменения участника. ГП или субподрядчик могут обращаться к экрану изменения участника посредством модуля 48 распоряжения об изменении. Экран изменения участника может включать в себя название проекта, номер проекта, название владельца, адрес проекта и текущий статус проекта. Экран изменения участника может включать в себя список организаций, которые могут быть изменены. Список организаций может включать в себя название организации, роль организации, статью бюджета, величину бюджета, величину платежа, накопленное удержание, остаточный баланс и связь для удаления каждого участника. На фиг. 116 представлен экран проверки удаления участника, который может быть связан с задачей 356 проверки удаления участника. ГП или субподрядчик могут обращаться к экрану проверки удаления участника посредством модуля 48 распоряжения об изменении. Экран проверки удаления участника может включать в себя название проекта, номер проекта, название владельца, адрес проекта и информацию об участнике, подлежащем удалению (например, название организации, роль организации, статью бюджета, величину бюджета, величину платежа, накопленное удержание и остаточный баланс). Экран проверки удаления участника может включать в себя возможность определения того, участвовал ли участник в проекте материально. На фиг. 117 представлен экран изменения аффидавита, который может быть связан с задачей 358 изменения аффидавита. ГП или субподрядчик могут обращаться к экрану изменения аффидавита посред- 22011312 ством модуля 48 распоряжения об изменении. Экран изменения аффидавита может включать в себя название проекта, номер проекта, название владельца, адрес проекта, текущий статус проекта, величину бюджета, предварительно выплаченную на определенную дату величину, удержанную на определенную дату величину и остаточный бюджет. Экран изменения аффидавита может включать в себя поле для ввода комментариев и возможность ввода пароля и разрешения изменения аффидавита. На фиг. 118 представлены задачи 360 поддержания экранов проекта, которые могут быть включены в процесс 94 управления проектом. Задачи 360 поддержания экранов проекта могут быть использованы для редактирования профиля проекта, контактной информацию и для закрытия проекта. Задачи 360 поддержания экранов проекта могут быть выполнены ГП, заимодателем, владельцем или представителем владельца с использованием модуля 28 проекта. Задачи 360 поддержания экранов проекта могут включать в себя задачу 362 профиля проекта, задачу 364 контактной информации по проекту, задачу 366 информации по проекту и задачу 368 закрытия проекта. На фиг. 119 представлена форма профиля проекта, которая может быть связана с задачей 362 профиля проекта. ГП, заимодатель, владелец или представитель владельца могут обращаться к форме профиля проекта посредством модуля 28 проекта. ГП, заимодатель, владелец или представитель владельца могут вводить требуемую информацию, такую как проектная информация, информация о финансировании проекта, информация о владельце проекта, информация о площадке и информация о ГП. На фиг. 120 представлен экран контактной информации по проекту, который может быть связан с задачей 364 контактной информации по проекту. ГП, заимодатель, владелец или представитель владельца могут обращаться к экрану контактной информации по проекту посредством модуля 28 проекта. Экран контактной информации по проекту может включать в себя название проекта, идентификацию проекта, адрес проекта и список контактной информации для участников проекта. Список контактной информации может включать в себя идентификационный номер участника, название организации, роль организации, имя менеджера проектов, контактный адрес электронной почты и контактный телефонный номер. На фиг. 121 представлен экран контактной информации по проекту, который может быть связан с задачей 366 создания информации по проекту. ГП, заимодатель, владелец или представитель владельца могут обращаться к экрану информации по проекту посредством модуля 28 проекта. Экран информации по проекту может включать в себя информацию по проекту, информацию по площадке, информацию о владельце проекта и информацию о ГП. На фиг. 122 представлен экран закрытия проекта, который может быть связан с задачей 368 закрытия проекта. ГП, заимодатель, владелец или представитель владельца могут обращаться к экрану закрытия проекта посредством модуля 28 проекта. Экран закрытия проекта может включать в себя название проекта, номер заемного счета, название владельца и возможность закрыть проект. На фиг. 123 представлены задачи 370 управления экранами доступа, которые могут быть включены в процесс 102 управления системным окружением. Задачи 370 управления экранами доступа могут быть использованы для настройки различных экранов, отображенных для конкретных пользователей или организаций в ходе процесса платежа в строительстве. Например, задачи 370 управления экранами доступа могут быть использованы для включения товарного знака или эмблемы организации в один или большее число экранов, отображаемых в ходе процесса платежа в строительстве (например, товарный знак заимодателя может быть включен в верхний правый угол каждого экрана). Кроме того, задачи 370 управления экранами доступа могут быть использованы для изменения внешнего вида конкретных форм или экранов в соответствии с предпочтениями или требованиями конкретных пользователей или организаций. Задачи 370 управления экранами доступа могут быть выполнены любым из участников с использованием администратора 52 системного окружения. Задачи 370 управления экранами доступа могут включать в себя задачу 372 входа в систему, задачу 374 выхода из системы 374, задачу 376 домашней страницы проекта,задачу 378 сброса пароля, задачу 380 основного экрана, задачу 382 просмотра проектов, задачу 384 забытого пароля и задачу 386 Вашего пароля. На фиг. 124 представлен экран входа в систему, который может быть связан с задачей 372 входа в систему. Каждый участник может обращаться к экрану входа в систему посредством администратора 38 доступа. Участник может ввести имя пользователя и пароль для входа в систему. Экран входа в систему может обеспечить связь, если пользователь забыл свой пароль. На фиг. 125 представлен экран выхода из системы, который может быть связан с задачей 374 выхода из системы. Каждый участник может обращаться к экрану выхода из системы посредством администратора 38 доступа. Экран выхода из системы может подтвердить, что пользователь вышел из системы. На фиг. 126 представлен экран домашней страницы проекта, который может быть связан с задачей 376 домашней страницы проекта. Каждый участник может обращаться к экрану домашней страницы проекта посредством администратора 38 доступа. Экран домашней страницы проекта может включать в себя название проекта, количество новых сообщений и связи для прочтения новых сообщений. Домашняя страница проекта может включать в себя обзорную информацию по проекту (включая индикатор хода расписания проекта и индикатор хода расходования фондов), информацию о выполненных выделениях средств (включая количество выделений средств, дату выделения средств и связи к информации по- 23011312 выделениям средств), информацию о находящихся на рассмотрении выделениях средств (включая количество выделений средств и дату начала). Домашняя страница проекта может включать в себя связи к нескольким действиям, формам или экранам (например, профилю проекта, бюджету проекта, представлению участников проекта, установке кодов счета, управлению пользователями проекта, отслеживанием одобрения титульной компании, инициированию незапланированного выделения средств и т.д.). На фиг. 127 представлен экран сброса пароля, который может быть связан с задачей 378 сброса пароля. Каждый участник может обращаться к экрану сброса пароля посредством администратора 38 доступа. Участник может ввести новый пароль дважды для того, чтобы изменить пароль, связанный с конкретным именем пользователя. На фиг. 128 представлен основной экран для конкретного пользователя, который может быть связан с задачей 380 основного экрана. Каждый участник может обращаться к основному экрану посредством администратора 38 доступа. На основном экране могут быть перечислены проекты, в которые вовлечен участник, а также коллчество новых сообщений, связанных с каждым проектом, и связь для прочтения новых сообщений. На фиг. 129 представлен экран просмотра проектов, который может быть связан с задачей 382 просмотра проектов. Каждый участник может получить доступ к экрану просмотра проектов посредством администратора 38 доступа. Экран просмотра проектов может включать в себя функциональную возможность поиска проекта и список проектов. Список проектов может включать в себя название проекта,название ГП, связь для редактирования проекта и возможность выбрать один или несколько проектов для просмотра. На фиг. 130 представлен экран забытого пароля, который может быть связан с задачей 384 забытого пароля. Каждый участник может обращаться к экрану забытого пароля посредством администратора 38 доступа. Пользователь может ввести свое имя пользователя и адрес электронной почты, а система может послать пароль пользователю по электронной почте. На фиг. 131 представлено уведомление о Вашем пароле, которое может быть передано в ходе задачи 386 Вашего пароля. Уведомление по фиг. 131 может включать в себя заявление, что Ваш пароль, который Вы запросили, направлен Вам по электронной почте, пароль и предложение, использовать пароль в следующий раз, когда Вы будете входить в систему. На фиг. 132 представлен процесс 388 управления экранами сообщения, который может быть включен в процесс 102 управления системным окружением. Процесс 388 управления экранами сообщения может быть использован для представления сообщений, создания сообщений или представления сообщения статуса системы. Процесс 388 управления экранами сообщения может быть выполнен любым из участников с использованием администратора 52 системного окружения. Процесс 388 управления экранами сообщения может включать в себя задачу 390 представления сообщения, задачу 392 представления особого сообщения, задачу 394 создания сообщения и задачу 396 сообщения состояния. На фиг. 133 показан экран представления сообщений, который может быть связан с задачей 390 представления сообщения. Каждый участник может обратиться к задаче 390 представления сообщения посредством администратора 52 системного окружения. Экран представления сообщения может включать в себя название пользователя, возможность определять тип сообщений, которые отображены (например, непрочитанные, недавние, все, посланные сообщения или заархивированные), и список сообщений определенного типа. Список сообщений может включать в себя возможность выбора конкретных сообщений, дат сообщений, названия проекта, предмета сообщения, а также того, требуется ли совершение действия. Экран представления сообщения может также обеспечить возможность архивировать выбранные сообщения и переходить к другому экрану сообщений. На фиг. 134 показано особое сообщение, просматриваемое пользователем. Особое сообщение может включать в себя любое из уведомлений, показанных и описанных в настоящих материалах. На фиг. 135 представлен экран создания/отправки сообщений, который может быть связан с задачей 394 создания сообщения. Каждый участник может обращаться к экрану создания/отправки сообщения посредством администратора 52 системного окружения. Пользователь может ввести в название проекта,указать, послать ли сообщение организации или пользователю, ввести названия организаций, имена пользователей, предмет сообщения и сообщение. На фиг. 136 представлен экран сообщения состояния, который может быть связан с задачей 396 сообщения состояния. Каждый участник может обращаться к экрану сообщения состояния посредством администратора 52 системного окружения. На экране сообщения состояния могут быть размещены сообщения, такие как заявление, что по проекту было инициировано выделение средств и что все участники были уведомлены. Экран сообщения состояния может включать в себя связь с домашней страницей организации или пользователя. На фиг. 137-153 представлен способ управления процессом платежа в строительстве в соответствии с другим вариантом осуществления изобретения. Аспекты способа по фиг. 137-153 могут быть использованы в совокупности с вариантом осуществления изобретения, показанным и описанным со ссылкой на фиг. 1-136 и фиг. 154-179. На фиг. 154-179 показаны диаграммы ввода/вывода для способа управления процессом платежа в- 24011312 строительстве, в соответствии с еще одним другим вариантом осуществления изобретения. Аспекты способа по фиг. 154-179 могут быть использованы в совокупности с вариантами осуществления изобретения, показанными и описанными со ссылкой на фиг. 1-136 и фиг. 137-153. На фиг. 155 представлены задача открытия проекта, задача создания расписания выделения средства и задача идентификации и назначения ролей по проекту, каждая из которых может быть выполнена ГП. Задача ввода бюджета может быть выполнена владельцем, представителем владельца, ГП, заимодателем или титульной компанией. Задача обновления деталей может быть выполнена ГП для субподрядчиков и/или поставщиков материалов либо владельцем, заимодателем, либо титульной компанией для любого типа участника. Задача закрытия проекта может быть выполнена титульной компанией, ГП или заимодателем. На фиг. 156 представлена задача ввода деталей проекта, в которой система может предположить,что проект имеет полное одобрение от всех необходимых агентств и участвующих организаций перед открытием проекта. Фиг. 156 включает в себя ввод деталей займа, при котором заимодатель может выбрать ввод только выбранной информации по правовым или деловым причинам. Если для проекта нет никакого займа, то никакая информация не вводится. Фиг. 157 содержит задачу рассмотрения предложенного расписания выделения средств, при которой система может выработать предложенное расписание выделения средств путем равного разнесения количества выделений средств по предполагаемому расписанию проекта. Фиг. 157 представляет задачу принятия или отклонения предложенного расписания выделения средств, при которой ГП может вручную объявить выделения средств в соответствии с расписанием (планом), установленным владельцем,представителем владельца, заимодателем или ГП. Автоматизированное расписание может быть отвергнуто, и расписание может поддерживаться вручную. На фиг. 159 представлен ввод бюджета проекта для участвующей организации, где может быть использован иерархический процесс. На каждом уровне, участвующая организация может выполнить процесс для организаций, который они используют, чтобы поддержать их. На фиг. 160 представлена задача авторизации распоряжения об изменении, при которой процесс решения проблемы может потребовать отклонения первоначального распоряжения об изменении и создания второго распоряжения об изменении, которое взаимно согласуемо всеми сторонами. В процессе решения только заключительное распоряжение об изменении должно быть одобрено. На фиг. 162 представлена задача добавления организации, при которой должна быть добавлена организация перед тем, как она сможет участвовать в проекте. Добавлять организации в систему могут система, титульная компания, заимодатель или ГП. Наряду с тем, что организации могут быть добавлены в ходе задачи идентификации и назначения ролей по проекту процесса поддержания плана платежей по проекту, организации могут быть добавлены и независимо от этого процесса. На фиг. 162 представлена задача ввода деталей организации, при которой первоначальный контакт в организации может быть ответственным за ввод деталей своей организации и дополнительной контактной информации. Каждая организация может идентифицировать внутреннего администратора системы, который может быть ответственным за обновление деталей своей организации и контактной информации. На фиг. 162 представлена задача поддержания деталей организации, при которой требования по безопасности могут быть особенно строгими в силу особых требований к финансовой информации. На фиг. 164 представлена задача проверки организации, которая может быть обеспечена третьим лицом на основании требований участников. Система позволяет облегчить проверку организаций и взимать плату за обслуживание. На фиг. 166 представлена задача объявления о выделении средств, которая может быть выполнена ГП. Выделение средств представляет собой механизм, посредством которого участники проекта могут представить счета, владелец (обычно посредством ГП) может заплатить за выполненную работу, а участвующие стороны могут получить платеж и снять свои соответствующие отказы от удержания. На фиг. 166 представлена задача выработки заявления под присягой, при которой ГП может рассмотреть подачи в онлайновом режиме (со ссылкой на документацию на бумажном носителе, если необходимо) и если подача правильная, система может выработать заявление под присягой на основании информации, которая была электронным образом представлена сторонами, участвующими в выделении средств. ГП может отклонить подачи, и они могут быть пересмотрены и повторно представлены для одобрения. Этот механизм может быть использован для разрешения любых проблем со счетом. На фиг. 166 представлена задача запроса инспекции, которая обычно может быть выполнена заимодателем или титульной компанией. На фиг. 166 представлена задача авторизации выделения средств, которая обычно может быть выполнена заимодателем, но может потребовать и вовлечения владельца, представителя владельца или другого назначенного участника проекта. Конфигурируемый механизм разрешения может включать любого участника проекта в процесс авторизации. На фиг. 166 представлена задача ввода и устроения отказов от удержания, которая может требоваться для завершения выделения средств. Фонды не переводят сторонам выставления счета, пока отказы от удержания сторон не будут введены и организованы. Это требование гарантирует, по существу, одновременное выполнение снятия отказа от удержания и платежа. На фиг. 166 представлена задача выполнения одновременного платежа/отказа от удержания, при которой, по- 25011312 существу, одновременный обмен отказом от удержания на платеж является автоматизированным. Такой автоматизированный обмен может устранить потребность во встречах и может устранить задержки по времени между выдачей отказа от удержания и платежом. Такой автоматизированный обмен позволяет уменьшить вероятность того, что отказ от удержания будет потерян, и позволяет ускорить платеж всем участникам выделения средств, устраняя промежуточные организации из процесса платежа. На фиг. 167 представлена задача объявления выделения средств, при которой электронное сообщение может быть послано по существу одновременно всем участвующим и/или заинтересованным организациям. На фиг. 168 представлена задача ввода деталей счета, которая может быть выполнена любой стороной, которая желает получить оплату с помощью процесса выделения средств. Электронная подача может сопровождаться бумажными документами, которые сопровождают подачу. Может быть обеспечена служба, которая позволяет сторонам представлять сопровождающую информацию путем сканирования. На фиг. 169 представлена задача авторизации счета, при которой процесс решения проблемы может потребовать отклонения первоначального счета и создания второго счета, который является взаимно согласуемым всеми сторонами. Только заключительный счет будет одобрен в процессе решения. На фиг. 170 представлена задача выбора инспектора, при которой с проектом может быть связано более одного инспектора. В этом случае, для выполнения инспекции должен быть выбран правильный инспектор. На фиг. 171 представлена задача подтверждения объема инспекции, при которой организация, запросившая инспекцию, может определить объем инспекции, либо для всего заявления под присягой, либо для сокращенного варианта заявления под присягой. На фиг. 171 представлена задача ввода результатов инспекции, в которой сопроводительная документация может быть необходима в зависимости от объема и сущности инспекции. На фиг. 171 представлена задача направления вспомогательной документации, при которой система может позволить присоединять файлы с цифровыми фотографиями или другим электронным материалом к электронным отчетам инспекции. На фиг. 173 представлена задача организации отказа от удержания, при которой подписанный электронным образом отказ от удержания может быть организован в системе, защищенной от любых изменений. В одном варианте осуществления изобретения, отказ от удержания не выдается титульной компании, пока не произойдет, по существу, одновременный обмен платежами и отказами от удержания. На фиг. 174 представлена задача подтверждения авторизации выделения средств и организованных отказов от удержания, которая может включать в себя обзор всех отказов от удержания для гарантии того, что они полны и правильны. На фиг. 178 представлена задача обеспечения поддержки пользователя, которая может включать в себя поддержку добавления или изменения организаций или проектов, урегулирования проблем с паролем, урегулирования проектов и сделок. На фиг. 178 представлена задача администрирования системы,которая может включать в себя администрирование безопасности, финансовой ревизии и поддержки в случае непредвиденного обстоятельства. На фиг. 178 представлена задача поддержания истории действий для участников системы, которая может включать в себя справочник по продавцам с историей о продавцах и/или рейтингами продавцов. Для среднего специалиста в данной области техники очевидным является, что варианты осуществления изобретения могут быть реализованы с использованием различных компьютерных устройств, таких как персональные компьютеры, серверы и другие устройства, которые имеют процессоры или которые могут выполнять программы или наборы инструкций. Вообще говоря, изобретение может быть осуществлено с использованием существующих аппаратных средств или аппаратных средств, которые могут быть легко созданы средними специалистами в данной области техники. Таким образом, архитектура представленных в качестве примеров устройств не всегда объясняется подробно, однако имеется в ввиду,что устройства обычно содержат процессор, память (некоторого вида) и приложения ввода и вывода. Процессор может быть микропроцессором, программируемым логическим управляющим устройством,проблемно-ориентированной интегральной схемой или вычислительным устройством, конфигурированным так, чтобы извлекать и выполнять инструкции. В некоторых случаях, устройства могут также иметь операционные системы и прикладные программы, которыми управляют операционные системы. Следует отметить, что, хотя системы 40 и 80 управления показаны соединенными в сеть, никакая определенная конфигурация сети не подразумевается. Одна или несколько сетей или систем связи, таких как Интернет,телефонные системы, беспроводные сети, спутниковые сети, сети кабельного телевидения и различные другие частные и общественные сети, могут быть использованы в различных комбинациях для обеспечения линий коммуникации, желаемых или необходимых для создания вариантов осуществления или выполнения изобретения, так, как это будет очевидным среднему специалисту в данной области техники. Таким образом, изобретение не ограничено какими-либо определенной сетью или комбинациями сетей. Различные признаки и преимущества изобретения сформулированы в нижеследующей формуле изобретения.- 26011312 ФОРМУЛА ИЗОБРЕТЕНИЯ 1. Способ управления процессом платежа в строительстве, включающий в себя действия по выработке бюджета для строительного проекта посредством по меньшей мере одной электронной формы; получению величины счета от по меньшей мере одного участника строительного проекта посредством по меньшей мере одной компьютерной сети; выработке по меньшей мере одного из автоматизированного счета и автоматизированного заявления под присягой на основании величины счета и бюджета; выработке по меньшей мере одного автоматизированного отказа от удержания на основании по меньшей мере одного из автоматизированного счета и автоматизированного заявления под присягой; электронному выполнению по меньшей мере одного из автоматизированного счета и автоматизированного заявления под присягой и по меньшей мере одного автоматизированного отказа от удержания для создания по меньшей мере одного из юридически обязывающего счета, юридически обязывающего заявления под присягой и юридически обязывающего отказа от удержания. 2. Способ по п.1, дополнительно включающий в себя действие по передаче уведомления в отношении одобрения автоматизированного счета. 3. Способ по п.1, в котором выработанный бюджет включает в себя множество статей, а выработанный автоматизированный счет включает в себя по меньшей мере одну из множества статей. 4. Способ по п.1, в котором выработанный бюджет включает в себя по меньшей мере одну из стоимостей от организации, не нанятой генеральным подрядчиком строительного проекта, и стоимостей организации, нанятой генеральным подрядчиком. 5. Способ по п.1, дополнительно включающий в себя действие по обеспечению того, что автоматизированное заявление под присягой и по меньшей мере один автоматизированный отказ от удержания соответствуют по меньшей мере одному автоматизированному счету. 6. Способ по п.1, дополнительно включающий в себя действие по обеспечению того, что сумма величин в долларах по счету, содержащаяся в автоматизированном счете, равна величине в долларах по заявлению под присягой, содержащейся в автоматизированном заявлении под присягой. 7. Способ по п.1, дополнительно включающий в себя действие по обеспечению того, что величина в долларах по счету, содержащаяся в автоматизированном счете, равна величине в долларах по отказу от удержания, содержащейся по меньшей мере в одном автоматизированном отказе от удержания. 8. Способ по п.1, в котором действия по выработке по меньшей мере одного из автоматизированного счета и автоматизированного заявления под присягой и выработке по меньшей мере одного автоматизированного отказа от удержания включает в себя выработку автоматизированного счета, одобрение автоматизированного счета, последующую выработку автоматизированного заявления под присягой, одобрение автоматизированного заявления под присягой и последующую выработку по меньшей мере одного отказа от удержания. 9. Способ по п.1, дополнительно включающий в себя действие по автоматическому снятию юридически обязывающего отказа от удержания после получения участником платежа от платежной системы. 10. Система управления платежом в строительстве, включающая в себя сервер приложений, сохраняющий электронный промежуточный бункер и модуль выделения средств, причем электронный промежуточный бункер получает отказ от удержания от участника строительного проекта, а модуль выделения средств передает платеж участнику в ответ на получение отказа от удержания и снимает отказ от удержания в ответ на платеж. 11. Система управления платежом в строительстве по п.10, в которой электронный промежуточный бункер сохраняет отказ от удержания. 12. Система управления платежом в строительстве по п.10, в которой модуль выделения средств передает платеж участнику посредством передачи платежной системе автоматизированной инструкции заплатить участнику. 13. Система управления платежом в строительстве по п.12, в которой модуль выделения средств снимает отказ от удержания посредством получения формы подтверждения от платежной системы, что участник получил фонды и, по существу, одновременно снимает отказ от удержания после получения подтверждения. 14. Система управления платежом в строительстве по п.10, в которой электронный промежуточный бункер получает множество отказов от удержания от множества участников и сохраняет каждый из множества отказов от удержания, пока не получено все множество отказов от удержания; причем модуль выделения средств передает автоматизированную инструкцию - заплатить множеству участников, когда получено все множество отказов от удержания. 15. Система управления платежом в строительстве по п.10, в которой электронный промежуточный бункер получает множество отказов от удержания от множества участников и сохраняет каждый из множества отказов от удержания, а модуль выделения средств передает автоматизированную инструкцию заплатить каждому из множества участников, когда получен каждый из множества отказов от удержания.- 27011312 16. Система управления платежом в строительстве по п.10, в которой электронный промежуточный бункер получает множество отказов от удержания от множества участников и сохраняет каждый из множества отказов от удержания, а модуль выделения средств передает первую инструкцию - заплатить по меньшей мере одному из множества участников, когда получен по меньшей мере один из множества отказов от удержания, и вторую инструкцию - заплатить по меньшей мере одному другому из множества участников, когда получено все множество отказов от удержания. 17. Система управления платежом в строительстве по п.12, в которой платежная система включает в себя по меньшей мере одно из автоматизированной системы расчетной палаты, системы банковского перевода, системы дебетовой карты и системы кредитной карты. 18. Система управления платежом в строительстве по п.10, в которой электронный промежуточный бункер и модуль выделения средств получают и снимают отказ от удержания, соответствующий работе,выполненной для текущего выделения средств. 19. Система управления платежом в строительстве по п.10, в которой сервер приложений сохраняет модуль бюджета, вырабатывающий бюджет для строительного проекта и модуль выделения средств,вырабатывающий по меньшей мере один автоматизированный счет, автоматизированное заявление под присягой и по меньшей мере один автоматизированный отказ от удержания на основании бюджета. 20. Система управления платежом в строительстве по п.10, дополнительно включающая в себя службу электронной подписи для выполнения электронным образом отказа от удержания.
МПК / Метки
МПК: G06F 17/16
Метки: система, способ, управления, строительстве, платежом
Код ссылки
<a href="https://eas.patents.su/30-11312-sistema-i-sposob-upravleniya-platezhom-v-stroitelstve.html" rel="bookmark" title="База патентов Евразийского Союза">Система и способ управления платежом в строительстве</a>