[{"data":1,"prerenderedAt":86},["ShallowReactive",2],{"legacy:engine\u002Forg:en":3},{"id":4,"title":5,"description":6,"keywords":7,"author":8,"robots":9,"bodyClass":10,"image":11,"jsonld":12,"html":85},"engine\u002Forg","Organization Engine - People-centric Org Master Data - JEDP Digital Platform","JEDP Organization Engine: consolidates organizational master data from the department tree, position assignments and reporting lines, providing organizational context for permission data scopes and process approver resolution, with multi-tenant isolation and group multi-plant scenarios.","JEDP, organization engine, six engines, digital platform, Lang Bowan","Shenzhen Langbowan Information Technology Co., Ltd.","index, follow","page-engines","https:\u002F\u002Fwww.jedp.cn\u002Fres\u002Fimages\u002Fproduct\u002Fplatform-overview.webp",[13,30,59],{"@context":14,"@type":15,"itemListElement":16},"https:\u002F\u002Fschema.org","BreadcrumbList",[17,22,26],{"@type":18,"position":19,"name":20,"item":21},"ListItem",1,"Home","https:\u002F\u002Fwww.jedp.cn\u002F",{"@type":18,"position":23,"name":24,"item":25},2,"Platform","https:\u002F\u002Fwww.jedp.cn\u002Fengines",{"@type":18,"position":27,"name":28,"item":29},3,"Organization Engine","https:\u002F\u002Fwww.jedp.cn\u002Fengine\u002Forg",{"@context":14,"@type":31,"@id":32,"name":33,"applicationCategory":34,"applicationSubCategory":35,"operatingSystem":36,"inLanguage":37,"description":6,"url":29,"provider":41,"isPartOf":43,"offers":45,"featureList":52},"SoftwareApplication","https:\u002F\u002Fwww.jedp.cn\u002Fengine\u002Forg#software","JEDP Organization Engine","BusinessApplication","Enterprise Digital Platform Engine","Web (browser access; SaaS multi-tenant, private deployment assessed by scenario)",[38,39,40],"zh-CN","zh-TW","en",{"@id":42},"https:\u002F\u002Fwww.jedp.cn\u002F#organization",{"@id":44},"https:\u002F\u002Fwww.jedp.cn\u002F#software",{"@type":46,"url":47,"availability":48,"priceSpecification":49},"Offer","https:\u002F\u002Fwww.jedp.cn\u002Fcontact?from=engine-org","https:\u002F\u002Fschema.org\u002FInStock",{"@type":50,"priceCurrency":51},"PriceSpecification","CNY",[53,54,55,56,57,58],"Department tree and org views: Tree-structured maintenance of departments, responsible persons, and levels, supporting architecture views and batch import\u002Fexport. When multiple business units\u002Fmultiple factories operate in parallel, organizational standards become the common dimension for permissions, processes, and reports, rather than each system drawing a separate diagram.","Staff assignments: Users can be associated with multiple departments, positions, and job types, distinguishing between primary departments and part-time roles; changes in appointments come with an effective date. During onboarding, transfers, or departures, permission packages and approvers switch at clearly defined times, avoiding the situation where 'the person has moved to a new department, but the system still refers to the old manager'.","Reporting lines: Maintain superiors and department heads to ensure stable parsing of rules such as 'superior' and 'department head' in the process. Deputies and authorizations should have a set duration to prevent long-term distortion of reporting relationships, which could result in approvals falling to the wrong responsible person.","Post and job-type catalog: Job codes and job types are managed uniformly, supporting personnel selection components, staffing statistics, and job-level permission package configuration, reducing authorization confusion caused by 'same name, different positions'.","Internal and external identities: Internal employees and external organizations\u002Fcontacts are managed in separate volumes, with data scope and login capabilities separated. Scenarios such as supplier portals and customer collaboration can reuse the identity model without polluting the internal address book.","Multi-tenant isolation: Organize data by tenant isolation, and the organizational framework can be initialized after account opening. When multiple organizations of a group run in parallel with SaaS, the organizational boundary is the security boundary, and cross-tenant personnel sharing is prohibited.",{"@context":14,"@type":60,"@id":61,"mainEntity":62},"FAQPage","https:\u002F\u002Fwww.jedp.cn\u002Fengine\u002Forg#faq",[63,69,73,77,81],{"@type":64,"name":65,"acceptedAnswer":66},"Question","Why does approval still go to the old manager after a transfer?",{"@type":67,"text":68},"Answer","Usually the assignment has no effective date, or the flow hard-codes a person. The org engine should switch assignment, permission pack, and handler resolution on the same day. Spot-check one to-do before and after the transfer.",{"@type":64,"name":70,"acceptedAnswer":71},"Can a concurrent post see rows it should not?",{"@type":67,"text":72},"Yes, if the concurrent post has no data scope or no end date. Concurrent posts, secondments, and proxies must be modeled with a term and reclaimed at expiry, or permission debt accumulates.",{"@type":64,"name":74,"acceptedAnswer":75},"Can the org engine replace EHR payroll and time clocks?",{"@type":67,"text":76},"No. It supplies department, assignment, and reporting-line master data for permission and flow. Pay formulas and clock protocols stay with EHR or shop-floor devices.",{"@type":64,"name":78,"acceptedAnswer":79},"Will supplier contacts enter the internal directory?",{"@type":67,"text":80},"They should not. Internal staff and external contacts are kept in separate books. External identities must not appear in internal payroll, cost, or unauthorized project people-pickers.",{"@type":64,"name":82,"acceptedAnswer":83},"How should a multi-plant organization hang together?",{"@type":67,"text":84},"Use one org tree for plants and shops. Job codes are shared; assignments hang on the plant. WMS warehouses, MES shops, and EHR pay orgs should map to this tree—not three parallel code systems.","\u003Csection class=\"product-detail-section page-section\">\n    \u003Cdiv class=\"detail-container\">\n      \u003Cnav class=\"breadcrumb\" aria-label=\"Breadcrumb\">\n        \u003Ca href=\"\u002F\">Home\u003C\u002Fa>\n        \u003Cspan class=\"breadcrumb-sep\">\u002F\u003C\u002Fspan>\n        \u003Ca href=\"\u002Fengines\">Platform\u003C\u002Fa>\n        \u003Cspan class=\"breadcrumb-sep\">\u002F\u003C\u002Fspan>\n        \u003Cspan>Organization Engine\u003C\u002Fspan>\n      \u003C\u002Fnav>\n      \u003Cdiv class=\"product-detail\">\n        \u003Cdiv class=\"detail-header\">\n          \u003Cdiv class=\"detail-icon\">\u003Ci class=\"fas fa-sitemap\">\u003C\u002Fi>\u003C\u002Fdiv>\n          \u003Cdiv>\n            \u003Ch1>Organization Engine\u003C\u002Fh1>\n            \u003Cp class=\"detail-subtitle\">Centering on people to consolidate organizational master data: department hierarchy, position assignments, and reporting relationships — the only trusted source for permission trimming and process personnel selection.\u003C\u002Fp>\n          \u003C\u002Fdiv>\n        \u003C\u002Fdiv>\n        \u003Cdiv class=\"detail-content\">\n\n          \u003Cdiv class=\"detail-section\">\n            \u003Ch2>Engine Positioning\u003C\u002Fh2>\n            \u003Cp class=\"detail-lead\">The organizational engine is the foundation of people and organizations on the platform. First, clarify departments, personnel, positions, and reporting relationships, so that permissions can be trimmed according to 'this department \u002F this department and sub-departments,' workflows can determine handlers based on superiors or department heads, and the form's user selection components can consume unified master data. What it solves is not 'drawing an organizational chart,' but ensuring that when employees join, transfer, change positions, have acting roles, or operate in multiple organizations simultaneously, business systems no longer maintain separate conflicting contact lists.\u003C\u002Fp>\n            \u003Cp class=\"detail-lead\">In scenarios where multiple business units of a group, SaaS multi-tenancy, and internal and external collaboration coexist, organizational data is isolated by tenant, and internal employees and external contacts are managed in separate directories. The organizational personnel in EHR, the multi-subsidiary procurement control in SRM, and the person's selection rules in various business approvals should all reuse the same set of positions and reporting relationships, and switch permissions and approvers based on the effective date to avoid situations where 'the person has moved to a new department, but the system still finds the old manager.'\u003C\u002Fp>\n          \u003C\u002Fdiv>\n          \u003Cdiv class=\"detail-section\">\n            \u003Ch2>Where It Fits\u003C\u002Fh2>\n            \u003Cul class=\"pain-list\">\n              \u003Cli>The group has multiple business divisions and subsidiaries operating in parallel, the department hierarchy and job definitions are not unified, and the report dimensions do not align.\u003C\u002Fli>\n              \u003Cli>One person holds multiple positions in different departments, with the coexistence of primary posts and part-time roles. Each business system maintains its own organization, and after a transfer, permissions and approvals drift for a long time.\u003C\u002Fli>\n              \u003Cli>Approvals must circulate according to superiors or department heads, but organizational relationships are scattered in IM and spreadsheets, and proxies have no time limit.\u003C\u002Fli>\n              \u003Cli>Internal and external collaboration (suppliers, customer contacts) needs to distinguish identity and data scope from internal employees\u003C\u002Fli>\n              \u003Cli>In SaaS\u002Fmulti-tenant deployments, organizational data must be isolated by tenant and can be initialized upon account creation\u003C\u002Fli>\n            \u003C\u002Ful>\n          \u003C\u002Fdiv>\n          \u003Cdiv class=\"detail-section\">\n            \u003Ch2>Capability Highlights\u003C\u002Fh2>\n            \u003Cul class=\"capability-list\">\n              \u003Cli>\u003Cstrong>Department tree and org views\u003C\u002Fstrong>\u003Cspan>Tree-structured maintenance of departments, responsible persons, and levels, supporting architecture views and batch import\u002Fexport. When multiple business units\u002Fmultiple factories operate in parallel, organizational standards become the common dimension for permissions, processes, and reports, rather than each system drawing a separate diagram.\u003C\u002Fspan>\u003C\u002Fli>\n              \u003Cli>\u003Cstrong>Staff assignments\u003C\u002Fstrong>\u003Cspan>Users can be associated with multiple departments, positions, and job types, distinguishing between primary departments and part-time roles; changes in appointments come with an effective date. During onboarding, transfers, or departures, permission packages and approvers switch at clearly defined times, avoiding the situation where 'the person has moved to a new department, but the system still refers to the old manager'.\u003C\u002Fspan>\u003C\u002Fli>\n              \u003Cli>\u003Cstrong>Reporting lines\u003C\u002Fstrong>\u003Cspan>Maintain superiors and department heads to ensure stable parsing of rules such as 'superior' and 'department head' in the process. Deputies and authorizations should have a set duration to prevent long-term distortion of reporting relationships, which could result in approvals falling to the wrong responsible person.\u003C\u002Fspan>\u003C\u002Fli>\n              \u003Cli>\u003Cstrong>Post and job-type catalog\u003C\u002Fstrong>\u003Cspan>Job codes and job types are managed uniformly, supporting personnel selection components, staffing statistics, and job-level permission package configuration, reducing authorization confusion caused by 'same name, different positions'.\u003C\u002Fspan>\u003C\u002Fli>\n              \u003Cli>\u003Cstrong>Internal and external identities\u003C\u002Fstrong>\u003Cspan>Internal employees and external organizations\u002Fcontacts are managed in separate volumes, with data scope and login capabilities separated. Scenarios such as supplier portals and customer collaboration can reuse the identity model without polluting the internal address book.\u003C\u002Fspan>\u003C\u002Fli>\n              \u003Cli>\u003Cstrong>Multi-tenant isolation\u003C\u002Fstrong>\u003Cspan>Organize data by tenant isolation, and the organizational framework can be initialized after account opening. When multiple organizations of a group run in parallel with SaaS, the organizational boundary is the security boundary, and cross-tenant personnel sharing is prohibited.\u003C\u002Fspan>\u003C\u002Fli>\n            \u003C\u002Ful>\n          \u003C\u002Fdiv>\n          \u003Cdiv class=\"detail-section\">\n            \u003Ch2>Works With Other Engines\u003C\u002Fh2>\n            \u003Cdiv class=\"platform-boost\">\n              \u003Carticle>\u003Ch3>Permission Engine\u003C\u002Fh3>\u003Cp>The data scope is trimmed according to the organizational boundaries of this department\u002Fthis department and its subordinates; after the effective date of the appointment, the visible rows converge with the permission package. Concurrent positions, secondments, and acting roles must have a term, otherwise permission debt will inevitably accumulate.\u003C\u002Fp>\u003C\u002Farticle>\n              \u003Carticle>\u003Ch3>Workflow Engine\u003C\u002Fh3>\u003Cp>Approvers are resolved according to supervisors, department heads, departments, and roles; after organizational adjustments, the handler rules can still be used, without needing to change each person's settings for every process, reducing maintenance costs.\u003C\u002Fp>\u003C\u002Farticle>\n              \u003Carticle>\u003Ch3>Form Engine\u003C\u002Fh3>\u003Cp>The personnel\u002Fdepartment\u002Fposition\u002Frole selection component only consumes the organization's master data, avoiding conflicts between independently built address books in various business units, and ensuring that the selection results are consistent with the appointments.\u003C\u002Fp>\u003C\u002Farticle>\n              \u003Carticle>\u003Ch3>Report Engine\u003C\u002Fh3>\u003Cp>The operations and human resources dashboard can be filtered by department\u002Forganization dimension, with the scope consistent with the organizational tree, supporting multi-factory comparisons without dimension mixing and with interpretable aggregation.\u003C\u002Fp>\u003C\u002Farticle>\n            \u003C\u002Fdiv>\n          \u003C\u002Fdiv>\n          \u003C!-- engine-depth:BEGIN -->\n\n          \u003Cdiv class=\"detail-section\">\n            \n            \u003Ch2>Typical breakpoints\u003C\u002Fh2>\n\u003Cdiv class=\"table-scroll\">\u003Ctable>\u003Cthead>\u003Ctr>\u003Cth>Breakpoint\u003C\u002Fth>\u003Cth>Common cause\u003C\u002Fth>\u003Cth>Control lever\u003C\u002Fth>\u003C\u002Ftr>\u003C\u002Fthead>\u003Ctbody>\u003Ctr>\u003Ctd>After the job transfer, approval still goes to the old manager\u003C\u002Ftd>\u003Ctd>The effective date of the position is not bound, or the process is hard-coded to an individual\u003C\u002Ftd>\u003Ctd>Effective date of appointment + Handler analyzes according to the rules\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd>Holding multiple positions leads to seeing things one shouldn't see\u003C\u002Ftd>\u003Ctd>No data range or indefinite period for concurrent post\u003C\u002Ftd>\u003Ctd>Explicitly model concurrent positions and set an end date\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd>The dimensions of the reporting department do not align\u003C\u002Ftd>\u003Ctd>Department codes built by each system\u003C\u002Ftd>\u003Ctd>Unified Department Tree and Import-Export Governance\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd>Supplier contacts added to internal address book\u003C\u002Ftd>\u003Ctd>Internal and external identities not separated\u003C\u002Ftd>\u003Ctd>External Organization\u002FContact Master Data\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd>Personnel transferring between subsidiary company databases\u003C\u002Ftd>\u003Ctd>Tenant isolation or organizational boundary misconfiguration\u003C\u002Ftd>\u003Ctd>Account Opening Initialization Skeleton + Random Inspection Isolation\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd>After opening the account, there is only the department with no one.\u003C\u002Ftd>\u003Ctd>Disconnection between framework and personnel introduction\u003C\u002Ftd>\u003Ctd>Phased Implementation + Random Inspection List for Positions\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd>Agent still appears in to-do after expiration\u003C\u002Ftd>\u003Ctd>Agent not bound end date or not retrieved\u003C\u002Ftd>\u003Ctd>Agent Ledger + Process Analysis Regression\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003C\u002Fdiv>\n            \u003Ch2>Promotion and Acceptance\u003C\u002Fh2>\n            \u003Cul class=\"accept-list\">\n              \u003Cli>First freeze the department codes and hierarchy rules, then batch import personnel; prohibit \"changing codes while going live\" to prevent historical document dimension drift\u003C\u002Fli>\n              \u003Cli>Integration of transfer and job change processes with organizational appointment: randomly check the permission packages, pending handlers, and form selection results before and after the effective date\u003C\u002Fli>\n              \u003Cli>Agents and secondments must be retrievable with a demonstrable end date; check whether expired agents still appear in the process parsing results\u003C\u002Fli>\n              \u003Cli>When sharing the organization with multiple products such as EHR and SRM, agree on a single maintenance entry and synchronization direction to avoid mutual overwriting of master data.\u003C\u002Fli>\n              \u003Cli>Randomly check whether the department dimension fields of the same personnel in the already launched modules such as QMS\u002FSRM\u002FWMS come from the same organizational tree\u003C\u002Fli>\n              \u003Cli>Multi-tenant account opening demonstration: Retrieval of personnel and departments across tenants should be isolated, and audits should be able to illustrate tenant boundary configuration.\u003C\u002Fli>\n              \u003Cli>External contacts must not appear in the selection results for internal salaries, costs, or unauthorized projects\u003C\u002Fli>\n            \u003C\u002Ful>\n            \n            \u003Ch2>Implement in stages\u003C\u002Fh2>\n            \u003Cul class=\"accept-list\">\n              \u003Cli>\u003Cstrong>Phase 1 (Framework)\u003C\u002Fstrong>: Tenant boundaries, department tree codes, job directory, internal and external volume strategies; complete import templates and sampling test cases\u003C\u002Fli>\n              \u003Cli>\u003Cstrong>Second term (in office)\u003C\u002Fstrong>: Personnel appointment, primary and concurrent positions, reporting relationships, onboarding, transfers, and departure linkage; coordination with permission packages and process analysis\u003C\u002Fli>\n              \u003Cli>\u003Cstrong>Phase Three (Collaboration)\u003C\u002Fstrong>: Align with external identities in EHR\u002FSRM\u002FCRM; include secondments and project-based organizations (if any) in the ledger\u003C\u002Fli>\n            \u003C\u002Ful>\n            \n            \u003Ch2>Create a landing prompt\u003C\u002Fh2>\n            \u003Cp class=\"detail-lead\">When multiple factories operate in parallel, a common practice is to use the organizational tree to distinguish factories and workshops, with the job directory having unified codes but positions being assigned according to the factory; WMS warehouse organization, MES workshop organization, and EHR payroll organization should be mapped to nodes of the same tree, rather than having three parallel sets of codes. For project-based manufacturing, if project teams are enabled, it is recommended to authorize project teams with a time limit and attach them to main positions to avoid 'still seeing project costs long after the project ends.' After going live, organizational changes should go through work orders or HR processes to leave a record, and directly changing codes in the backend without notifying downstream reconciliation is prohibited.\u003C\u002Fp>\n            \u003Ch2>When not to apply\u003C\u002Fh2>\n            \u003Cul class=\"pain-list\">\n              \u003Cli>It is hoped that the organizational engine will replace professional HR salary formulas or attendance device agreements—it provides master data for positions, but does not replace the attendance machine or the salary calculation rules themselves.\u003C\u002Fli>\n              \u003Cli>No effective date for discipline, organizational adjustments rely entirely on post-event permission changes — rules for the appointment ledger should be established before discussing automation\u003C\u002Fli>\n              \u003Cli>The requirement for cross-tenant shared personnel allocation—contradicts the SaaS multi-tenant isolation design and should be addressed through group-type deployment and organizational boundary modeling.\u003C\u002Fli>\n              \u003Cli>Treat the organizational chart as for display only, not allowing downstream consumption—if permissions and processes still maintain the address book separately, the underlying platform's value cannot be realized\u003C\u002Fli>\n            \u003C\u002Ful>\n          \u003C\u002Fdiv>\n          \u003C!-- engine-depth:END -->\n\n\u003Cdiv class=\"detail-section\">\n            \u003Ch2>Product Fit\u003C\u002Fh2>\n            \u003Cul class=\"related-cases\">\n              \u003Cli>EHR: Transfer, promotion, and resignation records and position ledger use organizational master data as the sole source\u003C\u002Fli>\n              \u003Cli>Case: Recruitment to Compensation and Human Resources Integration (Organization Position Driven)\u003C\u002Fli>\n              \u003Cli>SRM: Isolation of procurement organizations and personnel selection approval across multiple subsidiaries of the group\u003C\u002Fli>\n              \u003Cli>PMS: Project Organization and Resource View Reuse Department \u002F Position\u003C\u002Fli>\n              \u003Cli>Dual agents: Configuration acceleration is still subject to organizational scope constraints\u003C\u002Fli>\n              \u003Cli>Insight: Organizational Permission Inheritance and Effective Date of Transfer\u003C\u002Fli>\n            \u003C\u002Ful>\n          \u003C\u002Fdiv>\n          \u003Cdiv class=\"product-detail-cta scroll-reveal\">\n            \u003Ca href=\"\u002Fengines#engines\" class=\"btn btn-outline\">Back to Platform\u003C\u002Fa>\n            \u003Ca href=\"\u002Fcontact?from=engine-org\" class=\"btn\">Book a Meeting\u003C\u002Fa>\n          \u003C\u002Fdiv>\n        \u003C\u002Fdiv>\n      \u003C\u002Fdiv>\n    \u003C\u002Fdiv>\n  \u003C\u002Fsection>\n\n  \u003C!-- GEO:faq-visible:BEGIN · 由 scripts\u002Finject_geo.py 生成，请勿手改 -->\n  \u003Csection class=\"contact-faq page-section\" id=\"faq\">\n    \u003Ch2 class=\"section-title\">FAQ\u003C\u002Fh2>\n    \u003Cp class=\"section-subtitle\">Common questions on org master data and effective-date transfers; contact us if you still need help\u003C\u002Fp>\n    \u003Cdiv class=\"faq-list\">\n        \u003Cdetails class=\"faq-item\" open>\n          \u003Csummary>Why does approval still go to the old manager after a transfer?\u003C\u002Fsummary>\n          \u003Cp>Usually the assignment has no effective date, or the flow hard-codes a person. The org engine should switch assignment, permission pack, and handler resolution on the same day. Spot-check one to-do before and after the transfer.\u003C\u002Fp>\n        \u003C\u002Fdetails>\n        \u003Cdetails class=\"faq-item\">\n          \u003Csummary>Can a concurrent post see rows it should not?\u003C\u002Fsummary>\n          \u003Cp>Yes, if the concurrent post has no data scope or no end date. Concurrent posts, secondments, and proxies must be modeled with a term and reclaimed at expiry, or permission debt accumulates.\u003C\u002Fp>\n        \u003C\u002Fdetails>\n        \u003Cdetails class=\"faq-item\">\n          \u003Csummary>Can the org engine replace EHR payroll and time clocks?\u003C\u002Fsummary>\n          \u003Cp>No. It supplies department, assignment, and reporting-line master data for permission and flow. Pay formulas and clock protocols stay with EHR or shop-floor devices.\u003C\u002Fp>\n        \u003C\u002Fdetails>\n        \u003Cdetails class=\"faq-item\">\n          \u003Csummary>Will supplier contacts enter the internal directory?\u003C\u002Fsummary>\n          \u003Cp>They should not. Internal staff and external contacts are kept in separate books. External identities must not appear in internal payroll, cost, or unauthorized project people-pickers.\u003C\u002Fp>\n        \u003C\u002Fdetails>\n        \u003Cdetails class=\"faq-item\">\n          \u003Csummary>How should a multi-plant organization hang together?\u003C\u002Fsummary>\n          \u003Cp>Use one org tree for plants and shops. Job codes are shared; assignments hang on the plant. WMS warehouses, MES shops, and EHR pay orgs should map to this tree—not three parallel code systems.\u003C\u002Fp>\n        \u003C\u002Fdetails>\n    \u003C\u002Fdiv>\n  \u003C\u002Fsection>\n  \u003C!-- GEO:faq-visible:END -->\n\n  \n  \n  \n  \n  \n  \u003C!-- GEO:software-app:BEGIN · 由 scripts\u002Finject_geo.py 生成，请勿手改 -->\n  \n  \u003C!-- GEO:software-app:END -->\n\n  \u003C!-- GEO:faq:BEGIN · 由 scripts\u002Finject_geo.py 生成，请勿手改 -->\n  \n  \u003C!-- GEO:faq:END -->",1793937990262]