> For the complete documentation index, see [llms.txt](https://wiki.dieagenturverwaltung.de/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://wiki.dieagenturverwaltung.de/die-agenturverwaltung-en/projektverwaltung-1/projekte.md). # Jobs Die Agenturverwaltung uses three hierarchical levels to represent the client side: customer > customer account > **job**. ![](/files/87ae9d36da440b16c173e853f5a28890e6e7bf10) One or more customer accounts can be managed for a customer. \ Within a customer account there can be one or more jobs.\ This page deals with the lowest level: **the job**. The job is the level at which an agency's operational work is represented. Among other things, the following are done here: * tasks (formerly processes) are managed * project reportings are provided * financial documents related to the job are collected * agency services and external services as well as project budgets are monitored * project documents and notes are maintained * access rights are managed * job-related followups are created and viewed A job is also the basis for many operational processes in Die Agenturverwaltung: * project staff book time to jobs * external services are assigned to jobs * tasks (formerly processes) can be managed in jobs * estimates are created as part of jobs * expenditures from jobs are transferred into invoices * in some cases credit invoices are even created in jobs How you create, configure, monitor and bill jobs is explained on the subpages. ## The job number The job number is the unique identifier that is generated when creating a job according to the pattern you specify. This number can, for example, be given to suppliers so that they can reference the job later when invoicing. This saves a lot of time during document entry. You can find out here what pattern a job number can be built from: {% content-ref url="/pages/9aa90ec1091c6ac7845a2f66db133135778e063f" %} [Numbering systems](/die-agenturverwaltung-en/onboarding/nummernsysteme.md) {% endcontent-ref %} ## Job status {% embed url="" %} A job can have its status set to `active` to `closed` when it is completed. No further working times or external services can then be booked to it. New financial documents such as estimates, credit invoices or invoices can also no longer be created for these jobs. A job in the status `to be billed` indicates that the work is completed and the job is waiting to be billed by the responsible person. The status `dormant` documents that a job is currently not closed but behaves like a closed job, i.e. no times can be booked to it, for example. {% hint style="info" %} **Allow status changes only with certain permissions**\ It can also be defined that a user can only change a status under certain conditions - e.g. only with administrator rights. \ One usage scenario would be, for example, to allow only administrators to reopen an already closed job.\ If you have such rules in your processes, contact our customer service; you can define them under Settings > Process Definitions > Status Configurator for Jobs. {% endhint %} ## When should a job be divided? Breaking jobs down into sub-steps makes sense for a variety of reasons, for example because partial sections are easier to estimate, approve in procurement and bill. Further notes on this in our blog:\ Evaluation of multiple jobs To evaluate groups of jobs, customer accounts are suitable, or if the jobs cannot be together in one customer account for certain reasons, user-defined filters. With these filters it is, for example, possible to evaluate all jobs in a particular industry or all media jobs. How user-defined filters are used is explained here: {% content-ref url="/pages/2ec948877648f44dd85c71acbef4cfc1c0e6a160" %} [Custom filters](/die-agenturverwaltung-en/einstellungen-1/berichte/benutzerdefinierte-filter.md) {% endcontent-ref %} --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://wiki.dieagenturverwaltung.de/die-agenturverwaltung-en/projektverwaltung-1/projekte.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.