Перейти до змісту

Правка замовлень постачальнику

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

Де шукати: Модулі → Замовлення постачальникам (також у модулях: Обслуговування бази даних) → Служби → Правка замовлень постачальнику

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

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

Розбір на прикладі

Уявіть замовлення на 5 дрилів. Прихід провели, рахунок отримали — у рядку замовлення має стояти «надійшло 5, зараховано 5». Після невдалого імпорту там стоїть «зараховано 0», хоча рахунок постачальника в базі є і в його шапці вказано це замовлення: у рядка рахунку втрачено посилання на рядок замовлення.

Запуск служби розкручує ситуацію по кроках:

  1. Обнуляє «у замовленнях» у всіх записах «Статусів товару» — далі це число складається наново.
  2. Проходить усі замовлення й додає замовлені кількості назад до «Статусів товару». Для непроведених замовлень окремо накопичується своя кількість. Замовлення з галочкою «Завершено» до «у замовленнях» не додає нічого, а рядок непроведеного замовлення з кодом, для якого немає картки товару, — теж.
  3. Лагодить зв'язок із рахунком постачальника: дивиться рахунок, у шапці якого вказано це замовлення (якщо таких рахунків кілька — лише перший знайдений), і в рядках із тим самим кодом товару відновлює посилання на рядок замовлення. Рядок без посилання отримує рядок замовлення цього товару з тією ж позицією, а якщо такого немає — перший рядок цього товару; отримує один раз, тож два рядки замовлення одного товару не забирають його один в одного. Рядок, чиє посилання веде за межі замовлення або на рядок іншого товару, отримує рядок свого товару з тією ж позицією. Посилання на рядок цього замовлення з тим самим товаром служба не чіпає. Саме цей крок і рятує наш приклад. Зв'язку рядків надходжень і повернень служба не лагодить: їх вона знаходить лише за посиланням на рядок замовлення, яке в них уже записане.
  4. Перераховує отримане по кожному рядку замовлення: окремо «всього в надходженнях» (враховуючи ще не проведені) і «в проведених надходженнях», мінус проведені повернення постачальнику. Рахуються лише документи цього замовлення — ті, у шапці яких вказано його номер, — так само, як при їх збереженні.
  5. Перераховує зафактуроване — сума кількостей із рядків рахунків постачальника цього замовлення; кредитові рахунки (повернення грошей) віднімаються — так само, як при збереженні самого рахунку.
  6. Записує результат у рядки замовлення й зменшує «у замовленнях» на те, що вже отримано: у дорозі лишається тільки різниця.

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

Параметри запуску

Вікно служби

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

Кнопка «Виконати» запускає перерахунок одразу, «За розкладом» ставить його в чергу регулярних завдань — але саме цій службі регулярність не потрібна (див. нижче).

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

Типові ситуації

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

У статусі замовлення недобір. Колонка «Надх.» менша за фактично отримане, хоча всі прибуткові накладні проведені й підписані.

«Статуси товару» показують очікування за закритим замовленням. Товар давно на складі й уже проданий, а система вважає, що частина ще в дорозі, — таке очікування показують, наприклад, Звіт про статус товару і Звіт про нестачу запасів.

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

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

Куди дивитися далі