> For the complete documentation index, see [llms.txt](https://docs.pyck.cloud/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.pyck.cloud/graphql-api/types/repository.md). # Repository Repository Type Audience: Programmer Represents a storage location in the warehouse system. Repositories can be anything that holds goods - from entire warehouses down to individual bins or movable containers like pallets. ## Fields | Field | Type | Description | | -------------- | ----------------- | ----------------------------------------------------------------------- | | `id` | `ID!` | Unique identifier of the repository | | `tenantID` | `UUID!` | Tenant identifier | | `createdAt` | `Time!` | Creation timestamp | | `createdBy` | `UUID!` | User identifier who created the repository | | `updatedAt` | `Time` | Last update timestamp | | `updatedBy` | `UUID` | User identifier who last updated the repository | | `deletedAt` | `Time` | Deletion timestamp | | `deletedBy` | `UUID` | User identifier who deleted the repository | | `dataTypeID` | `UUID` | Data type identifier | | `dataTypeSlug` | `String` | Data type slug | | `data` | `Map` | Custom data associated with the repository | | `parentID` | `ID` | Edge reference ID to the parent repository (null for root repositories) | | `locationID` | `UUID` | Optional reference to a Location entity for geographic/logical grouping | | `name` | `String!` | Name of the repository | | `layout` | `String` | Layout configuration | | `type` | `RepositoryType!` | Type (static or dynamic) | | `virtualRepo` | `Boolean!` | Whether this is a virtual repository | ## Connection Fields All relationship fields return Connection objects that support pagination, filtering, and ordering. | Field | Connection Type | Description | | ------------------------------------ | ------------------------------- | ----------------------------------------------------------- | | `parent` | `Repository` | Parent repository in the hierarchy (resolved from parentID) | | `children` | `RepositoryConnection!` | Child repositories in the hierarchy | | `itemMovementToRepositories` | `ItemMovementConnection!` | Item movements where this repository is the destination | | `itemMovementFromRepositories` | `ItemMovementConnection!` | Item movements where this repository is the source | | `repositoryMovementToRepositories` | `RepositoryMovementConnection!` | Repository movements where this is the destination | | `repositoryMovementFromRepositories` | `RepositoryMovementConnection!` | Repository movements where this is the source | | `repositoryMovementRepositories` | `RepositoryMovementConnection!` | Repository movements for this repository | | `repositoryTransactions` | `TransactionConnection!` | Transaction records for this repository | | `repositoryStocks` | `StockConnection!` | Stock records in this repository | ### Connection Arguments Each connection field accepts the following arguments: | Argument | Type | Description | | --------- | ------------- | ----------------------------------------------- | | `after` | `Cursor` | Returns elements after this cursor | | `first` | `Int` | Returns the first n elements | | `before` | `Cursor` | Returns elements before this cursor | | `last` | `Int` | Returns the last n elements | | `orderBy` | `*Order` | Ordering options (specific to each connection) | | `where` | `*WhereInput` | Filtering options (specific to each connection) | ## Interfaces * `Node` ## Repository Types * **Static Repository**: Fixed locations like warehouses, zones, shelves, bins * **Dynamic Repository**: Movable containers like pallets, totes, trolleys, forklifts ## Virtual Repositories Virtual repositories allow stock to be allocated without validation. They're used at warehouse boundaries: * Incoming goods (supplier deliveries) * Outgoing shipments (customer orders) * Adjustments (damaged, stolen, corrections) ## Location Association The optional `locationID` field allows repositories to be associated with a Location entity. This enables: * Geographic grouping of repositories by physical location * Multi-site warehouse management * Location-based access control and reporting * Integration with the location management system When set, the repository is logically associated with the specified location, enabling queries and workflows to filter repositories by their physical or logical location. ## Usage Example ### Query Root Repositories with Children ```graphql query { repositories( where: { type: static, virtualRepo: false, hasParent: false } ) { edges { node { id name type virtualRepo data parent { id name } children(first: 50) { edges { node { id name type } } totalCount } repositoryStocks(first: 100) { edges { node { itemID quantity ownQuantity } } totalCount } } } } } ``` ### Query Repositories with Parent Filtering ```graphql query { repositories( where: { hasParentWith: [ { name: "Main Warehouse" } ] } ) { edges { node { id name parent { id name } } } } } ``` ### Query Repositories with Children Filtering ```graphql query { repositories( where: { hasChildren: true, hasChildrenWith: [ { type: static } ] } ) { edges { node { id name children(first: 20, orderBy: { direction: ASC, field: NAME }) { edges { node { id name type } } pageInfo { hasNextPage endCursor } totalCount } } } } } ``` ### Query Repository with Item Movements ```graphql query { repositories(where: { name: "Main Warehouse" }) { edges { node { id name itemMovementToRepositories(first: 10) { edges { node { id executed handler } } totalCount } itemMovementFromRepositories(first: 10) { edges { node { id executed handler } } totalCount } } } } } ``` ### Query Repositories by Location ```graphql query { repositories( where: { locationIDNotNil: true } ) { edges { node { id name locationID type virtualRepo } } } } ``` ## Breaking Changes The following breaking changes were introduced in this version: 1. **parentID field type changed**: The `parentID` field changed from `UUID` to `ID` (edge reference). This reflects the change from a direct UUID field to a proper GraphQL edge relationship. 2. **New edge predicates**: Use `hasParent`, `hasParentWith`, `hasChildren`, and `hasChildrenWith` for filtering instead of direct parentID comparisons. 3. **Removed filters**: The following parentID filters have been removed: * `parentIDGT` * `parentIDGTE` * `parentIDLT` * `parentIDLTE` ## Notes * Root-level repositories (parentID = null) typically represent warehouses * The actual purpose (warehouse, shelf, bin, etc.) is determined by naming and hierarchy * Virtual repositories don't enforce stock validation for movements * Dynamic repositories can change parents via repository movements * Use `hasParent: false` to find root repositories instead of `parentIDIsNil: true` * The `locationID` field enables location-based grouping and filtering of repositories ## New Fields (2025-01) {% hint style="info" %} **New Field**: `locationID` (UUID, optional) - Associates the repository with a Location entity for geographic/logical grouping. This enables multi-site warehouse management and location-based filtering. {% endhint %} --- # 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 by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.pyck.cloud/graphql-api/types/repository.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. 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.