Renamed POS Items
Some items keep the same button on the till while what they actually are changes. A soup of the day, a rotating special, a seasonal cake - the slot stays put and the name on it is edited every week or two.
When you rename a linked item in your POS, the link to its recipe survives the rename. That is usually what you want for a typo fix, and exactly what you do not want when the item is genuinely something else now. Until you tell Brikly which it is, the item keeps being costed as the old recipe.
The Item Mapper's Needs review tab is where you settle that question.
Why a rename matters
Say a slot called "Poached Pear" is linked to a Poached Pear recipe, and you rename it in Square to "Blueberry Burrata". Nothing breaks. Sales keep landing, margins keep being calculated - against the poached pear recipe. Every day that passes adds another day of numbers that look fine and are wrong.
The answer is not to guess. Only you know whether the new name is the same dish, a dish you have already costed, or something new. Brikly's job is to spot the change quickly, tell you, and make the fix a two-minute one.
How Brikly notices
Brikly compares the name on each linked item against the name it last saw during a catalog sync. Renames are usually picked up within a few minutes of you saving the change, and always by the next morning's sync at the latest.
A few things deliberately do not raise an alert:
- Unlinked items. An item with no recipe attached is nobody's problem yet, and the Item Mapper already shows its current name.
- Capitalisation and spacing only. "Gochujang Beans" becoming "Gochujang beans" is recorded silently as another name for the same recipe. You are not asked about it.
- A name you have already accepted. Once you have said "same recipe, just renamed" for a name, that name coming back does not ask again.
Rename alerts currently work for Square catalogs. Items from SumUp POS Pro do not raise rename alerts yet - if you rename a linked SumUp POS Pro item, use Change recipe on the item row to move it across when you are ready. The "Cost history from" date described below works on both.
The notification and the Needs review tab
When a rename is spotted you get a notification titled "[Item name] was renamed", reading something like:
Poached Pear became Blueberry Burrata on 12 Sep. It is still costed as Poached Pear.
with a Review button that takes you straight to the item. If four or more of your linked items are renamed on the same day (a bulk edit in Square, for example), they fold into a single notification - "5 linked items were renamed today" - pointing at the review list rather than filling your bell.
In the Item Mapper you will see:
- A Needs review tab beside Items, with an amber count of how many renames are waiting.
- Each waiting rename listed with its old name, its new name, the date the new name started selling, and a line reading "Still costed as [recipe]".
- A Renamed pill on the item's row in the Items tab, which jumps to the same review.
The three choices
Click Review on a renamed item and you are asked one question: what does this change mean?
| Choice | Pick it when | What happens |
|---|---|---|
| Same recipe, just renamed | The dish has not changed. A tidy-up, a spelling fix, a seasonal flourish on the name. | Nothing moves. The new name is recorded against the existing recipe so it stops being flagged, now or if it comes back later. |
| A different recipe | The slot is now selling something you have already costed. Common with a rotation that comes back around. | Costing moves to the recipe you pick, from the date you choose. |
| A new recipe | The slot is selling something you have not costed yet. | Brikly creates the recipe and links it from the date you choose. |
Brikly pre-selects the most likely answer. If the new name matches a recipe you already have, or a name this slot has been resolved to before, it pre-selects A different recipe with that recipe chosen. Otherwise it pre-selects A new recipe. You can change it.
What "A new recipe" does
Choosing A new recipe starts you from a copy of the current recipe rather than a blank page. The Start from dropdown defaults to the recipe the slot is costed as today, and you can pick any other recipe or Blank recipe instead.
A copy keeps the ingredients, consumables and labour, so on a rotating special where only the topping changes you are editing one line rather than rebuilding the dish. After you confirm, Brikly takes you straight into the new recipe so you can change the ingredients while it is still fresh in your head. The link is already made by the time you land there.
The first recalculation after you choose A new recipe uses the copied recipe's cost, because that is all Brikly knows at that moment. Once you edit the ingredients, the overnight recalculation picks up the change and restates the current period. Periods that had already closed keep the cost that was correct at the time, as they do everywhere in Brikly.
The "Cost from" date
Both A different recipe and A new recipe ask for a Cost from date. It defaults to the first day the new name actually sold on that slot, which is usually the day you renamed it or the day after.
The rule is the same one used everywhere in Brikly:
The week and month containing this date are attributed to the new recipe.
So if the new topping's first sale was a Wednesday, that whole week and that whole month are costed as the new recipe. Earlier weeks and earlier months keep the recipe that was live at the time and are never restated. That gives you an honest history: a slot that has carried eight toppings over a year reads as eight different things, not eight months of chickpeas.
You can move the date, within the range Brikly allows - no earlier than the day the current recipe's link started, and no later than today. If you pick something outside that, Brikly tells you why rather than silently accepting it.
Reprocessing
When you resolve a rename to a different or new recipe, Brikly rewrites the affected days, weeks and months in the background. While that is happening the item shows a Reprocessing chip, and the figures on your dashboards update within a few minutes. There is nothing to wait for - you can carry on.
If you do nothing
Nothing breaks, and nothing is lost. The item keeps selling and keeps being costed as the old recipe, with the flag next to it so you know the number is stale. The true name from the till still shows alongside the figures.
After 14 days, Brikly nudges you once more - "[New name] has been costed as [old name] for 14 days" - and then leaves you alone. The item stays in Needs review until you resolve it.
Correcting a choice later
Resolved it the wrong way, or picked the wrong date? You do not need to find the original alert.
- Go to the Items tab and find the item.
- Click Change recipe on its row.
- Pick the right recipe - the recipe it currently uses is offered too, so you can leave the recipe alone and only move the date.
- Set Cost from and save.
The same period-end rule applies, and the same reprocess runs. Earlier windows on the slot are left exactly as they are.
Unlinking a renamed item
Unlinking is not a way of undoing history. When you unlink an item, costing stops from tomorrow, and the history up to today keeps its recipe. The weeks and months already attributed to that recipe stay attributed to it.
If you link the slot to a recipe again later, the old window stays closed where it ended and the new one picks up from the date you choose, so the two can never overlap.
A worked example
You sell a "Topped Sourdough" and change the topping roughly every ten days, renaming the variation in Square each time rather than creating a new item.
- Monday. You rename the slot from "Miso Butterbeans" to "Curry Chickpeas" in Square. Within a few minutes Brikly raises a rename alert: "Miso Butterbeans became Curry Chickpeas on 15 Sep. It is still costed as Miso Butterbeans."
- Tuesday morning. You open the Item Mapper, see Needs review (1), and click Review. Brikly has pre-selected A new recipe with the name "Curry Chickpeas" and Start from set to the Miso Butterbeans recipe.
- You leave the Cost from date on 15 Sep, the day the new topping first sold, and confirm.
- Brikly creates the recipe, links it from 15 Sep, and drops you into the recipe editor. You swap the butterbeans line for chickpeas and curry paste - everything else on the recipe (the sourdough, the oil, the salad, the labour) is already correct. Two minutes.
- Overnight. The recalculation picks up your ingredient edit. The week of 15 Sep and the month of September read as Curry Chickpeas. The weeks before it still read as Miso Butterbeans, at the cost that was true at the time.
- Ten days later, the topping changes again. This time the new name is one you have costed before, so Brikly pre-selects A different recipe with that recipe already chosen, and the whole thing takes one click.
Related
- Item Mapper Overview - linking, unlinking, and the "Cost history from" date on a first link
- Hiding Items and Categories - keeping non-food items out of the way
- Recipe Costing - how a recipe's cost is built