Як ми будуємо касу й облік на заміну 1С для магазину: що вже працює

Чому пишемо свою касу, а не беремо готову

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

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

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

Як виглядає екран касира

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

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

Повернення і межа ціни

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

Закриття зміни

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

Що вміє облік

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

• Товари й ціни — групи, архів замість видалення (щоб старі чеки й прихід не ламались), зміна ціни рядком або масово по групі, незмінна історія цін з автором і часом.
• Закупівлі — прихід товару й оплата постачальнику однією формою, нова ціна продажу вписується тут же в рядку приходу, остання закупівельна ціна автоматично стає межею для ручної ціни на касі.
• Гроші — каси із залишками за обліком, закриття дня з перерахунком готівки, витрати за статтями, оплата постачальнику, внесення й переміщення між касами, касова книга за будь-який період.
• Борги — хто кому і скільки винен, по кожному постачальнику окремо й разом у чинних валютах.
• Валюти — гривня, долар, євро; курс дня підтягується автоматично раз на добу, прихід можна провести у валюті постачальника, оплату — гасити будь-якою валютою за курсом.
• Звіти — продажі за днями, товарами, групами, касирами й касами; рух товару; залишки на дату; продажі нижче закупівлі й нижче прайсу; курсова різниця по валютних боргах.
• Закриття місяця — період «застигає», собівартість у закритих днях більше не перераховується, а резервні копії бази робляться щодня вночі й одразу перевіряються відновленням в окрему базу.

Як переносяться дані з 1С і чому каса працює без інтернету

Дані беруться з копії бази 1С: групи, товари з одиницями виміру, чинні ціни, постачальники, каси, працівники. Вступні залишки переносяться на конкретну дату, кількість перевіряється до одиниці, а вартість бере партії з 1С. Собівартість за методом FIFO ми прогнали на всіх продажах поточного року й звірили з розрахунком 1С — розбіжність вийшла +0,006%. Там, де вона все ж є, причина в самій 1С: вона подекуди списувала партії не в порядку дат або продавала більше, ніж фактично було в партіях.

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

Офлайн-робота — одна з головних вимог. Каса тримає локальну базу прямо на собі: каталог, ціни, чергу чеків. Продаж і друк чека відбуваються без жодного запиту назовні. Коли звʼязок є, обмін з центром іде кожні 20 секунд: чеки йдуть угору й кожен потрапляє в облік рівно один раз, а зміни цін і товарів ідуть униз — нова ціна зʼявляється на плитці касира менш ніж за хвилину. Якщо звʼязку немає — чеки чекають у черзі й підуть самі, щойно зʼявиться мережа.

Каса працює з програмним РРО — модуль фіскалізації підключається окремим кроком, не змінюючи саму логіку продажу.

Що пішло не так

Кілька речей довелось переробляти вже під час роботи:

• Старий простий вебсервер тримав зʼєднання без обмеження в часі — кілька повільних підключень одночасно могли підвісити всю службу обміну. Переписали так, щоб кожен запит мав жорсткий таймаут, інакше він просто обривається.
• Коли касу перевстановлюють зі старим ключем доступу, новий чек з тим самим номером документа не ловився звичайною перевіркою на дублі в базі — вона реагує лише на повторний ідентифікатор, а не на повторний номер. Довелось додавати окрему перевірку, щоб такий чек не губився мовчки, а потрапляв у список конфліктів для людини.
• У розрахунку собівартості перший варіант не враховував, що в 1С траплялись продажі без відповідного приходу партії — довелось додати оцінку за останньою закупівельною ціною на час, поки реального приходу ще немає, і автоматичний перерахунок, щойно прихід з�ʼявляється.
• Історію цін у 1С відновити повністю не вдалось: прайс там подекуди перепроводили заднім числом, тож старі зміни цін перекривали одна одну. Рішення — почати незмінну історію цін з моменту міграції, а не намагатись реконструювати минуле.

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

Що вже працює, що в роботі і висновки

Уже готово й перевірено: продаж, повернення, закриття зміни, межа ціни на касі; офлайн-черга чеків із синхронізацією; увесь перелічений вище облік — товари, закупівлі, гроші, борги, валюти, звіти, закриття місяця; щоденні резервні копії з перевіркою відновлення.

У роботі: остаточний вибір постачальника програмного РРО для пілоту; звʼязок службових операцій на самій касі (зняття виручки) із закриттям дня в обліку; обробка повернень за чеками, виписаними ще в 1С до переходу; перевірка роботи самої програми каси на старих компʼютерах із застарілою Windows. І головне — повний паралельний пілот поруч із живою 1С ще попереду: усе перелічене перевірено на копії даних, а не на бойовому потоці продажів.

Висновки, які можна застосувати в себе:

1. Перш ніж міняти систему обліку, подивіться, якою її частиною насправді користуються — часто половина функцій морально застаріла й переносити її не варто.
2. Для вузького, простого процесу дешевше й надійніше написати малий інструмент під нього, ніж підганяти велику готову систему.
3. Офлайн-режим для роздрібної каси — не розкіш, а вимога: звʼязок у магазині падає регулярно, і продаж не повинен від цього зупинятись.
4. Незмінна історія документів і виправлення через сторно, а не редагування заднім числом, коштують небагато на етапі проєктування, але рятують від «тихих» розбіжностей в обліку пізніше.

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

Чи доведеться перенавчати продавців на нову касу?

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

Що буде, якщо в магазині пропаде інтернет?

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

Як це узгоджується з фіскалізацією й ПРРО?

Каса працює з програмним РРО — модуль фіскалізації під'єднується окремим кроком до продажу. Вибір конкретного постачальника для повноцінного пілоту ще не зафіксовано.

Наскільки точно нова система рахує собівартість порівняно з 1С?

Ми перевірили розрахунок за методом FIFO на всіх продажах поточного року й отримали розбіжність +0,006% проти 1С. Решту невеликих відхилень пояснено: 1С подекуди списувала партії не в порядку дат.

Чи можна перейти частково, залишивши якісь процеси в 1С?

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