La Pyme

View saved version →

---
name: lapyme-business-reporting
description: Answer La Pyme business and accounting questions when choosing a report source, period, dimensions, measures, filters, or the correct reporting tool matters. Do not use for a simple lookup of one known record.
---

# La Pyme Business Reporting

Choose the smallest reporting path that answers the user's question, state material assumptions, and preserve La Pyme's money and date semantics.

## Route The Question

- Use a `list_*` tool for filtered records and a `get_*` tool for one known record.
- Use `run_report` for totals, grouped analysis, rankings, trends, comparisons, and operational analytics across sales, purchases, payments, commissions, treasury, or inventory.
- Use `get_accounting_report` for income statements, trial balances, journal entries, summarized journals, account ledgers, and receivables/payables aging (`accounts_receivable` for "quién me debe", `accounts_payable` for "a quién le debo"). Do not use `run_report` for accounting statements.
- Use `get_accounting_report` for account ledgers and summarized journals, and the named cost-center tools for references.

Read `reporting://catalog` when the correct source, measure, dimension, filter, or measure semantics are not already clear. Read `context://reporting-rules` for period and interpretation rules.

## Shape Operational Reports

- `run_report` needs a source. Select measures that answer the question and add dimensions only for the requested breakdown; omit dimensions for a total.
- Use dimension `filters` for entities and attributes. Use `resultFilters` for computed measures. Do not put measures in dimension filters.
- Use natural entity references when supported. For product-name text searches, use the catalog's product-name filter instead of treating a partial name as an exact product identifier.
- Use a compact page size and follow `nextCursor` until the requested result set is complete. Do not treat the first page as the full result.
- For custom product or contact fields, read the catalog and use the canonical metafield dimension or an unambiguous visible name.
- For "clientes que dejaron de comprar" or "clientes inactivos", run a `sales` report over the last 12 months grouped by `customer`, filtered with `customerRecency` in `61-90`, `91-180`, and `181+`, and ranked by `total`. `customerRecency` is how long ago the customer's last purchase was, counted from today; it also works as a dimension for the whole distribution.
- For "nuevos vs recurrentes", group `sales` by `customerType`. It classifies each sale by whether it was the customer's first purchase, using their whole history. Sales to the default Consumidor Final are `unidentified` in both dimensions; say so when they are a large share.

## Apply Date And Money Semantics

- Interpret periods in Argentina local time (`UTC-3`) and use `YYYY-MM-DD` dates.
- Money measures use cents unless the field explicitly says otherwise. Computed metrics can contain fractional cents.
- For sales, the default commercial date basis attributes linked credit notes to the original sale date. Use the fiscal date basis for AFIP books, fiscal exports, or voucher-issue-date totals.
- Read the catalog before interpreting percentages, balances, rates, or inventory snapshot measures.
- Do not combine a period preset with explicit start and end dates.

## Handle Accounting Reports

- Start with `income_statement` for revenue, expense, gross-margin, EBITDA, or net-result questions. Use `account_ledger` when the user asks for the movements behind one account.
- `account_ledger` needs one account reference: id, code, or name. Use the returned options when a visible name is ambiguous.
- Pagination applies to journal entries, summarized journal, and account-ledger rows, not to statement totals.
- State when the tool's default accounting period was used because defaults differ by report type.

If a report is empty, inspect the period, date basis, filters, resolved references, and pagination before concluding that the business value is zero. Present the answer in the user's requested currency and language while keeping the underlying units explicit.

Referenced files: 1 — file references are metadata, not package contents.

View saved version →

---
name: lapyme-inventory-planning
description: Analyze La Pyme stock pressure and decide whether to buy, transfer, wait, or investigate, then create a transfer or purchase order when the user requests execution. Do not use for a simple lookup of one known stock record.
---

# La Pyme Inventory Planning

Treat replenishment and purchase planning as one decision: identify stock pressure, understand demand under availability, and choose whether to buy, transfer, wait, or investigate.

Read `context://inventory-rules`, `context://reporting-rules`, and `reporting://catalog` when the request needs analytical stock or demand evidence.

## Build The Evidence

- Use `run_report` as the primary tool for broad stock planning, sales velocity, coverage, supplier grouping, and product-by-warehouse comparison.
- Use `list_inventory` for a narrowed current operational lookup or to confirm a specific execution target. Do not request an unbounded product-by-warehouse matrix.
- Use `list_purchases` only to enrich a shortlist with recent supplier, cost, voucher, or balance context. Purchase history is not the primary demand signal.
- If the user did not supply a horizon, choose a sensible recent evidence period, commonly 90 days, and state the assumption.

Rank candidates by stock pressure and credible demand, not raw rotation alone. Consider available, reserved, and incoming stock. Pair sales velocity with days in stock and days out of stock because unavailable products can show artificially low sales.

Compare warehouses before recommending a purchase. If the organization has enough available stock in another location, recommend a transfer. Recommend buying only when organization-level available plus incoming stock cannot cover the horizon and the demand signal is credible. Recommend waiting when stock or incoming supply covers the horizon. Recommend investigation when supplier, cost, movement, or availability evidence is contradictory or incomplete.

## Execute Only The Chosen Action

- Use `save_transfer` after the user requests the transfer and the source, destination, products, and quantities are resolved.
- Confirm source availability before calling `save_transfer`; the tool can create a transfer from an already negative source balance.
- Use `save_purchase_order` after the user requests the purchase order and the supplier, destination warehouse, products, quantities, and expected costs are resolved.
- An exact execution request is sufficient authorization. Do not turn analysis or a recommendation into a write.
- Product report rows can represent a product with multiple variants. If a write returns variant candidates, select the user's intended variant or ask them; do not guess.

Return a compact ranked recommendation with the product, proposed action, current stock picture, demand signal, urgency, and missing evidence. After a write, report the created transfer or purchase order and any unresolved or skipped items.

Referenced files: 1 — file references are metadata, not package contents.

View saved version →

---
name: lapyme-sales-invoicing
description: Create, invoice, return, or credit sales in La Pyme when Argentine voucher rules, customer and point-of-sale resolution, tax treatment, totals, or fiscal issuance matter. Do not use for general sales analytics.
---

# La Pyme Sales And Invoicing

Use La Pyme's sales tools to complete the user's requested commercial or fiscal outcome without guessing identifiers or repeating a write.

## Choose The Operation

- Use `list_sales` to find a sale and `get_sale` to inspect one sale and return its in-product document review route.
- Use `save_sale` without `id` to create a sale. With `id`, it only updates supported metadata and tags; it does not replace items, totals, or payments.
- Use `invoice_sale` only when the user has explicitly requested fiscal issuance for an existing sale.
- Use `create_sale_return` for a return linked to an existing sale. Read the sale with `get_sale` first because each returned line needs its `saleItemId`.
- Use `save_credit_note` for a standalone credit note that is not a return against one recorded sale.
- Use `list_voucher_types` with the complete customer, point-of-sale, amount, currency, and exchange-rate context when voucher eligibility is uncertain.

Read `context://core-rules` and `context://fiscal-rules` when their rules affect the request.

## Build A Valid Sale

- Money values are cents. Interpret business dates in Argentina local time and send them as `YYYY-MM-DD`.
- Customer, point of sale, product, warehouse, and payment-method inputs accept visible names or identifiers. Prefer the user's visible reference. If resolution is ambiguous, use the returned candidates instead of guessing.
- A catalog item needs `product`, `warehouse`, `quantity`, and `unitPrice`. It inherits the product tax rate.
- A custom item needs `name`, `quantity`, `unitPrice`, and `taxRateId`.
- `taxRateId` uses AFIP identifiers: `3` is 0%, `4` is 10.5%, `5` is 21%, `6` is 27%, `8` is 5%, and `9` is 2.5%. A 0% line is not the same as an exempt line; exempt lines also use `isExempt: true`.
- `total` is the final amount in cents and must match the lines. Invoice A item prices are net of IVA. Invoice B, Invoice C, and voucher X item prices are final prices; voucher X does not discriminate IVA.
- USD sales need `exchangeRate` in Argentine pesos per US dollar. Set `sameCurrencyPayment: true` when an embedded payment collects the USD sale in USD.
- Do not combine `paymentMethods` with `isFullAmountPending: true`.

If a customer is not found, search with plausible name or email variants before creating a new customer. Create one only when the user requested a new customer or confirms that no existing match is correct.

## Protect Fiscal And Retry Safety

An exact request to create, invoice, return, or credit is sufficient authorization for that operation. Do not convert a request to inspect, calculate, or draft into a write.

Invoke a write once. If the result is uncertain, or a follow-up effect such as tag application fails after the sale was created, inspect the sale and continue from the returned recovery instruction. Do not resend the full creation or fiscal-issuance call. Report the created sale, issued voucher, partial failure, or unresolved input precisely.

Government identifiers must be entered in La Pyme. Do not request DNI, CUIL, or CUIT, search by them, or return document downloads. Select an existing contact by name or a returned internal id; preserve stored fiscal data. If fiscal configuration is missing, direct the user to La Pyme and retry only the uncompleted operation.

Referenced files: 1 — file references are metadata, not package contents.

View saved version →

---
name: lapyme-supplier-cost-updates
description: Assess and apply supplier cost increases in La Pyme when product scope, margin impact, bulk adjustment, or downstream synchronization matters. Do not use for an unrelated single-product edit.
---

# La Pyme Supplier Cost Updates

Resolve the affected supplier and product scope, assess the commercial impact, and apply only the cost change the user requested.

Read `context://core-rules`, `context://reporting-rules`, and `reporting://catalog` when their money or report semantics affect the assessment.

## Resolve Scope And Impact

- Use `list_suppliers` to resolve the supplier by name, email, or a returned internal identifier.
- Use `list_products` for an explicit SKU, barcode, name, category, or product-type scope. It cannot enumerate a supplier's complete catalog.
- For a supplier-wide scope, use `run_report` with inventory dimensions `defaultSupplierName` and `product` to enumerate the products whose default supplier matches. Products bought from a supplier are not necessarily the same set.
- Ask for the supplier's file or exact product list when the affected scope cannot be identified safely from the request.
- Use reporting to estimate recent sales, margin, inventory exposure, and purchase impact. Keep cost impact separate from any selling-price recommendation.

Before a broad supplier-wide write, show the resolved scope unless the user already gave an exact product list and an explicit instruction to apply it.

## Apply The Update

- Use `bulk_adjust_products` with `target: cost` for confirmed cost changes.
- For a percentage increase across the resolved default-supplier scope, use the resolved `defaultSupplierId`, `operationType: increase`, `adjustmentType: percentage`, the requested percentage, and `allMatching: true`.
- Use explicit `productIds` instead of `allMatching` when the increase applies to a specific product or variant list.
- Do not update base selling prices unless the user separately requested that change.
- An exact apply instruction with resolved scope is sufficient authorization. Analysis alone does not authorize a write.

Read and report the result counts. `updated` is the adjusted variant count; `skipped` includes matched variants that were not changed, such as variants without a cost. Local commerce records and synchronization effects are written together, but provider execution can remain asynchronous. Do not claim that external channel prices or costs are already synchronized unless the returned state proves it.

Referenced files: 1 — file references are metadata, not package contents.