Skip to main content

JSON interno della regola

La form produce due campi JSON principali:

  • match_json;
  • action_json.

match_json​

Descrive le condizioni di match.

Esempio:

{
  "logic": "ALL",
  "conditions": [
    {
      "field": "description",
      "operator": "contains",
      "value": "AFFITTO VIA ROMA"
    }
  ]
}

Condizioni multiple​

Il motore supporta condizioni multiple.

Esempio:

{
  "logic": "ALL",
  "conditions": [
    {
      "field": "counterparty_name",
      "operator": "fuzzy",
      "value": "ROSSI MARIO",
      "threshold": 0.75
    },
    {
      "field": "amount",
      "operator": "amount_equals",
      "value": 740,
      "tolerance": 2
    }
  ]
}

Con logic: ALL devono passare tutte le condizioni.

Con logic: ANY basta una condizione valida.

action_json​

Descrive cosa fare quando la regola fa match.

CLASSIFY​

{
  "description": "Spesa condominiale",
  "property_id": 7,
  "contract_id": 11,
  "category_id": 15,
  "expense_status": "CONFIRMED"
}

Effetto:

  • crea o aggiorna expenses;
  • crea uno split FULL;
  • aggiorna bank_transactions.

RENT_MATCH​

{
  "rent_installment_id": 123,
  "contract_id": 11,
  "property_id": 7,
  "category_id": 1
}

Effetto:

  • crea rent_payment_matches;
  • aggiorna la rata a PAID;
  • crea split;
  • aggiorna il movimento.

EXPECTED_EXPENSE_MATCH​

{
  "expected_expense_id": 45,
  "property_id": 7,
  "category_id": 15,
  "expense_status": "CONFIRMED"
}

Effetto:

  • crea o aggiorna expenses;
  • crea expense_payment_matches;
  • aggiorna expected_expenses a MATCHED;
  • crea split;
  • aggiorna il movimento.

Per spese ricorrenti generate in import, la regola può usare un lookup dinamico invece di un id fisso:

{
  "property_id": 7,
  "category_id": 21,
  "expected_expense_lookup": {
    "kind": "MORTGAGE",
    "property_id": 7,
    "category_id": 21,
    "amount": 850,
    "tolerance": 1,
    "window_days": 7
  }
}

Il motore cerca la spesa attesa EXPECTED o OVERDUE più vicina alla data del movimento.

UTILITY_BILL_SDD​

{
  "target": "UTILITY_BILL_SDD",
  "property_id": 7,
  "contract_id": 11,
  "utility_bill_lookup": {
    "strategy": "SDD_MANDATE_AND_AMOUNT",
    "property_id": 7,
    "contract_id": 11,
    "amount": 120.5,
    "tolerance": 0,
    "statuses": ["RECEIVED", "OVERDUE"]
  },
  "utility_bill_status": "PAID",
  "create_expense": false
}

Effetto previsto:

  • cerca una bolletta aperta collegata al contratto di fornitura usando mandato SDD e importo;
  • crea utility_bill_payment_matches;
  • aggiorna utility_bills a PAID;
  • aggiorna il movimento.

SPLIT​

{
  "splits": [
    {
      "type": "PERCENTAGE",
      "value": 70,
      "property_id": 7,
      "category_id": 15,
      "description": "Quota proprietario"
    },
    {
      "type": "PERCENTAGE",
      "value": 30,
      "property_id": 8,
      "category_id": 15,
      "description": "Quota altra proprietà"
    }
  ]
}

Effetto:

  • crea una riga in bank_transaction_splits per ogni split;
  • può creare una expense per ogni quota;
  • aggiorna il movimento con outcome SPLIT.

Idempotenza​

Il motore deve poter essere rieseguito senza duplicare dati.

Per questo:

  • le regole leggono solo movimenti non ancora riconciliati;
  • le spese create da una transazione possono essere aggiornate invece di duplicate;
  • i match verso rate o spese attese verificano l'esistenza del collegamento prima di crearne uno nuovo.