Маржа впала, а нічого не змінювали: пастка повернення при FIFO

Маржа впала на 12 пунктів за тиждень. У системі нічого не змінювали, ціни ті самі, продажі ті самі. Причина знайшлася на три тижні раніше — у поверненні постачальнику, яке всі вважали виправленою помилкою.

Найнеприємніші помилки в обліку — ті, що спрацьовують із затримкою. Документ провели в липні, помилку помітили того ж тижня, виправили, забули. А в серпні власник дивиться на звіт і питає, чому маржа просіла по всій компанії.

Цей випадок я розбирала кілька днів тому, і він гарний тим, що тут немає ані помилки програми, ані чиєїсь недбалості. Є звичайна помилка введення, цілком розумна спроба її виправити — і особливість складського обліку, про яку мало хто пам’ятає в момент виправлення.

Усе, що описано нижче, робиться мишкою в звичайних звітах Odoo. Доступ до бази й запити не потрібні.

Симптом

Тижневий звіт про маржу показує 36% замість звичних 44–47%. Падіння виглядає загальним: воно видно в підсумку по всіх продажах, а власник цілком логічно робить висновок, що «щось зламалося в системі» або «постачальники підняли ціни».

Перше, що варто зробити в такій ситуації — не шукати системну причину, а перевірити, чи вона взагалі системна. Розкладіть маржу по товарах. Якщо просадку дає один товар, шукати треба не в налаштуваннях, а в ньому.

У моєму випадку різниця була разючою: 36,5% по всьому асортименту і 48,3% без одного товару. Тобто решта номенклатури відпрацювала навіть краще за попередній тиждень.

Що сталося насправді

У закупівельне замовлення потрапив не той товар. Постачальник продає і дешеву червону ікру (близько 102 ₴ за штуку), і преміальну чорну (1 406 ₴ за штуку). У замовленні вибрали дешевий товар, а ціну лишили від дорогого. Двадцять одиниць зайшли на склад за ціною, завищеною майже в чотирнадцять разів.

Помилку помітили за кілька днів. І виправили найочевиднішим способом — оформили повернення постачальнику на всі двадцять одиниць. Кількість вирівнялася: на складі товару не додалося, залишки правильні. Усі видихнули.

Найпідступніше тут — затримка. Між помилкою і симптомом минуло три тижні. Весь цей час залишки на складі були правильні за кількістю, собівартість продажів була правильна, звіти виглядали нормально. Помилка чекала, поки черга дійде до її партії.

Як знайти це у себе: чотири екрани

Екран 1. Який саме товар зіпсував маржу

Виключати товари по одному вручну не треба — достатньо однієї зведеної таблиці.

Продажі → Звітність → Продажі, перемкнутися на режим Зведена таблиця. Далі:

• Міри: «Маржа» і «Разом без податків». Поле маржі з’являється у звіті, якщо встановлено модуль sale_margin — а він стоїть майже завжди.
• Рядки: Товар.
• Стовпці: Дата замовлення, згрупована по тижнях.

Тепер клікніть на заголовок колонки проблемного тижня — таблиця відсортується за маржею. Товар з аномалією опиниться скраю, і зазвичай його маржа буде від’ємною, чого при нормальній роботі не буває. У моєму випадку один товар показав −12 256 ₴ маржі при обороті 3 829 ₴.

Те саме можна відкрити через Продажі → Звітність → Товари — це той самий звіт, уже згрупований по товарах.

Є ще звіт «Маржі товару» (модуль product_margin): виділяєте товари в списку і викликаєте його з меню дій. Він зручний як загальний огляд, але рахує собівартість від standard_price і за рахунками, а не за фактично списаними партіями — для цієї задачі він занадто грубий.

Екран 2. Переконатися, що справа в собівартості, а не в ціні

Відкрийте будь-яке замовлення на продаж з проблемного тижня. У таблиці рядків натисніть на іконку налаштування колонок (маленький значок праворуч над таблицею) і увімкніть колонки Собівартість (Cost) і Маржа (Margin).

Якщо ціна продажу нормальна, а собівартість у кілька разів вища за звичну — питання не в продажах, а в тому, за якою ціною товар зайшов на склад.

Екран 3. Знайти саму партію

Склад → Звітність → Оцінка. Це список усіх партій: кожне надходження й кожне списання окремим рядком.

За замовчуванням тут показані не всі потрібні колонки. Натисніть іконку налаштування колонок праворуч над списком і увімкніть:

• Вартість одиниці (Unit Value) — ціна, за якою партія зайшла;
• Залишкова кількість (Remaining Quantity) — скільки з цієї партії ще на складі;
• Залишкова вартість (Remaining Value) — на яку суму.

Відфільтруйте за потрібним товаром і подивіться на колонку «Вартість одиниці». Партія з ціною, що вибивається з ряду, видно одразу — не треба нічого рахувати.

Меню «Оцінка» видно тільки з правами на оцінку запасів. Якщо його немає — попросіть адміністратора або бухгалтера подивитися разом з вами.

Екран 4. Подивитися, куди система вже віднесла різницю

Це найменш очевидний екран — і саме він рятує від подвійного виправлення.

Коли ви проводите повернення постачальнику, Odoo бачить, що товар пішов назад за однією ціною, а зі складу списався за іншою. Різницю він не залишає висіти: створює окреме, третє проведення, яке закриває розрахунки з постачальником і кидає різницю в собівартість реалізації на зменшення. Тобто витрати того місяця стають штучно меншими.

Подивитися можна в Бухгалтерія → Звітність → Головна книга, відфільтрувавши за датою повернення. Ви побачите три проведення замість двох: надходження, повернення і третє, автоматичне, на різницю.

Як виправляти

Після четвертого екрана стає видно, що роботи менше, ніж здається на перший погляд.

Крок 1. Коригування залишку

У тому ж списку Склад → Звітність → Оцінка знайдіть рядок помилкового надходження й поставте галочку саме на ньому. Угорі з’явиться меню Дії — оберіть Adjust Valuation («Коригувати оцінку»).

У вікні заповніть:

• Added value — від’ємна різниця: скільки зайвої вартості треба зняти з того, що ще на складі. Це залишкова кількість, помножена на різницю між хибною і правильною ціною.
• Counterpart Account — рахунок собівартості реалізації.
• Journal — складський журнал, підставиться сам.

Чого робити не треба

Найприродніша реакція — побачити роздуті витрати серпня й «виправити» їх ще одним ручним проведенням. Не робіть цього. Ці витрати вже врівноважені зменшенням витрат липня, яке система провела сама (екран 4). Друге проведення зробить виправлення вдвічі, а на рахунку відхилень зависне сума без підстави.

Перевірити просто: складіть зменшення липня і збільшення серпня по цьому товару. Якщо в сумі виходить приблизно те, що ще лежить на складі — усе вже врівноважено, і додаткових проведень не потрібно.

Крок 2. Собівартість у замовленнях на продаж

Останнє — і суто звітне. У кожному рядку замовлення собівартість збережена на момент відвантаження, і після коригування оцінки вона сама не перерахується. Тобто звіт про маржу далі показуватиме старі цифри.

Виправляється вручну: відкрити замовлення, увімкнути колонку Собівартість (як на екрані 2) і вписати правильне значення. Якщо таких рядків десяток — це п’ять хвилин роботи. Якщо сотні — простіше попросити розробника оновити їх пакетно.

На бухгалтерію ця дія не впливає взагалі: вона міняє тільки те, що показує звіт про маржу.

Як уникати

Помилкове надходження не можна виправляти поверненням постачальнику. Кількість вирівняється, а різниця у вартості залишиться на складі й спливе через тижні.

Що робити насправді — залежить від того, наскільки далеко зайшов документообіг.

Помилку помітили до проведення надходження

Найпростіший випадок: виправте ціну в замовленні на закупівлю і тільки потім проводьте надходження. Партія одразу створиться з правильною вартістю, і виправляти буде нічого.

Надходження проведене, рахунок постачальника ще ні

Це найкращий зі «пізніх» сценаріїв, і саме про нього найчастіше забувають. Просто проведіть рахунок постачальника з правильною ціною. Odoo сам створить коригувальну партію на різницю і виправить оцінку — причому розділить правильно: те, що ще на складі, перерахує в залишку, а те, що вже встигли продати, віднесе на рахунок витрат.

Це штатний механізм, який робить усю роботу за вас. Нічого вручну рахувати не треба — досить вписати в рахунок ту ціну, яку постачальник виставив насправді.

Рахунок уже проведений або скасований

Тоді автоматики не буде, і залишається те, що описано вище: коригування оцінки на залишок. Саме в цю ситуацію потрапив мій випадок — рахунок скасували як дубль, і виправляти довелося руками.

Часті запитання

Чи є це помилкою Odoo?

Ні. Це закладена логіка FIFO: списання йде від найстарішої партії, і повернення постачальнику не є винятком. Так само поводяться інші системи з партійним обліком.

Чи допоможе інвентаризація?

Ні. Інвентаризація вирівнює кількість, а тут кількість і так правильна. Проблема суто у вартості партії.

Як швидко це спливає?

Залежить від оборотності. Чим повільніше продається товар, тим довше помилкова партія чекає своєї черги — і тим важче потім пов’язати просадку маржі з подією тримісячної давнини.

А якщо товар уже повністю розпроданий?

Тоді не потрібно взагалі нічого. Зменшення витрат у місяці повернення й збільшення у місяцях продажу повністю погасили одне одного — облік уже правильний. Залишиться хіба що переписати собівартість у рядках замовлень, щоб звіт про маржу за минулі тижні не вводив в оману.

Чи можна це автоматизувати?

Так. Перевірку аномальних партій по всій базі можна оформити окремим звітом, який раз на тиждень надсилає список підозрілих надходжень на пошту. Це вже робота для розробника, але невелика.

Мораль тут не про Odoo. Складський облік влаштований так у будь-якій системі: черга собівартості живе своїм життям і не пам’ятає, яка саме одиниця зайшла за якою ціною. Коли ви виправляєте помилку рухом товару, ви виправляєте кількість. Вартість доводиться виправляти окремо — і саме про це найлегше забути.