1с упп аналоги номенклатури. Підбір аналогів у документи продажу

29.10.2016 (admin)

Будь-яке підприємство прагне впорядкувати систему контролю та обліку у всіх сферах діяльності: фінансової, господарської та інших. Однак відомі продукти 1С підходять не всім. Крім того, 1С є платною як у придбанні, так і в обслуговуванні. Сучасні розробники програмного забезпечення пропонують безкоштовні аналоги програм обліку.

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

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

Система управління у програмі «GrossBee» підійде як малих підприємств, так великих організацій. Кількість функцій дозволяє провести практично будь-яку операцію. Крім того, кожен блок функцій підпорядковується своїй підсистемі, яка утворює єдину базу даних. Всі бази обмінюються інформацією між собою, що підвищує точність відображення інформації та її актуальність. Розробники активно працюють над програмою, у ній з'являються нові модулі та системи.

Програма "ВС: Бухгалтерія" виключно бухгалтерська. Вона дозволяє вести облік у різних режимах оподаткування. Є можливість створення звітів з будь-яких фільтрів, касові операції, створення податкових декларацій, всілякі види обліків та банк-клієнт. Користувачі зазначають, що інтерфейс є приємним та зрозумілим. До мінусів програми можна віднести те, що її розробку зупинено. Офіційно програмою можна користуватись і вона повністю функціонує, проте технічна підтримка повністю відсутня.

"ERP Моноліт" - комплекс програм, розроблений для вирішення різноманітних завдань підприємства. Сюди входять такі продукти, як управління фінансами, планування, управління продажами та персоналом, електронний документообіг та інше. Кожен із блоків відображає актуальну інформацію та доступний для редагування одразу кільком користувачам. Усі разом вони взаємодіють, обмінюються даними. Окремо винесено можливість управління закупівлями та організацію тендерів. Розробники завжди залишаються на зв'язку зі своїми користувачами та надають технічну підтримку. Програма розповсюджується платно і є гарною альтернативою продуктам 1С.

Для невеликого підприємства чудовою альтернативою бухгалтерських продуктів 1С стане онлайн-сервіс «Класс365». Безкоштовна версія несе у собі функціонал обслуговування однієї організації одним користувачем. Користувачі відзначають приємне рішення кольору програми і зручний інтерфейс. У безкоштовну версію включені навіть такі функції як CRM, торговельний та складський облік. Технічна підтримка здійснюється повністю для всіх користувачів, незалежно від версії програми. У сфері торгівлі сервіс показав себе особливо добре, оскільки в нього вбудована функція інтеграції з інтернет-магазинами.

Безкоштовні аналоги 1соновлено: Листопад 6, 2016 автором: admin

Модуль включає наступні функції:

1. Відповідність кількох або одного товару як аналогічний до обраного
2. Підбір аналогічного товару в момент складання рахунку або оформлення продажу за відсутності обраної позиції
3. Автоматична взаємна аналогічна залежність товарів. Тобто. обравши аналог товара1 - товар2 і товар3 система автоматично вважатиме аналогом для товара2 - товар1 і товар3, і для товару 3 - товар1 і товар2

Відеопрезентація модуля для УТ 11.4

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

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

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

Версії конфігурацій, куди виконується, за бажанням, використання без додаткової оплати:

1. Торгівля та Склад 926

2. Управління торгівлею 10.3

3. Управління Торгівлею 11

4. Управління Нашою Фірмою

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

Гарантія повернення грошей

ТОВ "Інфостарт" гарантує Вам 100% повернення оплати, якщо програма не відповідає заявленому функціоналу з опису. Гроші можна повернути в повному обсязі, якщо ви заявите про це протягом 14 днів з дня надходження грошей на наш рахунок.

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

  • PHP ,
  • 1С-Бітрікс
  • Оскільки завдання написання «аналогів» та «альтернатив» 1С нетривіальне, є сенс викласти своє бачення та ключові моменти на основі досвіду написання свого наколеного виробу. Ну і як бонус почути критику і вчасно переробити, де промахнувся.

    За фактом, на даний момент 1С займає переважну частину в ніші облікових систем. Це пояснюється низкою причин, зокрема й агресивним маркетингом. Нагадаю технічну сторону. 1С у загальному вигляді, складається з двох фізично окремих елементів - власне платформи (ядра, движка) і так званої конфігурації.

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

    Це плюси. Але є й безліч мінусів. Щоб не описувати тут можна почитати наприклад.

    Спроб витіснити 1С робиться безліч. Більшість проектів намагаються переплюнути плюси 1С. Тягатися з величезною корпорацією справа малоперспективна. Продукти, писані на Делфі або .NET, тобто вимагають перекомпіляції, взагалі неконкурентні, ті, хто намагаються прикручувати як DSL двигун javascript або VBA виглядають трохи краще, але в будь-якому випадку такі рішення можуть використовуватися в основному якщо є штатний програміст, чого малий бізнес, як правило, дозволити собі не може.

    Спробуємо підібратися з іншого боку. Не намагатися переплюнути переваги 1С, а запропонувати вирішення тих проблем, де 1С має мінуси.

    Оскільки мінуси десь врівноважують плюси, а у нас цих мінусів не буде те, навіть якщо у нас не буде плюсів на рівні 1С, сальдо приблизно буде таке ж.

    Отже, які характеристики мають бути у створюваної системи.

    Open source. Кросплатформність.
    Тут пояснень не потрібно.
    Веб-додаток.
    Розрахований на багато користувачів режим з можливістю прямого доступу з мобільних пристроїв без необхідності писати спеціальних клієнтів, синхронізувати довідники і т.д.
    PHP
    Мова з низьким порогом входження, знайома більшості веб-розробників. Для внесення змін потрібно лише текстовий редактор. Веб-програма легко оновлюється заміною окремих файлів (привіт конфігуратору 1С). Скриптова слаботипізована мова у поєднанні з набором високорівневих бізнес-об'єктів добре підходить для написання бізнес-логіки.

    Здавалося б, що ще потрібне для щастя. Проте, насправді опенсорс облікові системи - це, зазвичай, криве портування зарубіжних розробок.

    Причому криве не лише локалізацією. Для приведення до вітчизняного законодавства потрібна чимала праця. Але це не все. Бухгалтер, дивлячись на сторінку такої системи, не розумітиме для чого половина полів і взагалі як тут працювати. Не забуваємо, що користувач, напевно, вже має досвід з 1С і напевно це його єдиний досвід роботи з обліковою системою. Це означає, що з сотні способів зробити макет сторінки введення накладної і підписати елементи введення потрібно вибирати той, який максимально нагадує 1С (а значить, треба перелопатити всі сторінки зарубіжного творіння).

    Коли я давав фрілансерам заповнювати свою систему демо даними (типу як демо – конфігурація в 1С), жодного разу не виникло питання – а як тут працювати.

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

    Програміст зазвичай робить систему максимально гнучкою (а як інакше!) витрачає дві третини часу на написання численних налаштувань, візардів, генераторів або того гірше тулсів для командного рядка і т.д.

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

    Прикладом є і сама 1С – від версії 2.0, де бухгалтера дійсно вводили формули спеціальною «пташиною» мовою до монстра 8.3. Спробуйте дати мануал непосвяченому і порахуйте з якої спроби він включиться в хитромудру словесну конструкцію «план видів характеристик».

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

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

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

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

    А тепер деякі спільні технічні ідеї, які можуть стати в нагоді «велосипедистам» при написанні власного «вбивця» 1С.

    Зберігання документів
    Типове питання на форумах, яке ставлять письменники CRM, облікові, складські системи та системи документообігу. Як зберігати документи, які, очевидно, мають різнорідну структуру. Окрема таблиця під кожен тип документа, загальна таблиця з купою універсальних полів, модні нині NoSQL сховища.
    Пропонується зберігати всі документи в одній таблиці в блобі, запакованих у XML. Окремо – лише загальні поля, які показуються у списках та журналах – номер документа, дата створення, автор, статус. Упаковка в XML має перевагу перед серіалізацією або json - кожне значення обрамлене іменованим тегом, а отже, можна виконувати наскрізний пошук, не натикаючись на зайві рядки. Тобто знайти посилання на контрагента щодо
    12
    не важко, тим більше більшість серверів БД підтримують XPath. Упаковка-розпакування відбувається автоматично в базовому класі, наприклад, Document, що містить два зумовлені асоціативні масиви - header і details (масив масивів для табличної частини) і які заповнюються дочірніми класами - первинними документами як їм по кайфу. Ключ асоціативного масиву стає тегом, значення – вмістом.

    Функції упаковки та розпакування викликаються відповідно перед записом та після читання документа з БД.
    Крім того, рекомендується використовувати денормалізацію. Наприклад, в документ пишеться не тільки id контрагента, а і його найменування, яке пред'являється користувачеві. Багато їсти не просить, зате дозволяє обійтися без джойнів до інших таблиць та використання «історичних» атрибутів.

    Аналогічно можна зберігати довідники – контрагенти, співробітники тощо. Окремо, у відповідних таблицях, є лише поля ідентифікаторів, найменувань, типів. Тобто те, по чому може знадобитися сортування або відбір. Решта пакується в XML. Такий підхід, крім іншого, дозволить уникнути необхідності зміни структури БД при внесенні змін до системи (наприклад поява нового атрибуту довідника).
    В ідеалі структура Бд повинна змінюватися тільки при появі в системі якихось нових бізнес-сутностей.

    Друковані форми документів та звітів.
    Просто HTML. Плюс нескладний шаблонізатор, наприклад, Fenom.

    Переваги очевидні – можемо створити будь-яку друковану форму без будь-яких будівельників, відобразити її у браузері чи роздрукувати. Крім того, HTML експортується в Word та Excel. Робиться це просто – HTML зберігається з розширенням docx або xslx. При відкритті файлу офіс (принаймні майкрософтівський) сам сконвертує в потрібний формат. Так, убого. Проте просто, універсально і не вимагає спеціального кодування. В крайньому випадку завжди можна підправити руками в тому ж екселі.

    При бажанні можна конвертувати і в pdf, але бібліотеки типу TCPDF чутливі до верстки та стилізації тому, кому треба, поставить PDFCreator і буде йому щастя.

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

    Зберігання аналітики
    Аналітичні дані, пов'язані із синтетичними рахунками у проводках. Субконто у термінах 1С. Реалізація - одна таблиця, по суті є таблицею фактів в ROLAP типу зірка. Посилання на документ, синтетичний рахунок (окремий запис на кожен кореспондуючий рахунок-типу напівпроводки), кількість, сума. Додаткові виміри – посилання на основні бізнес сутності – контрагенти, партії товарів, співробітники, грошові рахунки. Кількість та сума (відмасштабовані в цілі числа) для дебету пишуться з плюсом для кредиту – з мінусом. Це дозволяє простим підсумовуванням шляхом повного перерахунку отримувати залишки та обороти на будь-який період у розрізах основних бізнес-сутностей без необхідності зберігати проміжні підсумки. Також прораховуються і синтетичні рахунки в проводках.

    Така схема дозволяє видаляти, проводити та перепроводити документи заднім числом без перерахунку підсумків. А також проводити переднє число, наприклад, реалізовуючи резервування товарів.

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

    Модульність
    Те, на відсутність чого страждає 1С. У певному сенсі систему можна поділити на умовні «платформу» та «конфігуратор». Власне структуру сайту, системні об'єкти та сторінки можна вважати платформою (ядром). Об'єкти бізнес-логіки - довідники, документи, звіти тощо можуть бути підключені в довільному поєднанні. Насправді кожен об'єкт реалізується кількома файлами. Для найскладнішого - документа це 4 файли: шаблон сторінки введення, php файл - клас сторінки введення (бек-енд), файл шаблону друкованої форми та php файл персистентної сутності (Entity), що відповідає за збереження документа в сховищі. Файли та класи PHP у них повинні мати спільне «родове» ім'я. Наприклад, ввоєї або хорошоїдозволяє. Файли копіюються в певні папки. Потім до адмінпанелі додається новий пункт меню з посиланням на це ім'я та найменуванням пункту меню, відповідно Рахунок або Накладна. При відкритті основної сторінки меню генерується автоматично, групується, якщо зазначено, і одержуємо як "конфігурацію". При виборі пункту меню система знаходить явно незнайомий файл сторінки по «родовому» імені, а далі підтягуються шаблони та друковані форми.

    Тобто прикладна частина програми збирається і перезбирається як конструктор Lego. Навіть непрограміст може стягнути з оф. сайту або якого ресурсу виправлений документ або звіт та закинути на сайт. Та й технічно немає проблем організувати автооновлення.

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

    Може здатися, що пропонується якесь низькорівневе програмування - все захардкодити. Але ж мова 1С по суті нічим не високорівневіша за той же PHP. Просто там маніпуляція бізнес-даними здійснюється за допомогою високорівневих бізнес-об'єктів (документів, довідників), що пропонується робити і тут.

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

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

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

    Технологічна карта задається не так на виріб, але в процедуру виконання конкретної специфікації!

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

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

    Малюнок 1 – Повна схема виробництва

    Кількість технологічних карток для опису такої схеми залежить від обраної кількості специфікацій. Оскільки є ймовірність, що напівфабрикат "Каркас" випускатиметься незалежно (інакше його взагалі не виділяли б окремою номенклатурою) – на нього має бути своя специфікація. І друга специфікація – це виробництво виробу " Торшер " з " Каркаса " і " Абажура " . Значить, і технологічних карток буде теж дві.

    Малюнок 2 – Схема виробництва за специфікаціями та технологічними картами

    Технологічна карта – інструмент планування (інтерфейс «Планування», Довідники – Планування – Технологічні карти виробництва).Містить у собі:

    • Перелік технологічних операцій, які слід зробити.
    • Зв'язки операцій – кожна операція знає, яку наступну операцію потрібно передати свої результати. Якщо операція кінцева – у неї порожнє посилання наступну операцію (ознака те, що це кінцева операція).
    • Робочий центр, у якому виконується операція (чи група замінності робочих центрів).
    • Параметри виконання етапу – час виконання та кількість операцій, які здійснюються на етапі.

    Малюнок 3 – Технологічна карта

    Поля "Підрозділ" та "Стан" необов'язкові до заповнення.

    Реквізит табличної частини "№ операції" - унікальне ім'я операції в цій карті, може містити і цифри, і літери, не можна використовувати коми, крапки з комою, крапки та прогалини.

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

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

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

    Кількість - це скільки операцій слід зробити. Відомо, що від цього залежить і загальна вартість обробки, і час виконання.

    Поле "Наступна операція" - це ім'я наступної операції за маршрутом (або імена кількох наступних, перерахованих через кому). Якщо поле залишено порожнім, ця операція кінцева. Кінцевих операцій може бути кілька.

    Реквізит "Перенесення" застосовується виключно при позмінному плануванні виробництва – він визначає, чи можна виконувати операцію за кілька днів, а не за один. Або операція неподільна, наприклад, термообробка, яку розривати не можна.

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

    • Якщо в технологічній карті є етап (операція), у якої в полі "Наступна операція" через кому перераховано кілька номерів наступних операцій - це "розгалуження" маршруту. Після цієї операції можуть запуститися наступний (і не обов'язково паралельно).
    • Якщо ж у двох етапів (операцій) у полі "Наступна операція" вказано однаковий номер третьої операції, то відбуватиметься "сходження" гілок, коли дві операції закінчуються третьою операцією.

    Зв'язок технологічних карт зі специфікаціями в 1С:УПП здійснюється через регістр відомостей "Технологічні карти специфікацій номенклатури":

    Малюнок 4 – Зв'язок специфікацій та технологічних карт.

    Призначення технологічної карти для специфікації можна також з форми специфікації (вперше). Змінювати та редагувати цей зв'язок у наступних випадках – вже лише через регістр.

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

    • Для кожної номенклатури – на якій операції в технологічній карті вона поглинається.
    • Для кожної номенклатури – результатом якої операції вона є.

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

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

    Аналоги

    Аналогами матеріалів та комплектуючих у 1С:УПП вважаються ті матеріали та комплектуючі, які можуть бути використані замість основних, причому їх використання не змінить якості виготовленої продукції. Як правило, аналогами матеріалів доводиться користуватися за фактом, через брак основних матеріалів. Планування використання аналогів у конфігурації не ведеться.

    Аналоги задаються у регістрі відомостей "Аналоги номенклатури"(інтерфейс "Виробництво" - Номенклатура - Аналоги номенклатури). Обов'язковим є вказівка ​​наступних реквізитів:

    · "Номенклатура" – номенклатура, яка замінюватиметься аналогом, можлива додаткова вказівка ​​характеристики

    · "Вигляд аналога" - комплектуюча або вузол

    · "Аналог" - номенклатура або номенклатурний вузол, на який буде проводитися заміна, для номенклатури можлива також вказівка ​​характеристики

    · "Кількість" та "Одиниця" – кількість та одиниця виміру номенклатури, що підлягає заміні

    · "Кількість аналога" та "Одиниця" – кількість та одиниця вимірювання аналога, на який буде виконуватися заміна.

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

    Аналоги використовуються для підбору комплектуючих, які були використані під час виробництва продукції документи випуску продукції. Наприклад, "Звіт виробництва за зміну" (при заповненні вкладки "Матеріали" в режимі "Заповнити з підбором аналогів").

    Малюнок 5 – Підбір матеріалів та аналогів

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

    Для комплектуючих та аналогів довідково виводиться така інформація:

    · "№ операції" – номер технологічної операції, на яку подаються матеріали згідно з технологічною картою виробництва (видна тільки якщо використовується позмінне планування)

    · "Норматів" – нормативне споживання комплектуючих за даними специфікації

    ·"Одиниця" - одиниця виміру кількості комплектуючих

    · "Вільний залишок на складі" – кількість комплектуючих або аналогів, що є у вільному залишку на складі

    · "Вільний залишок у НЗП" – кількість комплектуючих або аналогів, що є у вільному залишку в незавершеному виробництві, показується тільки для тієї номенклатури, для якої довідник "Номенклатура" містить ознаку необхідності ведення оперативних залишків матеріалів у НЗП

    · "Пріоритет" – пріоритет використання аналогів, який заданий у регістрі відомостей "Аналоги номенклатури"

    Вибір аналогів можна виконувати в автоматичному режимі (кнопка "Автозаміна"). При натисканні на кнопку "Ок" у табличну частину документа перенесуться рядки, які зазначені в колонці "Використовується для випуску".

    Дякую!

    Оскільки завдання написання «аналогів» та «альтернатив» 1С нетривіальне, є сенс викласти своє бачення та ключові моменти на основі досвіду написання свого наколеного виробу. Ну і як бонус почути критику і вчасно переробити, де промахнувся.

    За фактом, на даний момент 1С займає переважну частину в ніші облікових систем. Це пояснюється низкою причин, зокрема й агресивним маркетингом. Нагадаю технічну сторону. 1С у загальному вигляді, складається з двох фізично окремих елементів - власне платформи (ядра, движка) і так званої конфігурації.

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

    Це плюси. Але є й безліч мінусів. Щоб не описувати тут можна почитати наприклад.

    Спроб витіснити 1С робиться безліч. Більшість проектів намагаються переплюнути плюси 1С. Тягатися з величезною корпорацією справа малоперспективна. Продукти, писані на Делфі або .NET, тобто вимагають перекомпіляції, взагалі неконкурентні, ті, хто намагаються прикручувати як DSL двигун javascript або VBA виглядають трохи краще, але в будь-якому випадку такі рішення можуть використовуватися в основному якщо є штатний програміст, чого малий бізнес, як правило, дозволити собі не може.

    Спробуємо підібратися з іншого боку. Не намагатися переплюнути переваги 1С, а запропонувати вирішення тих проблем, де 1С має мінуси.

    Оскільки мінуси десь врівноважують плюси, а у нас цих мінусів не буде те, навіть якщо у нас не буде плюсів на рівні 1С, сальдо приблизно буде таке ж.

    Отже, які характеристики мають бути у створюваної системи.

    Open source. Кросплатформність.
    Тут пояснень не потрібно.
    Веб-додаток.
    Розрахований на багато користувачів режим з можливістю прямого доступу з мобільних пристроїв без необхідності писати спеціальних клієнтів, синхронізувати довідники і т.д.
    PHP
    Мова з низьким порогом входження, знайома більшості веб-розробників. Для внесення змін потрібно лише текстовий редактор. Веб-програма легко оновлюється заміною окремих файлів (привіт конфігуратору 1С). Скриптова слаботипізована мова у поєднанні з набором високорівневих бізнес-об'єктів добре підходить для написання бізнес-логіки.

    Здавалося б, що ще потрібне для щастя. Проте, насправді опенсорс облікові системи - це, зазвичай, криве портування зарубіжних розробок.

    Причому криве не лише локалізацією. Для приведення до вітчизняного законодавства потрібна чимала праця. Але це не все. Бухгалтер, дивлячись на сторінку такої системи, не розумітиме для чого половина полів і взагалі як тут працювати. Не забуваємо, що користувач, напевно, вже має досвід з 1С і напевно це його єдиний досвід роботи з обліковою системою. Це означає, що з сотні способів зробити макет сторінки введення накладної і підписати елементи введення потрібно вибирати той, який максимально нагадує 1С (а значить, треба перелопатити всі сторінки зарубіжного творіння).

    Коли я давав фрілансерам заповнювати свою систему демо даними (типу як демо – конфігурація в 1С), жодного разу не виникло питання – а як тут працювати.

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

    Програміст зазвичай робить систему максимально гнучкою (а як інакше!) витрачає дві третини часу на написання численних налаштувань, візардів, генераторів або того гірше тулсів для командного рядка і т.д.

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

    Прикладом є і сама 1С – від версії 2.0, де бухгалтера дійсно вводили формули спеціальною «пташиною» мовою до монстра 8.3. Спробуйте дати мануал непосвяченому і порахуйте з якої спроби він включиться в хитромудру словесну конструкцію «план видів характеристик».

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

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

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

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

    А тепер деякі спільні технічні ідеї, які можуть стати в нагоді «велосипедистам» при написанні власного «вбивця» 1С.

    Зберігання документів
    Типове питання на форумах, яке ставлять письменники CRM, облікові, складські системи та системи документообігу. Як зберігати документи, які, очевидно, мають різнорідну структуру. Окрема таблиця під кожен тип документа, загальна таблиця з купою універсальних полів, модні нині NoSQL сховища.
    Пропонується зберігати всі документи в одній таблиці в блобі, запакованих у XML. Окремо – лише загальні поля, які показуються у списках та журналах – номер документа, дата створення, автор, статус. Упаковка в XML має перевагу перед серіалізацією або json - кожне значення обрамлене іменованим тегом, а отже, можна виконувати наскрізний пошук, не натикаючись на зайві рядки. Тобто знайти посилання на контрагента щодо
    12
    не важко, тим більше більшість серверів БД підтримують XPath. Упаковка-розпакування відбувається автоматично в базовому класі, наприклад, Document, що містить два зумовлені асоціативні масиви - header і details (масив масивів для табличної частини) і які заповнюються дочірніми класами - первинними документами як їм по кайфу. Ключ асоціативного масиву стає тегом, значення – вмістом.

    Функції упаковки та розпакування викликаються відповідно перед записом та після читання документа з БД.
    Крім того, рекомендується використовувати денормалізацію. Наприклад, в документ пишеться не тільки id контрагента, а і його найменування, яке пред'являється користувачеві. Багато їсти не просить, зате дозволяє обійтися без джойнів до інших таблиць та використання «історичних» атрибутів.

    Аналогічно можна зберігати довідники – контрагенти, співробітники тощо. Окремо, у відповідних таблицях, є лише поля ідентифікаторів, найменувань, типів. Тобто те, по чому може знадобитися сортування або відбір. Решта пакується в XML. Такий підхід, крім іншого, дозволить уникнути необхідності зміни структури БД при внесенні змін до системи (наприклад поява нового атрибуту довідника).
    В ідеалі структура Бд повинна змінюватися тільки при появі в системі якихось нових бізнес-сутностей.

    Друковані форми документів та звітів.
    Просто HTML. Плюс нескладний шаблонізатор, наприклад, Fenom.

    Переваги очевидні – можемо створити будь-яку друковану форму без будь-яких будівельників, відобразити її у браузері чи роздрукувати. Крім того, HTML експортується в Word та Excel. Робиться це просто – HTML зберігається з розширенням docx або xslx. При відкритті файлу офіс (принаймні майкрософтівський) сам сконвертує в потрібний формат. Так, убого. Проте просто, універсально і не вимагає спеціального кодування. В крайньому випадку завжди можна підправити руками в тому ж екселі.

    При бажанні можна конвертувати і в pdf, але бібліотеки типу TCPDF чутливі до верстки та стилізації тому, кому треба, поставить PDFCreator і буде йому щастя.

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

    Зберігання аналітики
    Аналітичні дані, пов'язані із синтетичними рахунками у проводках. Субконто у термінах 1С. Реалізація - одна таблиця, по суті є таблицею фактів в ROLAP типу зірка. Посилання на документ, синтетичний рахунок (окремий запис на кожен кореспондуючий рахунок-типу напівпроводки), кількість, сума. Додаткові виміри – посилання на основні бізнес сутності – контрагенти, партії товарів, співробітники, грошові рахунки. Кількість та сума (відмасштабовані в цілі числа) для дебету пишуться з плюсом для кредиту – з мінусом. Це дозволяє простим підсумовуванням шляхом повного перерахунку отримувати залишки та обороти на будь-який період у розрізах основних бізнес-сутностей без необхідності зберігати проміжні підсумки. Також прораховуються і синтетичні рахунки в проводках.

    Така схема дозволяє видаляти, проводити та перепроводити документи заднім числом без перерахунку підсумків. А також проводити переднє число, наприклад, реалізовуючи резервування товарів.

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

    Модульність
    Те, на відсутність чого страждає 1С. У певному сенсі систему можна поділити на умовні «платформу» та «конфігуратор». Власне структуру сайту, системні об'єкти та сторінки можна вважати платформою (ядром). Об'єкти бізнес-логіки - довідники, документи, звіти тощо можуть бути підключені в довільному поєднанні. Насправді кожен об'єкт реалізується кількома файлами. Для найскладнішого - документа це 4 файли: шаблон сторінки введення, php файл - клас сторінки введення (бек-енд), файл шаблону друкованої форми та php файл персистентної сутності (Entity), що відповідає за збереження документа в сховищі. Файли та класи PHP у них повинні мати спільне «родове» ім'я. Наприклад, ввоєї або хорошоїдозволяє. Файли копіюються в певні папки. Потім до адмінпанелі додається новий пункт меню з посиланням на це ім'я та найменуванням пункту меню, відповідно Рахунок або Накладна. При відкритті основної сторінки меню генерується автоматично, групується, якщо зазначено, і одержуємо як "конфігурацію". При виборі пункту меню система знаходить явно незнайомий файл сторінки по «родовому» імені, а далі підтягуються шаблони та друковані форми.

    Тобто прикладна частина програми збирається і перезбирається як конструктор Lego. Навіть непрограміст може стягнути з оф. сайту або якого ресурсу виправлений документ або звіт та закинути на сайт. Та й технічно немає проблем організувати автооновлення.

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

    Може здатися, що пропонується якесь низькорівневе програмування - все захардкодити. Але ж мова 1С по суті нічим не високорівневіша за той же PHP. Просто там маніпуляція бізнес-даними здійснюється за допомогою високорівневих бізнес-об'єктів (документів, довідників), що пропонується робити і тут.

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

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