Опис проєкту
ПерекладУ нас інтернет-магазин, і кожне замовлення досі вручну переноситься в бухгалтерську програму. Зараз це виглядає так: працівник відкриває нове замовлення, переписує його у QuickBooks (для одного з брендів ми паралельно ведемо облік у Xero), потім створює рахунок, привʲязує клієнта й вручну править залишки на складі. Це повільно, породжує помилки, і наприкінці завантаженого тижня цифри в магазині й цифри в бухгалтерії перестають збігатися. Нам потрібна нормальна двостороння синхронізація, яка повністю видаляє цей ручний крок й тримає обидві системи в узгодженні.
Конкретно інтеграція має автоматично й в обидві боки передавати замовлення, рахунки, клієнтів, товари й складські залишки. Нове замовлення в магазині має з'являтися в обліковій системі як рахунок або продаж із правильно привʲязаним клієнтом; клієнт, створений або змінений на будь-якій стороні, має зіставлятися, а не дублюватися; а коли залишок змінюється через продаж, повернення або ручну коректування, друга система обов'язково це має підхопити. Нам важливо зрозуміле зіставлення полів — щоб ми самі вирішували, як поля магазину лягають на поля бухгалтерії (податки, артикули, способи оплати, валюти), й щоб це зіставлення можна було переглянути й поправити, а не отримати «чорний ящик».
Оскільки синхронізація двостороння, конфлікти невідворотні, і те, як ви їх розв'язуєте, для нас важливіше чистої швидкості. Якщо один і той самий клієнт або товар змінений на обох сторонах між запусками, потрібні розумні правила, вибір джерела істини за кожною сутністю й журнал, де видно, що змінено, що пропущено й що винесено на рішення людини. Опишіть, будь ласка, як ви побудуєте синхронізацію (регулярні запуски плюс близько реального часу там, де це критично), як будете усувати дублі, як відновитеся, якщо API бухгалтерії на хвилину недоступний, і як дасте нам безпечно перезапустити впалу пачку без подвоєння.
— Сутності: замовлення, рахунки, клієнти, товари, складські залишки
— Двосторонній обмін, джерело істини й журнал конфліктів за кожною сутністю
— Редаговане зіставлення полів (податок, артикул, валюта, спосіб оплати)
— Безпечні повтори й ідемпотентні перезапуски без подвійних рахунків
Конкретно інтеграція має автоматично й в обидві боки передавати замовлення, рахунки, клієнтів, товари й складські залишки. Нове замовлення в магазині має з'являтися в обліковій системі як рахунок або продаж із правильно привʲязаним клієнтом; клієнт, створений або змінений на будь-якій стороні, має зіставлятися, а не дублюватися; а коли залишок змінюється через продаж, повернення або ручну коректування, друга система обов'язково це має підхопити. Нам важливо зрозуміле зіставлення полів — щоб ми самі вирішували, як поля магазину лягають на поля бухгалтерії (податки, артикули, способи оплати, валюти), й щоб це зіставлення можна було переглянути й поправити, а не отримати «чорний ящик».
Оскільки синхронізація двостороння, конфлікти невідворотні, і те, як ви їх розв'язуєте, для нас важливіше чистої швидкості. Якщо один і той самий клієнт або товар змінений на обох сторонах між запусками, потрібні розумні правила, вибір джерела істини за кожною сутністю й журнал, де видно, що змінено, що пропущено й що винесено на рішення людини. Опишіть, будь ласка, як ви побудуєте синхронізацію (регулярні запуски плюс близько реального часу там, де це критично), як будете усувати дублі, як відновитеся, якщо API бухгалтерії на хвилину недоступний, і як дасте нам безпечно перезапустити впалу пачку без подвоєння.
— Сутності: замовлення, рахунки, клієнти, товари, складські залишки
— Двосторонній обмін, джерело істини й журнал конфліктів за кожною сутністю
— Редаговане зіставлення полів (податок, артикул, валюта, спосіб оплати)
— Безпечні повтори й ідемпотентні перезапуски без подвійних рахунків
Розробка для WEB Готівка, Банківський переказ
