SABSUS and Odoo: test a workflow changeSABSUS и Odoo: смена правил
The next workflow change can reveal more than the first demonstration. Ask both suppliers to add the same service variant and approval rule, then show what changes for existing orders, staff permissions and connected records. Compare the verified change process rather than a broad feature count.Следующее изменение процесса может раскрыть больше первой демонстрации. Попросите обоих поставщиков добавить одинаковый вариант услуги и правило согласования, затем показать последствия для старых заказов, прав сотрудников и связанных записей. Сравнивайте проверенный процесс изменения, а не число функций.
Can a new service rule go live without changing old commitments?Можно ли ввести новое правило, сохранив старые обязательства?
A service-and-retail business adds a premium repair option with a different parts allowance and manager approval for substitutions. Existing jobs must retain their accepted terms. The buyer needs to see whether staff can select the new option, whether stock use follows the correct version and whether the approval rule applies only where intended. Use this concrete amendment in both demonstrations.Сервисно-торговый бизнес вводит премиальный ремонт с другим набором деталей и согласованием замен руководителем. Старые работы должны сохранить принятые условия. Нужно увидеть выбор нового варианта сотрудником, списание по нужной версии и применение согласования только в заданных случаях. Используйте одинаковое конкретное изменение в обеих демонстрациях.
Odoo offers an integrated application suite with deployment and customization choices; SABSUS describes connected operational modules. Neither description proves how this amendment is implemented. Before anyone edits settings, the process owner writes the old rule, new rule, effective point and exceptions. The administrator explains which records and connections will change, and the manager approves the business result.Odoo предлагает связанные приложения с вариантами размещения и настройки; SABSUS описывает соединённые операционные модули. Ни одно описание не доказывает способ реализации изменения. До правки настроек владелец процесса записывает старое и новое правило, момент действия и исключения. Администратор объясняет затронутые записи и связи, руководитель утверждает результат.
Official documentation: Официальные материалы: Odoo
When each option makes senseКогда подходит каждый вариант
Configuration changeИзменение настройки
Ask whether service variants, allowed fields and approval boundaries are configurable in the quoted setup. In Odoo name the edition, version and relevant apps; in SABSUS name the demonstrated configuration. Have the intended administrator reproduce the change and retain the prior rule for comparison.Уточните, настраиваются ли варианты услуг, поля и согласования в предложенном комплекте. Для Odoo назовите редакцию, версию и приложения; для SABSUS — показанную конфигурацию. Пусть будущий администратор повторит изменение и сохранит прежнее правило для сравнения.
Official documentation: Официальные материалы: Odoo
Extension or custom logicРасширение или собственная логика
If the amendment needs an extension or code, identify its owner and supported version. Ask what the change affects beyond the visible form, including imports and external updates. Do not assume a feature in a demonstration is standard or maintained under the ordinary subscription.Если нужны расширение или код, укажите владельца и поддерживаемую версию. Выясните последствия вне видимой формы, включая импорт и внешний обмен. Не предполагайте, что показанная функция стандартная и сопровождается обычной подпиской.
External or manual boundaryВнешняя или ручная граница
A specialist system or manager review may remain appropriate. Define the trigger, reference and acknowledgment, and measure the remaining work. A manual approval is acceptable when deliberate and observable; it should not be hidden inside a claim that the new service is fully automated.Специализированная система или проверка руководителя могут остаться уместными. Определите условие, ссылку, принятие и объём работы. Ручное согласование допустимо, если намеренно и наблюдаемо; его нельзя скрывать за обещанием полной автоматизации услуги.
How to make the decisionКак принять решение
Price this amendment separately from the initial implementation: configuration work, development, staff review, regression and future maintenance. Compare a second likely change, such as a new material allowance, to expose whether every adjustment requires a supplier project. The preferred proposal may use standard rules or an intentional extension; the criterion is a repeatable change process with accepted cost and responsibility.Оцените изменение отдельно от первоначального внедрения: настройку, разработку, проверку команды, повторные тесты и будущее сопровождение. Сравните вторую вероятную правку, например норму материала, чтобы понять, требует ли каждая коррекция нового проекта поставщика. Подходят и стандартные правила, и осознанное расширение; критерий — повторяемое изменение с принятыми расходами и ответственностью.
Keep a small regression set owned by the business, not only a supplier’s demonstration script. It should include the original service, the new variant and the most consequential exception. When a later update is proposed, the owner can judge the change using the same evidence. This makes maintenance acceptance concrete even when the implementation method differs between products.Сохраните небольшой набор повторных проверок под ответственностью бизнеса, а не только сценарий демонстрации поставщика. Включите исходную услугу, новый вариант и самое существенное исключение. При очередном обновлении владелец оценит изменение по тем же доказательствам. Это делает приёмку сопровождения предметной при разной реализации продуктов. Отдельно укажите, кто обновляет сами проверки, если бизнес осознанно меняет правило, чтобы устаревший сценарий не стал ложным критерием ошибки.
The exception that tests the choiceИсключение для проверки выбора
Now open a job accepted before the new rule, substitute a part, and then repeat the scenario after a system update. The old customer terms must remain understandable while current authorization rules are applied as agreed. If a new field is absent from an external import, route it for review rather than silently inventing a value. The release owner decides whether a failed case blocks rollout.Откройте работу, принятую до нового правила, замените деталь и повторите сценарий после обновления системы. Старые условия клиента должны оставаться понятными, а текущие полномочия — применяться по договорённости. При отсутствии нового поля во внешнем импорте нужна проверка, а не выдуманное значение. Ответственный за выпуск решает, блокирует ли отказ запуск.
Evidence to accept the workflowДоказательства для приёмки
- Demonstrate a new service, an existing job, an unauthorized substitution and a missing-field import using the intended staff roles.Покажите новую услугу, старую работу, запрещённую замену и импорт без поля с предусмотренными рабочими ролями.
- Reconcile materials, price, approval evidence and connected records; preserve the prior accepted version and the reason for the change.Сверьте материалы, цену, согласование и связанные записи; сохраните прежнюю принятую версию и причину изменения.
- Repeat the same cases after an update and document rollback conditions, extension ownership and the accepted support boundary.Повторите случаи после обновления и запишите условия отката, владельца расширения и принятую границу поддержки.
A practical next stepПрактический следующий шаг
Bring the old and proposed service rules to a SABSUS demonstration and request the same change evidence from the Odoo implementer. Accept the amendment only when staff can operate both existing and new jobs correctly. This detailed test complements a broader supplier-selection review; it does not establish universal superiority for either product.Принесите старое и новое правило на демонстрацию SABSUS и запросите такие же доказательства у исполнителя Odoo. Принимайте изменение, когда сотрудники правильно ведут старые и новые работы. Подробная проверка дополняет общий выбор поставщика и не доказывает универсальное превосходство продукта.
Quick answersКороткие ответы
Does a configurable field prove the change is complete?Настраиваемое поле доказывает готовность изменения?
No. Check permissions, existing records, imports, calculations and downstream actions affected by the new rule.Нет. Проверьте права, старые записи, импорт, расчёты и дальнейшие действия, затронутые правилом.
Must every change avoid custom code?Любое изменение должно обходиться без кода?
Not necessarily. An extension can be justified when its cost, maintainer, tests and upgrade responsibility are explicit.Не обязательно. Расширение оправдано при явных расходах, сопровождении, тестах и ответственности за обновления.
Sources and scopeИсточники и границы
Official materials checked on 6 October 2026. Examples establish advertised or documented scope, not a complete market ranking or a test of your account. Confirm the current plan, region, providers and configuration; acceptance cases above are proposed checks, not claimed product results. Confirm Odoo’s exact edition, deployment and commercial terms in the current proposal.Официальные материалы проверены 6 октября 2026 года. Примеры подтверждают заявленный или документированный объём, а не полный рейтинг рынка или проверку вашего аккаунта. Уточните текущий тариф, регион, провайдеров и конфигурацию; сценарии выше — предлагаемые проверки, а не заявленные результаты продукта. Точную редакцию, размещение и коммерческие условия Odoo подтвердите в актуальном предложении.