Теоретичні основи обліку товарних запасів у Trade Control Utility

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

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

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

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

Моделі обліку товарних запасів

Вхідні дані

Спершу, ніж заглиблюватись у "моделі" (а модель - це завжди спрощення), розглянемо, а що ми маємо в реальному житті?
1. Товари надходять на склад (торгову точку, магазин, цех) від постачальників.
2. Надходження товарів відображається у вигляді прибуткових накладних, де кожен запис товару у накладній є закупівельною партією.
3. Кожна закупівельна партія має початкову кількість, поточну кількість та закупівельну ціну.
4. На підставі закупівельних цін та інших факторів утворюється ціна продажу.
5. Відвантаження (продаж) товару відображається через видаткову накладну, де для кожного товару вказана кількість та ціна продажу.
6. В будь яким момент ми можемо зробити звіт з продажу, де побачимо, в якій кількості продані товари, по яких закупівельних цінах вони до нас надходили, та по яких цінах товари були продані. На підставі цих даних вираховується товарний прибуток.
Тепер поставимо собі просте запитання.
Коли ми відвантажуємо (продаємо) покупцю товар, чи знаємо ми, з якої конкретно закупівельної партії ми його віддаємо?
Тут все залежить від напрямку торгівлі. Якщо це побутова техніка і товар штучний, кожен зі своїм серійним номером, тут все зрозуміло. Облік ведеться по кожній окремій одиниці товару наскрізь - від надходження до продажу. А якщо це продукти харчування? Постійно йдуть надходження пляшок мінеральної води, полиця постійно поповнюється, покупці постійно забираюить товар з полиці магазину. Зрозуміти, з якої конкретно закупівельної партії продано ту чи іншу пляшку води, неможливо. Інформацію про це вже втрачено. Отже для продуктів харчування, запчастин, товарів широкого попиту модель складського обліку потрібно спрощувати.
Які в нас є варіанти?

Середньозважені ціни

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

Партіонний (чи то партійний) облік

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




Andriy Kravchenko

Admin, Writer, File Uploader

05.09.2025 14:08:28

5

An error has occurred. This application may no longer respond until reloaded. An unhandled exception has occurred. See browser dev tools for details.