Trade Control Utility реалізує універсальну модель обліку товарних запасів, яка автоматично надає партіонний облік за FIFO, за FEFO та середньозважений облік товарів. Під обліком товарів ми розуміємо перш за все облік товарних запасів.

Товарний запас, або товарний залишок - це інформація про те, який товар, на якій торговій точці, і в якій кількості збергігається.

Далі йде текстовий блок академічного занудства, кому не цікаво, сміливо пропускайте і переходьте до суті.

Програми обліку товарів та види складського обліку

1. Номенклатурний облік

Найбільш спрощена модель. Маємо довідник товарів (може бути розділений по групах або категоріях, навіть з вкладеними підгрупами), фактично, товарний залишок факсується прямо в картці товарного найменування. Можливо, така модель підійде для зовсім просто обліку на одній точці, де не важливе відстеження прибутку, де не задіяне автоматичне ціноутворення та інше.

2. Облік за середньозваженими цінами.

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

Коли відбувається надходження товару, середню закупівельну ціну перераховуємо, кількість збільшуємо. Коли відбувається продаж, кількість зменшуємо, закупівельна ціна в складському записі не змінюється.
У видатковій накладній фіксуємо кількість, середньозважену закупівельну ціну та ціну продажу. Ці дані є базою для формування звіту з продажу.
Які переваги? Просто рахувати, малий об'єм бази даних, все працює швидко. По великому рахунку, такої деталізації для невеликого продуктового магазину цілком достатньо. А якщо це оптовий склад? І там треба працювати з закупівельними партіями? Коли треба розпродати товар саме з цієї партії, бо спливає термін придатності? Я якщо треба провести детальний аналіз і порівняти продажі того самого товару, але від різних постачальників? Тому роблять модель більш деталізованою

2. Партійний облік.

Кожне надходження товару утворює окрему закупівельну партію з початковою кількістю та поточною кількістю. Кожна партія зберігає "свою" закупівельну ціну та постачальника. Відвантаження (продаж) товару відбувається за певною чергою. Сперши відвантажуємо товари з більш "ранніх партій", по мірі витрати, задіюємо більш "пізні". Це і є метод FIFO (перший прийшов, перший пішов). Найбільш розповсюджений та зручний. Буває ще FEFO (Firtst Expired, First Out), це коли спершу відвантажуємо з партій, в який спливає термін придатності. Модель близька до FIFO, але, не завжди практична. Коли той самий товар в супермаркеті зберігається на одній полиці, покупець не буде обов'язково забирати до кошика товари, термін дії яких скоро спливає. Є ще модель LIFO, коли спершу відвантажуємо останні, які надійшли, але я не пригадаю, де таке можна застосувати. Тому FIFO.
Яка тут проблема? З часом ці партії стають порожніми і накопичуються як луска від насіння. І їх треба кудись дівати. Сучасні бази даних без проблем справляються з такими обсягами. А от користувацький інтерфейс - не дуже. Тому постає питання, як це відображати візуально і як із цим працювати користувачу.

3. Сортовий облік.

Окремо виділяють "Сортовий облік", коли додаються розміри та кольори. Зазвичай для взуття та одягу. Я б його не виділяв в окремий вид обліку. Це той самий партіонний облік, але дещо розширений додатковими характеристиками.

Отже, проаналізувавши весь спектр пропозицій, що ми можемо запропонувати такого унікального?

Універсальна модель складського товарного обліку

А якщо в принципі відійти від поняття "моделі"? Тобто, відійти від певних спрощень, обмежень та умовностей. І реалізувати облік максимально близький до реальних процесів? Користувач не буде змушений заглиблюватись в усі ці "хащі" партіонного, сортового та середньозваженого обліку. Він просто буде вводити первинні документи і бачити стан свого бізнесу. Прозоро і зрозуміло. Чи реально це?

Відомо, що найбільш складно реалізувати речи, які виглядають простими. Що ж ми можемо запропонувати?

Упаковка складностей та принцип Оккама

Це правила проектування, якими повинен володіти кваліфікований інженер. І якими часто нехтують, породжуючі ось таких монстрів.
Чи відмовляємось ми від партіонного обліку? Ні в якому разі. Ми його упаковуємо. А якщо згадаємо про принцип Оккама - не породжувати нову сутність без крайньої на те необхідності, то відмовимось від окремої таблиці з закупівельними партіями. Бо вони в нас вже є, просто неявно. Не варто дублювати інформацію.
Де ж ми можемо побачити закупівельні партії? А це записи товарів в прибуткових накладних. Там є вся необхідна інформація. Який товар, на який склад надходить, коли, по якій закупівельній ціні, в якій кількості. І якщо при цьому додати окреме поле з поточною кількістю, то ми отримаємо повноцінну закупівельну партію з повним набором даних яка одночасно є записом товару у прибутковій накладній.
Таким чином, ми завжди знаємо загальний залишок цього товару на складі, якщо складемо всі поточні залишки закупівельних партій.

Ідея була в тому, щоб одразу реалізувати всі моделі обліку, а користувач отримував одразу всі переваги кожної з них.

Загальні нариси

Алгоритм

Вимальовується наступна послідовність операцій.

1. Товари надходять на склад (торгову точку, магазин, цех) від постачальників. Таким чином на складі утворюються товарні запаси.
2. Надходження товарів відображається у вигляді прибуткових накладних, де кожен запис товару у накладній є закупівельною партією певного товару.
3. Кожна закупівельна партія має початкову кількість, поточну кількість та закупівельну ціну.
4. Надходження першої ж закупівельної партії призводить до утворення товарного залишку на торговій точці. Наступні надходження збільшують товарний залишок, видатки відповідно зменшують.
5. Товарний залишок складається з поточних кількостей закупівельних партій на цій торговій точці.
6. На підставі поточних кількостей і закупівельних цін партій автоматично розраховується середьнозважена закупівельна ціна товарного залишку.
7. Проведення закупівельної партії з новою ціною продажу призводить до переоцінки ціни продажу товарного залишку.
8. Відвантаження (продаж) товару відображається через видаткову накладну, де для кожного товару вказана кількість та ціна продажу.
9. Видаткова накладна відвантажує товари із закупівельних партій за принципом FIFO (або його різновидом FEFO).
10. Якщо виникає потреба завжди можна вручну вказати потрібну закупівельну партію, з якої потрібно відвантажити товар отримувачу.
11. В будь який момент ми можемо зробити звіт з продажу, де побачимо, в якій кількості продані товари, по яких закупівельних цінах вони до нас надходили, та по яких цінах товари були продані. На підставі цих даних вираховується товарний прибуток.

Принцип Паретто

Більшість підприємств (умовно 80%) веде свій облік майже однаково. Можна одразу "з коробки" запропонувати їм систему, де все буде заздалегідь налаштовано, і буде працювати так, як вони очікують.

1. Використовуємо модель FEFO для тих товарів, в закупівельних партіях яких вказано термін придатності.
2. Використовуємо принцип FIFO для всіх інших товарів.
3. За потреби, у видатковій накладній завжди можна вказати потрібну закупівельну партію, з якої відбудеться відвантаження товару.

Як показує багаторічний досвід, цього абсолютно достатньо. Далі нам залишається прозоро та зрозуміло відобразити всі дані в інтерфейсі додатку.

Реалізація обліку товарів у Trade Control Utility

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

Початковий стан

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

Для прикладу возьмемо товар Насіння Semki гарбузове солоне 40г п/е

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

Бачимо роздрібну ціну 17,66 грн. Бачимо поточну кількість 3 шт.

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

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

Як бачимо, зараз ці ціни співпадають. Подивимось, чому. Для цього перейдемо в розділ "закупівельні партії".

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

Прихід товару

Зробимо прихід наступної партії цього товару і подивимось, що буде. Для цього створимо нову прибуткову накладну, і додамо в неї наш товар (і ще декілька інших, так накладна більше схожа на справжню).

Закупівельну ціну вкажемо іншу - 14,00 грн. і, відповідно, треба збільшувати роздрібну ціну, щоб витримувати беззбиткову націнку

Проведемо накладну

Як бачимо, накладну більше не можна редагувати, товар надійшов на склад. Знову відкриємо картку обліку товару по скаду.

Бачимо вже інший залишок - 19 штук, тобто наші 16, які оприходували і 3, які вже були присутні на точці раніше.

Подивимось на середньозважену ціну. А вона змінилась з 12,62 грн. на 13,78 грн. Розберемось, чому так. Для цього відкриємо розділ "Закупівельні партії".

Ми бачимо, що наш товарний залишок складається тепер з поточного залишку 3 в першій закупвельній партії, і поточного залишку 16 у новій закупівельній партії, яку ми щойно провели у прибутковій накладній.

У підсумках ми бачимо середньозважену закупівельну ціну 13,78, яка утворилась за формулою (3 * 12,62 + 16 * 14,00)/(3 + 16)=287,10 / 19 = 13,78 грн. Всі ці числа присутні в рядку підсумків, їх легко перевірити.

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

Ціна продажу

До проведення останньої прибуткової накладної ціна продажу для цього товарного залишку складала 17,66. Закупівельна ціна наступної партії товару зросла, і, відповідно, нам потрібно збільшити і ціну продажу. Іноді можна зустріти думку, що, оскільки попередня партія була закуплена за нижчою ціною, то і продана вона повинна бути за нижчою. Це в корні невірно. Якщо ми продамо товар за старою роздрібною ціною, ми не зможемо відновити товарний запас за ту саму суму. Нам доведеться витратити більше. І ми понесемо збиток. Насправді, все просто - гроші за цей час подешевшали. Нажаль.

Тому Trade Control Utility автоматично переоцінила поточний залишок у три штуки з 17,66 грн. до 19 грн. і додала туди нову партію в 16 штук. В результаті наш товарний залишок цього товару має кількість 19 штук, середньозважену закупівельну ціну 13,78 грн., та роздрібну ціну 19,00 грн. Щоб побачити, як саме відбулась переоцінка, повернемось до нашої прибуткової накладної.

В розділі "Пов'язані документи" прибуткової накладної ми бачимо документ переоцінки. Відкриємо його подвійним кліком.

Програма автоматично створила і провела акт перецінки, де переоцінила наш товар в кількості 3 шт. (товарний залишок до моменту приходу нової партії) з 17,66 (стара ціна продажу) на 19,00 (нова ціна продажу, вказана в закупівельній партії нашої прибуткової накладної). Таким чином, будь яка зміна ціни продажу на товар обов'язково документується за допомогою акту переоцінки.

Якщо відкрити картку руху товару, то можна все це побачити в концентрованому вигляді

Нас цікавлять три останніх записи. Передостанні два - це переоцінка нашого залишку в 3 штуки. Переоцінка в картці руху товару завжди фігурує як пара записів - видаток по старій ціні (17,66), прихід - по новій (19,00).

І лише після переоцінки товарного залишку на нову ціну, ми вливаємо в залишок нову кількість вже по тій самій ціні продажу 19 грн.

Відвантаження товару

Наше завдання зрозуміти, як працює модель FIFO.

Просте відвантаження

Зараз маємо дві закупівельні партії з поточними залишками в 3 та 16 штук. Спробуємо спершу відвантажити одну штуку. Як це відпрацює. Для цього створимо видаткову накладну з нашим товаром і проведем її.

На початку товарного рядка з'явився "+". Натиснемо на нього і побачимо перелік використаних закупівельних партій для здійснення цього відвантаження.

Ми побачимо, що була витрачена одна штука із закупівельної партії з закупівельною ціною 12,62. Тобто по цій накладній ми зафіксували товарний прибуток як різницю між ціною продажу 19,00 та закупівельною ціною в 12,62. Нова поточна кількість в партії зменшилась до двох штук. Відкриємо перелік закупівельних партій цього товару з накладної по правій кнопці.

Що ми тут бачимо цікавого? По перше зменшився поточний залишок в першій партії. По друге змінилась середньозважена ціна. Вона зросла з 13,78 до 13,85. Чому? Тому що доля товару з меншою ціною зменшилась.
На залишку зараз 18 штук.

Складне відвантаження

Спробуємо відвантажити одразу 10 штук і відкриємо перелік використаних закупівельних партій, натиснувши на "+" на початку рядка.

Ми бачимо, що відвантаження відбулось з двох закупівельних партій послідовно. Спочатку повністю була використана партія із залишком в 2 штуки, а потім було відвантажено 8 штук із нової партії. Сердньозважена закупівельна ціна такого відвантаження склала 13,72. Ми знову зафіксували закупівельну ціну відвантаженого товару, і відповідно товарний прибуток такого відвантаження.

Можемо побачити стан закупівельних партій.

Першу партію вичерпано в нуль. Вона закінчилась. В другій партії маємо поточний залишок 8 штук. Зверніть увагу на середньозважену закупівельну ціну, вона дорівнює 14,00 грн, оскільки розраховується із закупівельної ціни єдиної наявної партії, і, відповідно, їй дорівнює. Таким чином, ми повністю реалізували модель FIFO, одночасно зберігши модель середньозважених цін.

Відвантаження зі знижкою

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

Як поведе себе система, якщо ми відвантажимо товар по іншій ціні продажу, ніж облікова в 19,00? Наприклад, 18,30. Створимо ще одну видаткову накладну.

Відвантажимо 7 штук, але ціну покладемо 18,30. Накладна сама обрахувала знижку у 0,70 грн. за одиницю, обрахувала суму знижки та її відсоток. І бачимо в пов'язаних документах акт переоцінки. Десь ми вже таке бачили. Щось знайоме. Таке, але трохи не таке. Тоді ми переоцінювали залишок на складі, і вливали в нього прихід. А зараз ми виокремили 7 штук, які відвантажуємо, і переоцінили саме їх, не зачепивши товари, що залишаються на точці "вдома".

Подивимось тепер на картку руху товару.

7 штук переоцінили з 19,00 на 18,30 і їх же відвантажили.
Ну і глянемо, що в нас залишилось на складі

Результати

Спершу ми вибрали одну штуку з першої партії, другого разу вибрали дві до нуля в першій партії, і 8 штук в другій партії. А потім ще 7 з другої партії. І залишилась одна штука в другій партії.
І маємо загальний залишок в одну штуку.

Які можна зробити висновки.

Створити універсальну модель товарного обліку цілком можливо. Така модель вперше була створена у 2003 році, відмінно себе показала у ТЦУ3 на протязі 20 років експлуатації, і була перенесена без принципових змін до Trade Control Utility.

Облік товарних запасів: Trade Control Utility vs 1С (BAS)

?У чому головна відмінність підходу до товарного обліку між 1С/BAS і Trade Control Utility?

1С/BAS використовує традиційну модель — роздільне ведення обліку за партіями, складами та документами. Партійний облік формується окремими таблицями (“Рухи”, “ПартіїТоварівНаСкладах”), які постійно зростають і потребують регулярного очищення та регламентних обробок.
Trade Control Utility реалізує універсальну модель, де закупівельні партії “упаковані” в самі прибуткові документи. Кожен запис у прибутковій накладній є партією. Це усуває дублювання даних і дозволяє отримувати одночасно й партіонний, і середньозважений, і FEFO-облік — без окремих регламентів і довгих перерахунків.

?Як зберігаються закупівельні партії?

У BAS закупівельні партії ведуться в окремому регістрі. Для великого обороту це призводить до мільйонів записів, що уповільнюють роботу бази. Залишки обчислюються через запити до “Регістру накопичення”, що часто дає затримки при формуванні звітів.
У Trade Control Utility партія — це безпосередньо рядок прибуткової накладної з полем “поточна кількість”. Система миттєво знає, що і скільки залишилось, без складних запитів і “збору рухів”. Це дозволяє працювати з мільйонами позицій без втрати швидкодії.

?Як обчислюється середньозважена закупівельна ціна?

У 1С/BAS середньозважена ціна розраховується періодично або при проведенні документа через допоміжні регістри. Вона може змінюватись заднім числом після “перерахунку підсумків”.
У Trade Control Utility середньозважена ціна визначається в момент операції, одразу при надходженні або списанні. Усі цифри видно “тут і зараз”, без нічних перерахунків і “закриття місяця”.

?Як реалізовано FIFO і FEFO?

1С/BAS дозволяє вибрати метод списання (FIFO, LIFO, середньозважений), але кожен з них реалізований через регламентні алгоритми, що потребують додаткових обчислень при формуванні звітів і закритті періоду.
Trade Control Utility автоматично відвантажує товари за принципом FIFO або FEFO (для товарів із терміном придатності). Черговість визначається в момент продажу, а зв’язок між видатковими й прибутковими партіями відображається прямо в документі — користувач може побачити, з якої партії була відпущена кожна одиниця.

?Чи можна відслідкувати товарний прибуток у розрізі постачальників і партій?

У 1С/BAS звітність за партіями можлива, але формується через складні звіти, де потрібно вручну налаштовувати відбори.
У Trade Control Utility прибуток рахується автоматично під час продажу. У видатковій накладній одразу видно, з якої партії товар списано, яка закупівельна ціна, яка роздрібна — тобто прибуток формується в момент продажу, а не під час регламентної обробки.

?Як відбувається переоцінка товарів?

У 1С/BAS зміна ціни продажу зазвичай фіксується окремими документами (“ПереоценкаТоваровВРознице”), які потрібно створювати вручну або через обробку.
У Trade Control Utility переоцінка відбувається автоматично: якщо нова партія має іншу ціну продажу, програма сама створює акт переоцінки залишку. Це повністю документований процес, який зберігає прозорість і відновлюваність історії цін.

?Чи підходить універсальна модель TCU для різних типів бізнесів?

Так. Trade Control Utility не змушує користувача обирати тип обліку. Система “підлаштовується” під дані: якщо товар має термін придатності — працює FEFO; якщо ні — FIFO; якщо користувач хоче простий облік без партій — він теж можливий.
BAS вимагає визначитись із моделлю ще на етапі впровадження: партійний, середньозважений, за складом чи без. Перехід між ними надалі складний і часто вимагає перезапуску обліку.