Network permissions and catalog standardsПрава и каталог сети: общее и местное

Preserve stable record identityСохраните устойчивую идентичность записи

Name a catalog steward who owns identifiers, variants, units and rules for adding entries. A local display name may differ while retaining its link to the shared record. Before creating an item, an employee checks existing variants and submits a request with a label example. Matching names do not prove items are identical; different names do not necessarily identify different products. Use the properties that actually distinguish business transactions.Назначьте владельца справочника, который отвечает за идентификатор, вариант, единицу и правила добавления позиции. Местное название для витрины может отличаться, но связь с исходной записью должна сохраняться. До создания нового товара сотрудник проверяет существующие варианты и подаёт запрос с образцом маркировки. Совпадающее название ещё не доказывает одинаковую позицию; различающиеся названия не всегда означают разные товары. Важны свойства, по которым бизнес реально различает операции.

Changing a unit or merging duplicates requires checking linked orders and history. Do not reuse an old identifier for a different item: earlier records must remain understandable. For an obsolete entry, define how new use stops while past transactions remain available. Describe changes as a version transition with an owner and effective date. Copying a branch database wholesale does not establish common identifiers and can multiply existing inconsistencies.Исправление единицы или объединение дублей требует проверки связанных заказов и истории. Не переиспользуйте старый идентификатор для другого товара: прошлые записи должны оставаться объяснимыми. Для устаревшей позиции определите прекращение нового использования и доступ к прежним операциям. Изменения сначала описывают как переход между версиями с ответственным и датой применения. Копирование базы филиала целиком не заменяет согласование общих идентификаторов и может размножить уже существующие расхождения.

Separate local settings from the standardОтделите местные настройки от стандарта

List which fields are shared across the network, controlled locally or changeable only by exception. Local availability might depend on branch format while the item unit remains common. For pricing or other commercial limits, use the business’s approved boundaries and authority. Define precedence when a shared rule and a local variation affect the same record. Employees should be able to explain why a particular value applies now.Составьте явный перечень полей: общие для сети, управляемые точкой и доступные только по исключению. Например, локальная доступность может зависеть от формата филиала, а единица позиции остаётся общей. Для ценовых или иных коммерческих ограничений используйте утверждённые бизнесом границы и полномочия. Опишите приоритет правил, когда на одну запись действуют общий стандарт и местное изменение. Сотрудник должен понимать, почему именно это значение применяется сейчас.

A temporary variation needs a branch, affected entries, reason, approver, start and end. Before applying it, check whether it expands a customer promise beyond what was approved. At expiry, an owner confirms restoration of the standard or records another decision. Define how existing orders are treated separately: catalog changes must not silently rewrite recorded commitments. An enduring local difference belongs in an approved rule rather than an indefinitely extended temporary entry.Временное изменение содержит точку, затронутые позиции, причину, согласующего, начало и окончание. До применения проверьте, не расширяет ли оно обещание клиенту за пределы согласованного. По истечении срока ответственный подтверждает возврат к стандарту или оформляет новое решение. Отдельно определите судьбу уже принятых заказов: изменение каталога не должно молча переписывать зафиксированные условия. Постоянная местная особенность оформляется как утверждённое правило, а не бесконечно продлеваемая временная запись.

Specify the action and access scopeЗадайте действие и область доступа

An access matrix answers three questions: who acts, what they do and which records they can affect. Viewing, creating, correcting, approving and exporting each need a separate check. A branch manager may need the local overview without another team’s personal details. Headquarters staff may see the network while retaining limited editing rights. Do not grant a broad role merely to solve one inconvenient operation; first identify the specific missing permission.Матрица прав отвечает на три вопроса: кто действует, что делает и над какими записями. Просмотр, создание, исправление, согласование и выгрузка требуют отдельной проверки. Руководителю точки может быть нужен её обзор, но не персональные сведения другой команды. Сотрудник центра может видеть всю сеть, сохраняя ограниченные права изменения. Не выдавайте широкую роль только ради одной неудобной операции: сначала уточните конкретный недостающий доступ.

Moving an employee between branches requires checking both old and new access scopes. Give temporary cover an expiry and someone responsible for ending it. In a hypothetical example, 3 roles, 2 branch scopes and 2 selected actions produce 3 × 2 × 2 = 12 test combinations. This covers only the selected matrix. Other actions and ways of retrieving data need separate checks; successful sign-ins do not establish that access boundaries hold.Перевод сотрудника в другую точку требует проверки старой и новой области доступа. Для временного замещения назначьте срок и владельца завершения. Учебный пример: 3 роли, 2 области точек и 2 выбранных действия дают 3 × 2 × 2 = 12 комбинаций проверки. Это только выбранная часть матрицы. Дополнительные действия и способы получения данных проверяют отдельно; число успешных входов в систему не говорит, что границы доступа соблюдены.

Test visibility through different pathsПроверьте видимость разными путями

Use agreed test records and accounts assigned the actual working roles. For each role, test both expected permission and expected denial: its own branch, another branch and the shared catalog. Inspecting the initial screen is insufficient. If the selected setup includes search, direct links, reports, attachments or exports, check the same boundaries through each available path. A hidden button alone does not prove that the underlying record is inaccessible.Используйте согласованные тестовые записи и учётные записи с реальными рабочими ролями. Для каждой роли проверьте ожидаемое разрешение и ожидаемый запрет: свою точку, чужую точку и общий справочник. Просмотр только начального экрана недостаточен. Если выбранная конфигурация поддерживает поиск, прямые ссылки, отчёты, вложения или выгрузки, проверьте те же границы через каждый доступный путь. Даже скрытая кнопка не доказывает, что недоступна сама запись.

Also check indirect exposure through result counts, attachment names and drill-down details in shared reports. When someone is permitted only an aggregate measure, access to another branch’s rows must respect that boundary. Record expected and actual outcomes with the role and configuration. Incorrect denial matters too: an employee with the intended authority must complete permitted work without borrowing another account or relying on a permanent administrator.Проверьте также непрямое раскрытие через количество результатов, названия вложений и детализацию общего отчёта. Если сотруднику разрешён только агрегированный показатель, переход к чужим строкам должен соответствовать этому ограничению. Зафиксируйте ожидаемый и фактический результат с ролью и конфигурацией. Ошибка запрета столь же важна для работы: сотрудник со штатными полномочиями должен закончить разрешённое действие, не обращаясь к чужой учётной записи или постоянному администратору.

Accept changes with a history checkПримите изменение с проверкой истории

Before releasing a change, the catalog steward checks affected branches, open orders and historical reports. The branch manager confirms that local settings were preserved or changed as approved. Prepare a configuration rollback while preserving operational history already created. If the change affected accepted commitments, establish the facts and an authorized decision first. Restoring a catalog version does not itself reverse actions already performed.Перед выпуском изменения владелец каталога проверяет затронутые точки, открытые заказы и прежние отчёты. Руководитель филиала подтверждает, что местная настройка сохранилась или изменилась именно по решению. Подготовьте способ возврата настроек, но не удаляйте уже возникшую операционную историю. Если изменение затронуло принятые обязательства, сначала установите факты и ответственное решение. Возврат версии каталога сам по себе не отменяет совершённые действия.

For a SABSUS discussion, bring one shared entry, a local exception and the role matrix. Establish the available field, action and branch boundaries, then test them with the selected scenarios. Acceptance requires stable identity, understandable rule precedence, preserved history and correct visibility. Physical stock and transfers need their own workflow checks; this standard establishes who governs shared data and within which boundaries.На обсуждении SABSUS покажите одну общую позицию, местное исключение и матрицу ролей. Уточните доступные границы по полям, действиям и точкам, а затем проверьте их выбранными сценариями. Приёмка требует устойчивой идентичности, объяснимого приоритета правил, сохранной истории и правильной видимости. Вопросы фактических остатков и перемещений проверяются своим процессом; этот стандарт определяет, кто и в каких пределах управляет общими данными.

Checking roles and permissionsПроверка ролей и полномочий · Branch stock and transfersОстатки и перемещения по точкам

Quick answersКороткие ответы