الخطوة 1: قم بتحميل ملف الـ JRXML من تعريف التقرير ثم فتح محادثة جديدة مع Claude
الخطوة 2: ارفع ملف الـ JRXML اضغط على زر إرفاق الملفات وأرفع ملف .jrxml المطلوب تعديله.
الخطوة 3: انسخ البرومبت بالكامل والصقه
انسخ كل المحتوى من ملف "JRXML_MultiSelect_Prompt.md" (الموجود معك) والصقه في الرسالة، مع كتابة اسم الفلتر أو الفلاتر المطلوب تحويلها في السطر المخصص لها أول البرومبت، مثلاً:
الفلاتر المطلوب تحويلها: المخزن (Warehouse) و الصنف (Item)
ملحوظة: ممكن تطلب فلتر واحد، أو أكتر من فلتر في نفس الطلب، البرومبت يدعم الاتنين.
الخطوة 4: ابعت الرسالة وانتظر الملف الناتج Claude هيرجع لك ملف JRXML معدّل وجاهز للتحميل.
الخطوة 5: تأكد بالعين قبل الاستخدام افتح التقرير في الـ NamaERP وتأكد إن الفلتر ظهر بشكل زرار أخضر "..." بدل الحقلين القدام (من / إلى).
الخطوة 6: لو حصلت أي مشكلة
ارفع صورة الشاشة (Screenshot) للفلتر زي ما ظهر، وقول لـ Claude "لسه نفس المشكلة" أو وصف اللي شايفه، وهو هيراجع الملف ويصلحه.

SoftVision | NamaERP PRO Edition

Claude Standalone Prompt (or any AI assistant):

Convert JRXML Filters "From/To" range style into the "multi-select style"

Copy everything below this line and send it along with your JRXML file.

I have a JRXML report from SoftVision | NamaERP PRO Edition. I need you to convert one or more filters from the old "From/To" range style (two separate single-select fields) into the multi-select style (single field with a green "..." button), following the exact technical pattern below. This pattern is confirmed working and tested in production — follow it precisely, do not improvise alternative approaches.

Filter(s) to convert

[Tell me which filter(s) to convert, e.g.: "Warehouse" / "Item" / "Branch" / "Supplier" / "Employee" / "Sector", etc. You can list more than one.]

The exact pattern to apply

1. Parameter definition

Replace the existing From/To pair (e.g. FWarehouse + TWarehouse, or fromWare + toWare, or any naming variant) with a single parameter:

<parameter name="EntityName_In" class="java.lang.String">
    <property name="entityType" value="EntityType"/>
    <property name="property" value="code"/>
    <property name="arabic" value="Arabic label without من/الي prefix"/>
    <property name="english" value="English label without From/To prefix"/>
    <property name="list" value="true"/>
</parameter>

Critical rules — do not deviate:

• class must be java.lang.String (NOT java.util.Collection — that breaks rendering)
• The trigger property is <property name="list" value="true"/> (NOT multiSelect, NOT anything else)
• property value must be code (NOT id)
• Parameter name convention: EntityName_In (e.g. Warehouse_In, Item_In, Branch_In, Supplier_In)
• Arabic/English labels should drop the "from/to" (من/الي) wording since it's now a single multi-select field

2. Remove dependent parameters

If the old From/To parameters have companion "display" parameters (commonly named X_1 with a <property name="src" value="FWarehouse"/> style reference), delete those too — they no longer apply.

3. SQL WHERE clause — every occurrence

Replace every instance of the BETWEEN filter:

-- OLD (any of these variants):
$X{[BETWEEN],Warehouse.code,FWarehouse,TWarehouse}
$X{[BETWEEN] ,W.code,fromWare,toWare}

-- NEW:
$X{IN,Warehouse.code,Warehouse_In}

Important: Search the entire SQL query, not just the main WHERE clause. namaERP reports often have multiple CTEs/subqueries (opening balance calculations, cost calculations, etc.) that repeat the same filter — every single occurrence must be updated, or the filter will be partially ignored and produce wrong report totals.

Syntax rules:

• Use $X{IN,...} — no square brackets around IN (unlike [BETWEEN])
• Filter by .code column, not .id

4. Page header / title display fields (if present)

If the report's header section displays the selected filter value(s) as text (commonly two textField elements referencing the old From/To parameters), update them:

<!-- OLD -->
<textFieldExpression><![CDATA[$P{FWarehouse_1}]]></textFieldExpression>
<textFieldExpression><![CDATA[$P{TWarehouse_1}]]></textFieldExpression>

<!-- NEW -->
<textFieldExpression><![CDATA[($P{Warehouse_In} != null && !$P{Warehouse_In}.isEmpty()) ? $P{Warehouse_In}.toString().replaceAll("[\\[\\]]","") : ""]]></textFieldExpression>
<textFieldExpression><![CDATA[""]]></textFieldExpression>

5. Final verification

Before returning the file, confirm:

• No leftover references to the old parameter names anywhere in the file (search the whole file, not just parameters and main query)
• The new _In parameter appears in: the parameter declaration, every SQL filter occurrence, and the header display expression (if applicable)
• Parameter count for SQL $X{IN,...,EntityName_In} matches the number of places the old BETWEEN filter appeared

What NOT to do

• Do not use class="java.util.Collection" for the parameter
• Do not use multiSelect="true" as the trigger property — it is not recognized by namaERP
• Do not filter by .id in the SQL — use .code
• Do not use $X{[IN],...} with brackets — correct syntax is $X{IN,...} without brackets
• Do not stop after fixing only the main WHERE clause — check all CTEs/subqueries
• Do not leave orphaned display parameters that reference the deleted From/To parameters via a src property

Deliverable

Return the complete, updated JRXML file with all changes applied, ready to import into NamaERP PRO Edition.