Справді, що може бути гірше? Витрата перевищує прихід, на складі виникає від'ємний залишок, а ретельно налагоджений і прорахований облік по партіях відлітає до чортової бабусі. Що робити?
Найпростіший спосіб полягає в адміністративному (в технічному сенсі слова) заборону проводити документи заднім числом. Справді, адже # 147; мертві Бастардо не можуть успадковувати трон # 147 ;. Але далеко не кожен замовник погодиться з такою точкою зору програміста. І матиме рацію # 151; справа не тільки і не стільки в роздовбайство персоналу, вічно втрачає одні документи і несподівано знаходить інші, втрачені місяць тому. Багато бізнес-процеси побудовані таким чином, що проведення документів заднім числом є їх невід'ємною частиною # 151; наприклад, коли постачальник призначає відпускні (а для нас закупівельні) ціни на партію товару за підсумками продажів цієї партії.
Так що заборонити не вийде. Якщо програміст не зможе гарантувати коректності потрібних замовнику розрахунків, замовник не буде вступати в дебати, а просто найме іншого програміста. І буде правий.
Фірма 1С подбала про нас, ввівши в платформу для контролю за проведенням документів спеціальний об'єкт # 147; Послідовність # 148 ;. Ідея така: ми визначаємо, які документи входять в послідовність, руху яких регістрів, що здійснюються цими документами, мають для нас значення. і все, можемо спати спокійно. Система сама буде відстежувати цілісність послідовності і хронологічний порядок, а ми в будь-який момент за допомогою програмних методів цього об'єкта зможемо дізнатися, порушена послідовність, і далі діяти на власний розсуд # 151; забити болт, попередити користувача, змусити його перепровести документи в потрібному порядку, відправити скаргу начальнику користувача, відформатувати йому вінчестер і т.п.
Здавалося б, проблема вирішена. Але не все так просто # 151; відновлення послідовності на практиці означає тотальне перепроведніе всіх вхідних в послідовність документів, починаючи з # 147; збійного # 148; і закінчуючи самим останнім за часом. А якщо # 147; зіпсований # 148; документ розташовується на початку минулого року? Якщо за цей рік в базу було занесено півмільйона документів? Якщо у нас є сотня постачальників, і 99 працюють з нами як люди, а сотий # 151; як справжнісінький нелюдь, але він найважливіший для нас і # 147; збійні # 148; накладні від нього надходять щотижня? Нам доводиться постійно перепроводити і перераховувати сотні і тисячі (а особливо везучим і десятки тисяч) ні в чому не винних документів. Програмісти винаходять найнеймовірніші способи полегшити собі життя, створюючи інструменти для як завгодно хитрого автоматичного відновлення послідовностей. Послідовність явно не годиться на роль універсальних ліків. Ось якби її можна було прив'язати ні до рухам регістра, як таким, а до рухів регістра по конкретному набору вимірювань. було б набагато зручніше.
Спробуємо тимчасово забути про існування об'єкта # 147; Послідовність # 148; і озброїтися інструментом під назвою # 147; власні руки # 148 ;. Що виходить?
- Перш за все визначимо # 147; ключове # 148; вимір регістра, за яким нам потрібно контролювати руху (зазвичай, це саме верхнє вимір). Переконаємося, що це довідник, тому що для не-довідників методику ще не вигадали.
Функція Перевірка (Конт) Експорт
Кордон = Конт.Кліент.Граніца.Получіть (РабочаяДата ());
Якщо СравнітьДокіПоВремені (Кордон, Конт.ТекущійДокумент ()) = 1 Тоді
Повідомити ( "ай-ай! Послідовність порушена");
Повернення 0;
інакше
Повернення 1;
КонецЕсли;
КонецФункціі
Функція СравнітьДокіПоВремені () тупо порівнює два документа за датою / часом і її код я не наводжу зважаючи на повну тривіальності.
Процедура ОбработкаПроведенія ()
Якщо Перевірка (Контекст) = 0 Тоді
СтатусВозврата (0);
повернення;
КонецЕсли;
// тут власне проведення документа
УстановітьРеквізітСправочніка (Клієнт, "Кордон",
ТекущійДокумент (), ДатаДок. ););
КонецПроцедури
Що ми маємо в підсумку? Проведення документа заднім числом вимагає перерахунку вже не всієї бази # 147; від забору і до обіду # 148 ;, а тільки деякої частини документів. Наведений код є реалізацією найпростішого випадку, адже # 147; ключових # 148; вимірювань регістрів, на які впливає проведення документа, зазвичай кілька (клієнт, товар, фірма, etc.) і наведена схема дасть виграш аж ніяк не в будь-якому випадку. Але в деяких випадках (і це підтверджено практикою) використання механізму # 147; розумних # 148; послідовностей дає непоганий ефект.
А де тут граблі, запитає вдумливий Новомосковсктель? Адже не може ж бути, щоб технологічне обмеження платформи обходилося настільки елементарним чином. І дійсно, граблі присутні.
Не вийшло так, що ми проміняли шило навіть не мило, а на інше шило? Все залежить від ситуації. Жодна завдання не вирішується в загальному вигляді, і ні одне універсальне рішення не обходиться без додаткових витрат. Просто в одному випадку вигідніше одне рішення, а в іншому # 151; інше. Є ще ситуації, які називаються # 147; Виверт-22 # 148 ;, але мені здається, що проблема відновлення послідовностей до таких все ж не відноситься ;-)- Ілюстрація в форматі маленької конфігурації