Точка във времето и граница, предназначение, примери за употреба. Автоматично и контролирано блокиране

Момент от време:
Компанията 1C го описва по следния начин:
Проектиран да получава и съхранява момент във времето за обект в базата данни. Съдържа дата и час, както и препратка към обект на база данни. Използва се като стойности на свойства и параметри на метода на други обекти от типа Instant of Time.
Момент във времето се използва в случаите, когато е важно да се прави разлика между моменти във времето за обекти, които имат една и съща дата и час, например, за да се сравнят позициите на документи на времева ос.

И с вашите собствени думи:
Момент във времето е комбинация от дата и препратка към документ. Позволява ви да разделяте и организирате документи в рамките на една секунда, като подреждате всички документи в недвусмислена последователност. Получаването на данни при осчетоводяване в даден момент гарантира, че движенията, извършени в същата секунда като публикувания документ, но разположени пред него, ще бъдат взети предвид.
Но има една особеност - документите, публикувани в една и съща секунда, са подредени в произволен ред, а не в реда на тяхното физическо създаване (както беше в 7.7).

InstantTime() е моментът непосредствено ПРЕДИ позицията на документа (аналогично на CalculateRegistersOn(CurrentDocument() в 7) и ако трябва да получите момента непосредствено след позицията на документа, използвайте обекта Border
Код 1C v 8.x Момент веднага след документа = Нова граница (Връзка към документа, Изглед на граница. Включително)

Код 1C v 8.x // Примерът създава момент от време с помощта на дата и връзка към обект в базата данни.
Момент = Нов момент (TekDocument.Date, TechDocument.Link);

При получаване на баланси:
„Точка във времето“ е виртуално поле, което не се съхранява в базата данни. Съдържа обект за точка във времето (който включва ДАТА и ВРЪЗКА КЪМ ДОКУМЕНТ)
<Виртуальная>балансовата таблица не се съхранява в базата данни, а се изгражда в момента на достъп до нея.
1. изберете времева точка, по-голяма или равна на стойността на ПАРАМЕТЪРА, за която са ИЗЧИСЛЕНИ балансите
2. в този момент се получават остатъците от общата таблица
3. ако моментът от време, към който са изчислени балансите, не съвпада с момента на времето на сумите, тогава балансите се БРОЯТ по движения.

Граница:
Проектиран да получава и съхранява границата на определен диапазон от стойности. Съдържа граничната стойност на интервала, както и знак за включване или изключване на граничната стойност в интервала.
Използва се като стойности на свойства и параметри на метода на други обекти от типа Boundary.
Граница се използва в случаите, когато посочването на включването или изключването на гранична стойност е важно, например, когато се получават балансите и оборотите на регистрите за натрупване, срезовете и стойностите на информационните регистри, за задаване на интервали на заявки.

Border Type - Дефинира набор от типове граници по отношение на граничната стойност:
BoundaryView.Include - границата включва граничната стойност.
BoundaryView.Excluding - Граница изключва граничната стойност.
Код 1C v 8.x Border = Нова граница (Дата, BorderType.Включително);
Request.SetParameter("ConBorder", Border);

Пример за получаване на салда към датата на документа, включително движенията му
Заявка.Текст =
"ИЗБИРАМ

| ОТ

Request.SetParameter("MomTime", New Boundary(MomTime.InstantTime(), BorderType.Inclusive));

Пример за получаване на салда на датата на документа, но преди движението му
Код 1C v 8.x Заявка = Нова заявка;
Заявка.Текст =
"ИЗБИРАМ
| Взаимни разплащания със служители на организации Салда. Физически лица,
| Взаимни разплащания със служители на организации Салда Сума на взаимни разчети Салдо
| ОТ
| Регистър на натрупвания. Взаимни разчети със служители на организации. Салда (&MomTime, Индивидуално = &Индивидуално) AS Взаимни разчети със служители на организации Салда";
MomTime = Документи. Заплати за служители в организацията. Намерете по номер("00012","12/31/2009 23:59:59");
Request.SetParameter("MomTime", New Boundary(MomTime.InstantTime(), BorderType.Excluding));
// или така: Request.SetParameter("MomTime", MomTime.Instance());
Request.SetParameter("Physicist", Directories.Individuals.FindByCode("365"));
OutputResult(Query.Run());

Информацията е взета от сайта

Имайки достатъчно опит в прилагането на SCP, бих искал да отбележа, че при всеки проект рано или късно беше необходимо счетоводният отдел да бъде прехвърлен като отдел за работа в програмата. Има доста трудности в този процес. По-специално бих искал да отбележа прехода от BP 2.0 към UPP. Въпреки факта, че BP 3.0 вече е пуснат, мисля, че този въпрос ще остане популярен известно време. И така, каква е трудността?

Трябва да започнем с факта, че в 1.3 счетоводният отдел е по-близо до счетоводния отдел на предприятието от издание 1.6, отколкото до 2.0, въпреки че, разбира се, цялата функционалност съответства на съвременните реалности. Въпреки това, това се възприема като връщане към нещо старо, морално остаряло. И най-важното е, че в това има доста истина.

Разбира се, за счетоводни задачи конфигурацията (наричана по-нататък BP) 2.0 има предимства и удобства, но въпреки това акцентът на UPP е неговата производствена верига, която няма аналози в нито едно 1C решение (освен). За съжаление е трудно да се обърне това конкретно психологическо предимство; това може да се постигне само чрез волево решение на ръководството, че тези, които не се преквалифицират, ще бъдат уволнени.

Разлики между 1C UPP и 1C Accounting

Основните отрицателни точки, които отличават UPP от BP, които срещнах на практика:

Генериране на фактура чрез връзка (в BP тази фактура се въвежда в отделен раздел).
Външен вид на отчетите (счетоводните отчети в UPP определено изглеждат скучни, за разлика от красивите отчети в BP със зелена заглавка и много настройки).
Разлики в дневниците за документи (както имената, така и съставът на дневниците за документи, с които счетоводителите в BP са свикнали, са различни).
Наличие на допълнителни полета за търсене във формуляри за дневник на документи.

Вземете безплатно 267 видео урока за 1C:

Сега трябва да поговорим по-подробно за тези и други технически възможности, които могат да повлияят на счетоводството. И също така, какви алтернативи ни предлага 1C UPP?

Най-важната разлика в принципите на счетоводство в UPP и BP за счетоводител, според мен, е невъзможността (вероятно много ограничено количество) за отразяване бизнес сделки « Счетоводни удостоверения" В някои компании половината от счетоводството е изградено върху използването на „Операции“. Тази функция произтича от широкото използване на счетоводни регистри в UPP, а не само на счетоводни регистри. В UPP по-голямата част от операциите се извършват с помощта на специализирани документи.

Пример: повечето счетоводители отразяват лихвата по заеми, издадени с помощта на операция, посочваща кореспонденция Dt91 Kt76, но в 1C UPP този подход няма да засегне, например, регистъра на взаимните разплащания с контрагенти. Трябва да използвате документа за продажба на стоки и услуги.

Заслужава да се спомене отделно, че е възможно да се използва документът Операция, но само във връзка с документа за корекция на регистъра и този документ може да обърка всеки неподготвен потребител.

Освен това трябва да се отбележи, че има разлики в подконто счетоводството за някои счетоводни сметки и невъзможността за получаване на интересуващата ни информация чрез стандартни методи. Например сметка 60 няма трета подсметка „Документи за сетълмент с контрагента“, според която документът на Регистратора е отразен в BP; съответно няма да е възможно да видите тези документи, като използвате стандарта баланса. Част от изхода от тази ситуация е използването на отчета „Отчет за взаимни разплащания с контрагенти“.

Липсата на някои „задбалансови“ сметки в 1C UPP, например MC сметки. Действително, материалите в експлоатация се вземат предвид в сметката BP в сметката MC. В UPP информацията за прехвърлените в експлоатация материали се взема предвид в регистъра „Материали в експлоатация“, информация за тях може да бъде получена с помощта на отчета „Отчет за материалите в експлоатация“.

Липсата на процедура за приключване в края на месеца, която е толкова близка и разбираема. Да, такава обработка не е включена в SCP. Приключването на месец се извършва с помощта на бизнес процеса „Процедура за приключване на месеца“, който използва елемента от директория „Настройка за приключване на месец“.

Може би тази точка е напълно специален случай. Въпреки това си струва да се отбележи. Документ „Движение на дълготрайни активи“ - трудността тук е, че счетоводният отдел посочва откъде и къде се премества обектът на дълготрайни активи, но SCP посочва само мястото, където се премества обектът. Реалното местоположение на обекта се определя от записа в регистъра към даден момент.

Отчетът за амортизационния лист в UPP има различно представяне и не отразява движението на дълготрайни активи, като алтернатива можете да използвате модернизиран отчет.

Увеличен брой детайли за попълване. Разбира се, броят на детайлите се е увеличил. Въпреки това, благодарение на потребителските настройки, по-голямата част от тези данни могат да бъдат попълнени автоматично.

Начини за излизане от тази ситуация

По правило повечето от проблемите, с които се сблъскваме, имат няколко решения. В тази ситуация мога да подчертая например това:

В една компания позицията на счетоводния отдел беше много силна, те наистина не обичаха да се връщат в миналото на 1C UPP 1.3, проектът имаше опасност от провал... За щастие компанията имаше отлични финансови възможности... Резултатът беше пълно съответствие на всички счетоводни отчетии привеждането им във формата на BP 2.0, добавяне на нови документи към регистрационни файлове на документи, показване на формуляри за търсене във формуляри на регистрационни файлове на документи. Оказа се скъпо: както по отношение на развитието, така и по отношение на по-нататъшната поддръжка, но счетоводният отдел усети важността му и проектът продължи.

Въпреки че тази опция не изглежда много ефективна, тя съществува в живота.

Диаметрално противоположно решение би било стриктно указание от ръководството да се използва само съществуващата функционалност. Между другото, той позволява пълно счетоводство и има всички механизми за контрол. Този подход е оптимален за компанията!

За внедрители, които работят със стандартни или свои собствени конфигурации - и тези, които се подготвят за сертифициране в 1C: Специалист по платформа.

В тази статия ще разгледаме:

как използвайте управляваните ключалки правилноза оперативна и неоперативна обработка на документи
до какво може да доведе без блокиране
как да избегнем грешки, които не се откриват веднага и могат да имат сериозни последствия :)

Време за четене: 20 минути.

И така, два метода за контролиране на баланси в 1C:Enterprise 8.3

Нека започнем с факта, че обозначенията „стар метод“ и „нов метод“ са доста произволни. Всъщност, ако „нова техника“ е била използвана от 2010 г., тя вече не е много нова :)

Въпреки това отново сме принудени да спрем до тук, т.к необходимо е да се прави разлика между тези подходи и това е критично.

„Старият метод“ е подход за контролиране на остатъците, който се използва от дните на 1C:Enterprise 8.0.

От 2010 г., с развитието на платформата и добавянето на нови възможности с 1C:Enterprise 8.2, се прилага „нова методология“ ( обаче - не навсякъде).

Каква е разликата?

Основната разлика е в момента на контрол на остатъците:

При „стария“ метод балансите се контролират ПРЕДИ записването на движенията в регистрите.
Първо проверяваме балансите, ако балансите „не са достатъчни“ (ще има отрицателни салда) – няма да обработваме документа
При „новия“ метод контролът става СЛЕД запис на движенията, тоест постфактум.
Ако след изпълнението се образуват отрицателни салда, трябва да „върнете обратно“ транзакцията, тоест да анулирате документа.

Предимствата и недостатъците на новата техника са разгледани подробно в отделна статия, така че ще се ограничим само до общата теза - новата техника е по-оптимална по отношение на производителност и мащабируемост.

Добре, значи старата техника е нещо от миналото и това е съдбата на UT 10.3?

Не, това не е съвсем вярно.

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

Например, когато сумата за отписване е известна от табличната част на документа. Проблемът възниква със себестойността, защото тя трябва да се изчисли преди да се запише в регистъра, тоест да се изпълни заявка към базата данни.

Следователно новата методика може да се прилага успешно, ако данните за количество и себестойност се съхраняват в отделни регистри.

Например така:

Има обаче конфигурации, при които и количеството, и цената се вземат предвид в един и същи регистър. И тук е оправдано старият метод за контрол на остатъците все още работи!

Ето пример за един регистър както за количество, така и за цена:

Какво ще кажете за типичните конфигурации? Това е просто нова техника, нали?

Не винаги!

Например в „1C: Управление на търговията 11.3“ има 2 регистъра:

При осчетоводяване на товарителни документи регистърът „Стойност на стоките“ изобщо не се попълва. Данните влизат в този регистър само при извършване на рутинни операции за приключване на месеца.

UT 11 използва нова техника, тъй като всички данни за осчетоводяване на документи могат да бъдат получени без достъп до контролирани регистри.

Що се отнася до „1C: Счетоводство“, там се съхраняват както количеството, така и цената в един регистърсчетоводен отдел, по съответните счетоводни сметки.

Ето защо BP 3.0 използва старата техника.

Моля, имайте предвид, че количественото и разходното счетоводство в UT 11 се извършват с различни анализи. Например, разходите се поддържат допълнително по организация, подразделение, ръководител, вид дейност, ДДС и т.н.

Като част от тази статия ще анализираме блокирането както за старите, така и за новите методи за контролиране на баланси.

Относно бързата обработка на документи

Често има погрешни схващания относно този прост въпрос.

Понякога се смята, че оперативното внедряване е контролът на остатъците по нов метод. Това не е вярно, от думата „изобщо“.

Оперативната ефективност може да се анализира, докато се наблюдават остатъците, но не е необходимо.

Оперативно изпълнение– това е способността на документа да записва възникващи събития тук и сега, тоест в реално време.

Конфигурира се с помощта на специално свойство на документа:

Какво означава „да се регистрирате тук и сега“? Платформата за бързо обработвани документи извършва редица действия:

На публикуваните днес документи се присвоява текущото време
Ако два документа се публикуват едновременно, всеки ще има свое време (т.е. системата ще разпредели документите в различни секунди)
Документите не могат да бъдат публикувани на бъдеща дата.

Но основното е, че системата предава знак за ефективностдокумент за обработка:

За своевременно публикувани документи можете да пропуснете посочването на параметъра в заявката; текущите салда ще бъдат получени към 31 декември 3999 г.:

Текущите салда се съхраняват в системата и се получават възможно най-бързо (салда за други дати в повечето случаи се получават чрез изчисление).

По този начин оперативното прилагане може да бъде прието както за старите, така и за новите методи за контрол на остатъчните вещества.

Интересен факт.

В UT 11 отписването на номенклатурата на документи е забранено да се извършва своевременно. Например, това са документи „Продажби на стоки и услуги“, „Сглобяване на стоки“, „Движение на стоки“, „Вътрешно потребление на стоки“ и други.

Защо се прави това?

В системата контролът на баланса се извършва винаги в текущия момент (параметърът Период не е посочен в заявката). А липсата на оперативно изпълнение ви позволява да въвеждате документи в бъдеще, такава задача често се изисква от клиентите.

Контрол на салда по нов метод - без блокиране

Нека разгледаме накратко алгоритъма за контролиране на баланси при извършване на документа „Продажби на стоки и услуги“, използвайки конфигурация на модела.

Има два регистъра:

Налични салда – за количествено отчитане
Себестойност на стоките – за отчитане на разходите

За да контролирате продуктовите баланси, е достатъчно да работите с регистъра „Безплатни баланси“.

Кодът за обработка на публикуване ще изглежда така:

Заявка = Нова заявка;

#Област Площ1
Query.TemporaryTableManager = NewTemporaryTableManager;
#EndArea

// 4. Записване на движения в базата данни
#Област Площ4
Движения.Запис();
#EndArea

#РегионРегион6
Момент на оставащ контрол =
?(Режим = Режим на задържане на документи. Оперативен,
неопределен,
Нова граница(TimePoint(), BoundaryView.Include));
Request.SetParameter("Момент от време", Момент на оставащ контрол);
RequestResult = Request.Execute();
#EndArea

#РегионРегион7
Ако НЕ Query Result.Empty() Тогава
Отказ = Вярно;
ErrorSelect = QueryResult.Select();
Докато SelectErrors.Next() цикъл
Message.Text = "Няма достатъчно количество продукт: "+SelectionErrors.Shortage;
Message.Field = "Продукти["+(ErrorSelection.LineNumber-1)+"].Количество";
Съобщение.Съобщение();
EndCycle;
endIf;
#EndArea

#Регион Регион8
Ако Провал Тогава
Връщане;
endIf;
#EndArea

Край на процедурата

Нека разгледаме ключовите точки на алгоритъма за остатъчен контрол.

1. Инициализиране на мениджъра на временни таблици

Мениджърът ще е необходим, така че временната таблица, създадена в заявката, да е налична в следващите заявки.

Така данните от табличната част се получават еднократно, записват се във временна таблица и след това се използват многократно.

2. Заявка за групиране на таблични данни

Заявката избира групирани данни от табличния раздел.

Моля, имайте предвид, че номерът на реда на документа също е избран - той ще бъде необходим за контекстуализиране на съобщението за грешка. За номера на реда се използва агрегатната функция MINIMUM() - т.е. съобщението ще бъде обвързано с първия ред, където се среща указаната номенклатура.

Първата заявка в пакета създава временна таблица. Във втората заявка се избират данни от временна таблица и се добавят 2 полета, необходими за всеки запис в регистъра - Период и Тип движение.

Предимствата на този подход:

Не е необходимо да извършвате предварително почистване, тоест да използвате метода Clear().
Няма нужда да организирате цикъл въз основа на селекцията или табличната част.

Между другото, подобен подход се използва в стандартните конфигурации, по-специално в UT 11 и BP 3.0.

4. Записване на движенията в базата данни

Записът може да се извърши с една команда (вместо две) - Movements.FreeRemains.Record().

И в нашия случай, когато се пише един регистър, няма да има разлика.

Но този подход е по-универсален:

Първо задайте флага Write за необходимите набори от регистрационни записи
След това извикайте метода Write() на колекцията Movement, който записва всички набори с флаг Write, зададен в базата данни

След изпълнение на командата „Movements.Record()“, флагът за запис за всички набори ще бъде нулиран на False.

Също така трябва да запомните, че в края на транзакцията (след последваща обработка) системата автоматично ще запише в базата данни само тези набори от записи, за които флагът Write е зададен на True.

Използване на типични решения подобна схемаза запис на движенията. Защо?

Методът Write() на колекцията Movement записва набори от записи в една и съща последователност, дори за различни документи.

Ръчното записване на движения може да доведе до проблеми.

Да дадем пример.

Ако напишете в документа „Внедряване“ така:

Movements.FreeRemainders.Write();
...
Movements.Cost of Goods.Write();

И в документа „Движение на стоки“ променете реда:

Движения. Цена на артикулите.Write();
...
Движения. FreeRemainings.Write();

Това може да доведе до блокиране на документи в пресичащи се набори от елементи.

Горният подход за запис на движение може да се използва, ако подходящата стойност за запис на движение е указана в свойствата на документа:

5. Запитване за получаване на отрицателни салда

Заявката избира отрицателни салда по позиции от документа.

Отрицателното салдо е недостиг (недостиг) на продукт.

Връзката към елементите от документа се извършва само за получаване на номера на реда.

Ако не планирахме да свързваме съобщения с полета на документа, заявката можеше да бъде значително опростена - данните щяха да бъдат получени от една таблица (останалата част от регистъра).

6. Определяне на момента във времето за контрол на остатъчните вещества

Тук оперативното изпълнение дойде на помощ.

Ако документът се извърши своевременно, тогава моментът за получаване на салда е Неопределен, което означава получаване на текущи салда.

Ако това е неоперативна транзакция, тогава получаваме точка във времето „след“ документа - за да вземем предвид току-що направените движения.

Нека си припомним, че получаването на текущи салда е бърза операция в сравнение с получаването на салда в произволен момент от време.

Именно това е ползата от бързо оформените документи.

7. Ако заявката не е празна, това означава, че са формирани отрицателни салда

В цикъла преминаваме през всички отрицателни остатъци и показваме съобщение, прикрепено към редовете на табличната част.

Ето как ще изглежда диагностичното съобщение:

8. Ако има грешки, върнете се от манипулатора на събития

Ако има поне една грешка, излизаме от процедурата.

Тъй като няма смисъл да продължаваме транзакцията, транзакцията така или иначе няма да бъде записана (и тогава ще разработим код за отписване на партиди).

Изпълнение на отписване на разходи по партиди

След като проверката на балансите е успешна, можете да започнете да отписвате партидите.

Кодът за отписване от FIFO ще бъде така:

// I. Анализ на изместването на датата на документа напред

И НЕ ThisObject.ThisNew()
And ThisObject.Conducted Then

Заявка = Нова заявка;
Заявка.Текст =
"ИЗБИРАМ
| Документ.Дата КАТО Дата
| ОТ
|КЪДЕ

RequestResult = Request.Execute();
ИзберетеДокумент.Напред();

В противен случай
лъжа);
endIf;

Край на процедурата

Процедура при запис (отказ)

ThisObject.AdditionalProperties.Insert("DocumentDateMovedForward",
ThisObject.Date>

endIf;

Край на процедурата

ProcessingProcedure(неуспех, режим)

Заявка = Нова заявка;

// 1. Инициализация на мениджъра на временни таблици
#Област Площ1
...
#EndArea

// 2. Данни от таблица за групиране на заявки
#Област Площ2
...
#EndArea

// 4. Записване на движения в базата данни
#Област Площ4
...
#EndArea

// 5. Запитване за получаване на отрицателни салда
#РегионРегион5
...
#EndArea

// 6. Определяне на момента във времето за контрол на балансите
#РегионРегион6
...
#EndArea

// 7. Ако заявката не е празна, значи са формирани отрицателни салда
#РегионРегион7
...
#EndArea

// 8. Ако има грешки, връщане от манипулатора на събития
#Регион Регион8
...
#EndArea

// II. Подготовка на набори от записи за регистър "Стойност на стоките".
#Област ОбластII

Движения.Запис();
endIf;
Movements.Cost of Goods.Record = True;
#EndArea

// IV. Цикъл по документна номенклатура
#AreaAreaIV

// V. Вземете сумата за отписване
//VI. Партиден цикъл по FIFO
Докато SelectionBatch.Next() и RemainingWrite>0 цикъл
// VII. Проверете за нулев баланс
Ако SampleBatch.QuantityRemaining=0 Тогава
Продължи;
endIf;
Movement.Period = Дата;

// VIII. Изчисляване на количеството и сумата за отписване

// IX. Ще намалим сумата за отписване
EndCycle;
EndCycle;
#EndArea

Край на процедурата

Нека да разгледаме ключовите точки на алгоритъма за отписване на партиди с помощта на FIFO.

I. Анализ на изместването на датата на документа напред

Тук разбираме дали датата на публикувания документ се премества напред. Тази информация ще бъде полезна по-долу при почистване на движения.

За да се анализира изместването на датата на документа, са необходими 2 събития:

Преди запис– за получаване на старата дата на документа и проверка на режима на осчетоводяване на документа
При запис– за получаване на нова дата на документа

Прехвърляме данни между събития чрез специална колекция на обекта – „Допълнителни свойства“. Съществува, докато текущата версия на обекта е в паметта, тоест е достъпна за всички събития по време на изпълнение.

Подобна техника се използва в стандарта „1C: Счетоводство 8“. Но се използва едно събитие „Преди запис“.

Защо не е необходимо да използвате „При запис“ в BP?

Всичко е просто - транспортните документи не могат да бъдат обработени своевременно в счетоводния отдел. Това означава, че времето на документа няма да приеме оперативен печат (ако документът е публикуван повторно в текущия ден), следователно както старата, така и новата дата на документа могат да бъдат получени в събитието „Преди запис“.

II. Подготовка на набори от записи за регистър „Стойност на стоките”.

Режимът на изтриване на движение е зададен за документа - „Когато публикуването е отменено“:

По този начин има възможност при повторно публикуване да вземем предвид движенията на самия документ. НО това ще стане само ако датата на документа е изместена напред. Тоест има смисъл да се изчистват движения само когато датата на документа е изместена напред.

Ето един пример:

Балансът на мониторите LG към момента на документи е 10 бр.
Осчетоводен е документ, който отписва 8 бр.
В същия документ времето се увеличава с 1 минута, нека повторим

Ако старите движения не бъдат изтрити, системата ще отчете недостиг на 6 монитора, тъй като текущите движения на документи вече са отписали 8 от 10 налични монитора.

Забележка. Понякога има съвет - да се премахнат движенията само по време на операция.

Но това е погрешно: те няма да вземат предвид ситуацията на промяна на „неоперативни“ документи (вчерашни и по-ранни).

Тоест проблемът с „недостиг на 6 монитора“ (виж по-горе) в този случай ще бъде решен само за документи, модифицирани днес.

III. Заявка, която получава партидни салда за отписване с помощта на FIFO

В заявката ние се позоваваме на балансите по партиди и в същото време наслагваме общите суми по позиции.

На общо ниво се получава количеството от документа - МАКСИМУМ(Количество) и баланса на партидата - СУМ(Оставащо количество).

Смятате ли, че количеството от документа може да надвишава общия баланс на артикула за всички партиди?

Ако движенията в регистрите „Свободни остатъци” и „Разходи за стоки” по количество се извършват синхронно (както входящи, така и изходящи), тогава такава ситуация не може да възникне. На това ще разчитаме при отписване на партиди.

IV. Цикъл по документна номенклатура

Благодарение на резултатите в заявката във външния цикъл, ние заобикаляме номенклатурата от документа.

V. Вземете сумата за отписване

Нека си спомним колко трябва да отпишете. По-нататък тази сума ще намалява.

VI. Партиден цикъл по FIFO

Вложеният цикъл ще съдържа партиди според текущия елемент.

VII. Проверете за нулев баланс

По принцип ситуацията, когато партидният баланс е нула, е грешка в системните данни (въпреки това е възможна такава ситуация). Въпросът е, че в този случай сумата НЕ е нула (виртуалната таблица на балансите на регистъра не връща записи с нулеви стойности на ресурса).

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

VIII. Изчисляване на количеството и сумата за отписване

Количеството за отписване е минималната стойност между остатъка от партидата и това, което остава за отписване.

Сумата се изчислява по елементарна пропорция.

Ако целият баланс на партида бъде отписан, цялата сума на тази партида ще бъде отписана. Това е математика за 3-ти клас в енорийско училище: X*Y/X = Y:)

Тоест НЕ е нужно да го правите допълнителни проверки(понякога те дават такива съвети) до факта, че цялата сума е отписана. Този съвет дори има собствено име - “ проблемът със стотинките».

А за тези, които дават лоши съвети, има смисъл да разгледате конфигурацията „1C: Accounting 8“. Там (о, ужас!) няма проверка, че цялата партида е отписана :)

Ето екранна снимка на общия модул „Счетоводство на стоките“, методът „Отписване на оставащите стоки“:

IX. Ще намалим сумата за отписване

Трябва да разберете колко остава за отписване. За да направите това, извадете количеството от движението на регистъра.

Защо са необходими управлявани ключалки?

Тук стигаме до контролирано блокиране.

Изглежда, че представените по-горе алгоритми работят като часовник. Можете да ги тествате сами (връзки към изтегляния на база данни в края на статията).

Но по време на реална многопотребителска работа ще започнат проблеми и, както често се случва, проблемите няма да бъдат открити веднага...

Нека дадем пример за най-типичния проблем при отписване на артикул, когато 2 потребители почти едновременно се опитват да отпишат артикул (да направят продажба):

В този пример двама потребители почти едновременно извършват продажба на стоки - документ № 2 започва да се извършва малко по-късно от документ 1.

При получаване на салдото системата отчита, че салдото е 10 единици, като и двата документа са обработени успешно. Тъжният резултат е минус 5 LG монитора на склад.

Но в същото време контролът на остатъчните вещества работи! Тоест, ако документ № 2 е осчетоводен след края на документ № 1, системата няма да осчетоводи документ № 2:

Понякога има погрешно схващане - „Само 3-4 потребители работят в моята база данни едновременно, вероятността за паралелна обработка на документи е нула, така че не е нужно да се разсейвате от блокиране.“

Това е много опасни разсъждения.

Дори двама потребители могат да публикуват документи почти едновременно, например ако единият от тях извършва групово публикуване на документи.

Освен това не можете да сте имунизирани срещу увеличаване на броя на потребителите. Ако бизнесът тръгне, тогава ще са необходими нови търговци, складови служители, логистици и т.н. Следователно трябва незабавно да създадете решения, които ще работят стабилно в среда с много потребители.

Как да решим проблема при паралелно осчетоводяване на документи?

Решението е просто - блокирайте мониторите на LG в момент T1, така че други транзакции да нямат достъп до балансите за този продукт.

След това във време T2 системата ще изчака LG мониторът да бъде отключен. И след това системата ще получи текущия баланс на стоките и отписването на стоките ще бъде завършено (или не е завършено).

Само няколко думи за класификацията на блокирането.

Има 2 вида брави:

Обект
Транзакционен.

Казано по-просто, блокировките на обекти не позволяват интерактивнопромяна на един обект (елемент от директория или документ) за двама потребители.

И заключването на транзакции позволява програмноработете с текущи данни, когато извършвате движения между регистри.

В тази статия ще се интересуваме от транзакционни ключалки, след това просто ключалки.

Кога трябва да се приложи блокирането?

Задачата за задаване на ключалки става актуална веднага щом базата данни стартира работят повече от един потребител.

Трябва да се поставят ключалки върху транзакциите, но кога се случват транзакциите? Точно така, най-честият случай е обработка на документи.

Тоест трябва да се прилага блокиране при обработка на всички документи?

В никакъв случай. Определено не си струва да настройвате ключалки „за всеки случай“.. В края на краищата самите заключвания намаляват едновременността на потребителите (системна скалируемост).

Трябва да се поставят заключвания върху ресурси (редове на таблица), които се четат и модифицират в транзакции. Например при извършване на документи.

В примера по-горе такъв ресурс е балансът на продукта. Системата трябваше да блокира баланса от момента на получаване на данните за баланса (T1) до края на транзакцията (T3).

Забележка. Транзакцията при осчетоводяване на документ № 1 започва по-рано от момента на получаване на салдото. Но за простота приемаме, че T1 е както началният час на обработка на документа, така и моментът на получаване на салда.

Пример кога няма нужда от заключване– извършване на документ „Получаване на стока“. В този случай няма конкуренция за ресурси (остатъци, ...), така че блокирането ще бъде вредно: то ще намали скалируемостта на системата.

Автоматично и контролирано блокиране

Тук няма да навлизаме в теорията (това е тема на отделна статия), а само ще кажем, че управляваните брави са по-оптимални.

Вместо теория, можем да дадем доказателство - всички съвременни стандартни конфигурации работят на контролирани блокировки.

Следователно в конфигурацията на нашия модел ще бъде избран подходящият режим:

Контролирани ключалки в новата технология за контрол на остатъците

Ние ще приложим заключване към регистъра „Безплатни баланси“ и само към артикулите, намерени в документа.

освен това правилна опция за блокиране– възможно най-късно.

При новия метод за контролиране на салда това трябва да се направи преди записване (или по време на записване) на движения в регистъра „Свободни салда“, така че други транзакции да не могат да променят този споделен ресурс.

Заключването може да се постави ръчно (програмно) и малко по-късно ще покажем как става това.

Но допълнителен бонус нова технологияоставащият контрол е, че е необходим само един ред код за заключване на споделени ресурси.

Просто трябва да зададете свойството BlockForChange в набора от записи в регистъра:

// 3.1. Остатъците от заключващия регистър
#Area Area3_1
Moves.FreeRemainders.BlockForChange = Вярно;
#EndArea

// 4. Записване на движения в базата данни
#Област Площ4
Movements.FreeRemainders.Write = True;
Движения.Запис();
#EndArea
...

В резултат на това 2 транзакции няма да могат да променят свободните салда за един артикул.

Всъщност, когато свойството е BlockForChange не инсталира управлявано заключване, той само изключва режима на разделяне на общите регистри при запис.

Но за нашата статия е основно следното: системата ще зададе заключване на комбинацията от данни, записани в регистъра. Ще разгледаме подробно работата на свойството BlockForChange в отделна статия.

Между другото, в стандартния UT 11 не е толкова лесно да се намери настройката на свойството BlockForChange за регистъра „Безплатни баланси“. Факт е, че това се извършва в модула за набор от записи в регистъра, в събитието „Преди писане“.

Това е всичко, с един ред код беше осигурена правилната работа на системата!

важно. Ние не заключваме регистъра „Цена на стоките“.

Защо? Такова блокиране би било ненужно (и това е известно натоварване на 1C сървъра), тъй като движенията към регистрите „Свободни баланси“ и „Цена на стоките“ винаги се извършват синхронно, тоест последователно един след друг.

Следователно, като блокираме стоки от „Свободни баланси“, ние няма да позволим други транзакции преди тези стоки и в регистъра „Стойност на стоките“.

Но за стария метод за остатъчен контрол блокирането ще се прилага по различен начин. Първо, нека да разгледаме алгоритъма за партидно отписване за този случай.

Стар метод за контрол на остатъците

Припомняме, че старата методика може да се прилага, ако количеството и себестойността се отчитат в един регистър.

Нека това да е регистърът „Цена на стоките“:

Тогава алгоритъмът за осчетоводяване на документа „Продажби на стоки“ ще изглежда така:

// 1. Обработчик на събитие "Преди запис"
Процедура преди запис (отказ, режим на запис, режим на провеждане)

Ако режим на запис = режим на запис на документ
И НЕ ThisObject.ThisNew()
And ThisObject.Conducted Then

Заявка = Нова заявка;
Заявка.Текст =
"ИЗБИРАМ
| Документ.Дата КАТО Дата
| ОТ
| Документ Продажби на стоки и услуги AS Документ
|КЪДЕ
| Document.Link = &Връзка";
Request.SetParameter("Връзка", ThisObject.Link);
RequestResult = Request.Execute();
SelectionDocument = Query Result.Select();
ИзберетеДокумент.Напред();

ThisObject.AdditionalProperties.Insert("OldDocumentDate", SelectDocument.Date);

В противен случай
endIf;

Край на процедурата

Процедура при запис (отказ)

Ако НЕ е ThisObject.AdditionalProperties.Property("DocumentDateShiftedForward"), тогава

ThisObject.AdditionalProperties.Insert("DocumentDateMovedForward",
ThisObject.Date>ThisObject.AdditionalProperties.OldDocumentDate);

Доклад(ThisObject.AdditionalProperties.DocumentDateMovedForward);
endIf;

Край на процедурата

ProcessingProcedure(неуспех, режим)

// 2. Премахване на "стари" движения на документи
Ако AdditionalProperties.DocumentDate е ShiftedForward Тогава
Movements.Cost of Goods.Record = True;
Movements.Product Cost.Clear();
Движения.Запис();
endIf;

// 3. Задаване на флага за запис на движения в края на транзакцията
Movements.Cost of Goods.Record = True;

Request.SetParameter("TimePoint", TimePoint());
Request.SetParameter("Връзка", Връзка);

RequestResult = Request.Execute();

SelectionNomenclature = Query Result.Select(BypassQueryResult.ByGrouping);

// 5. Цикъл по позиция - проверка дали количеството е достатъчно за изписване
Докато SelectionNomenclature.Next() цикъл

Номенклатурен дефицит = Примернаноменклатура.Количество - Примернаноменклатура.Оставащо количество;

Ако номенклатурен дефицит>0 Тогава
Съобщение = Ново съобщение до потребител;
Message.Text = "Няма достатъчно количество продукт: "+Номенклатурен дефицит;
Message.Field = "Продукти["+(SelectionNomenclature.LineNumber-1)+"].Количество";
Message.SetData(ThisObject);
Съобщение.Съобщение();
Отказ = Вярно;
endIf;

Ако Провал Тогава
Продължи;
endIf;

// 6. Вземете сумата за отписване
RemainingWrite = Примерна номенклатура.Количество;
SelectionBatch = SelectionNomenclature.Select();

// 7. Партиден цикъл
Докато SelectionBatch.Next() и RemainingWrite>0 цикъл

Movement = Movements.Cost of Goods.AddExpense();
Movement.Period = Дата;
Movement.Nomenclature = SelectionBatch.Nomenclature;
Movement.Batch = SelectionBatch.Batch;
// 9. Изчисляване на количеството за отписване
Movement.Quantity = Min(RemainingWrite, BatchSelection.QuantityRemaining);
// 10. Изчисляване на сумата за отписване
Movement.Amount = Movement.Quantity*
SampleBatch.AmountRemaining/SampleBatch.QuantityRemainder;

// 11. Намалете сумата за отписване
RemainingWrite = RemainingWrite - Movement.Quantity;

EndCycle;
EndCycle;

Към днешна дата софтуерни продукти 1C е своеобразен стандарт за счетоводство, управление и други видове счетоводство в малкия и среден бизнес. Работодателите изискват от служителите си да имат необходимите умения за работа с този конкретен софтуерен продукт. Ако въпросът за интегриране на онлайн магазин и системи за автоматизация (остатъци, цени, поръчки и т.н.) възникне на дневен ред, офисът обикновено разполага и с база данни 1C, с която трябва да се извърши интеграция. По същия начин в много други случаи: всеки процес на автоматизация за малки и средни предприятия традиционно започва с продуктите на 1C и продължава с тяхното използване.

Като бизнес консултант доста често срещам въпроси за това какво е 1C, каква структура може да има този софтуерен продукт и като цяло как работи цялата тази система.Те обикновено се задават от уеб разработчици, които са принудени да се справят с проблеми с интеграцията на сайта и 1C, програмисти, специализирани в мобилни приложения и други специалисти, които поради естеството на работата си трябва да се занимават с 1C програми рядко.

В тази статия реших да събера отговори на най-много ЧЗВ, които постоянно възникват в работата ми. Затова искам веднага да ви предупредя: статията е предназначена за хора, запознати с ИТ технологиите; бизнесмени, счетоводители, хора, далеч от ИТ сферата, най-вероятно ще им е трудно да разберат някои от нюансите. Разбира се, ще се опитам да пиша възможно най-просто и нямам намерение да се задълбочавам в техническите нюанси на ниво код, но все пак някои термини и концепции може да изглеждат сложни за неспециалисти.

Няколко думи за моя опит с 1C

По едно време работих като програмист на 1C в основен проект, след това зае позицията на ръководител на проекта, беше доста дълго време ръководител на проектния отдел, който се занимаваше изключително със задачи в 1C.

Сега, както неведнъж съм писал, работя като бизнес консултант в областта на малкия и среден бизнес. Постоянно се сблъсквам с различни задачи, свързани с автоматизацията на работата и в резултат на това със софтуерните продукти 1C. Най-често като бизнес консултант наемам специалисти от 1C за решаване на определени проблеми, имам постоянен екип и привличам специалисти на трети страни, включително свободни професии. В много редки случаи сам пиша нещо в 1C, най-често ако спешно трябва да реша малък проблем.

От друга страна, все повече се отдалечавам от постоянна работас продуктите на 1C. Ако в началото на кариерата ми работата с 1C програми ми донесе 100% от доходите ми, днес внедряването на някои 1C решения заема не повече от 20% от работата ми, всичко останало са уебсайтове, CRM системи и т.н.

Ето защо, въпреки че все още не съм се отдалечил твърде далеч от проблемите, свързани с програмата 1C, реших да систематизирам знанията си, да събера и запиша важни аспекти и нюанси на работа с тези софтуерни продукти

Малко повече за 1C и защо пиша всичко това

Аз самата знам, че ми предстои, както се казва, да прегърна необятното. Затова още едно предупреждение:

Планирам да създам цяла поредица от статии за 1C, където ще говоря за този софтуерен продукт от различни гледни точки. Тази статия е предназначена предимно за програмисти. Ето защо го публикувам в Хабре. Следното ще обхваща по-широк кръг от концепции, включително тези, които представляват интерес за бизнесмени и потребители на софтуерни продукти 1C, и следователно те ще бъдат публикувани в Megamind.
Няма да се задълбочавам в нюансите на използването на кода или други технически подробности, които всеки от вас може да прочете сам на официалния уебсайт на 1C, на сайтове за поддръжка, на известни форуми и др.
Няма да обсъждам нюансите на това как работи тази или онази версия на платформата. Освен това най-често ще говоря за платформа 8.3 като най-нова към момента на писане, както и за типични конфигурации, които са най-търсени сред моите клиенти (среден и малък бизнес).

В същото време не просто искам да помогна на уеб програмист или друг специалист да разбере къде да търси правилното парче код, искам да им помогна да разберат какво е това – 1C.

Днес компанията 1C сама въведе толкова много объркване в описанията на продуктите, в изискванията за нивото на специалистите, които ще конфигурират системата, в избора на платформа, конфигурация, плъгини, добавки, версии и т.н., и т.н., че системата 1C лично започва да ми напомня за стария телевизионен сериал „ Октопод“. Ако някой друг помни, в този филм комисарят се бори с престъпна групировка, част от която беше банкова група. И този банкова системабеше толкова объркващо, че беше много трудно да се разбере откъде идват парите, къде отиват, как работи този или онзи отдел и най-важното защо.

В системата 1C усилията за „объркане“ на потребителя, струва ми се, са насочени към едно нещо: не е нужно да разбирате нищо, просто трябва да платите. И много бизнесмени всъщност плащат, без да разбират дали имат нужда от тази актуализация, дали имат нужда от този продукт. Просто плащат и това е.

Ще се опитам да разплета „пипалата на октопода“ и да структурирам общо разбиране за това как работи системата 1C.

Също така бихме искали да напомним на програмистите, че можете да намерите всяка техническа информация на уебсайта на 1C. Изобщо не смятам да се спирам на тези нюанси. ще пиша на прост език, доколкото е възможно, по фундаментални въпроси.

И ако имате нужда от някакви специфични технически нюанси на 1C, винаги можете да използвате следните ресурси:

1C уебсайт и партньорски форум. http://www.1c.ru
Други ресурси

В по-голямата част от случаите отговорите на вашите въпроси ще бъдат намерени на един от тези ресурси. Има още много форуми и други неща, но повечето от решенията са там.

1C като екосистема

Когато бизнесмен, адвокат, счетоводител, продавач и друг потребител срещне 1C програми, много често има неразбиране какво е това. Някои хора смятат, че 1C е удобна системасчетоводство, за едни – че това е система за автоматизиране на онлайн магазин, за други не разбират много за какво говорим. Някои дори смятат, че с помощта на този или онзи продукт 1C можете да разрешите всеки бизнес проблем, просто трябва да изберете правилния продукт и може би да го промените малко.

Причината за такива очевидно погрешни възприятия е, че никой не разбира какво е 1C от гледна точка на платформата. Всеки вижда нещо различно, специфично. Самият 1C носи още повече объркване, тъй като активно поддържа всички тези погрешни схващания поради своя маркетинг, който се опитва да позиционира 1C като решение за всички случаи и за всякакви цели.

В статията вече казах, че всъщност 1C трябва да се възприема като цяла екосистема. Именно този подход ще ви помогне да разберете какво е 1C и защо е необходимо.

И така, от гледна точка на техническата екосистема, 1C се състои от следните компоненти:

Платформата 1C е основата, върху която се пишат конфигурации, с които работят програмистите и т.н. Тя се актуализира от версия на версия и следователно може да бъде: 6.0, 7.7, 8.0, 8.2 или 8.3.
Конфигурация. Това е следващото ниво на специфичност. Конфигурациите се записват на платформата с помощта на 1C код. Потребителите работят с конфигурации.
1C Битрикс. Система за работа с уебсайтове, заслужава да се говори отделно.

Друг аспект, в който може да се структурира работата на 1C, е организационното ниво. И тук има 2 части, които също не работят една без друга:

Самата компания 1C и нейният персонал от специалисти.
1C партньори (франчайзинг) и специалисти, участващи в поддръжката на системата. Те също си струва да бъдат подчертани като един от компонентите на екосистемата. Без специалисти, които финализират и внедряват 1C, системата няма да работи. Това могат да бъдат компании партньори на 1C или отделни фрийлансъри, няма значение, те просто трябва да бъдат, в противен случай системата няма да бъде жизнеспособна.

След това предлагам да разгледаме по-отблизо частите на екосистемата 1C.

Платформа

Платформата е самата основа, на която 1C програмистите, използвайки езика за програмиране 1C, пишат готови програми (конфигурации) за потребителите. Платформата е основата, без която нито един компонент или конфигурация няма да работи. В същото време самата платформа без конфигурация може да представлява интерес изключително за 1C програмист; за всички останали (потребители, различни специалисти) тя е безполезна.

Можете да работите на различни версии на платформата. Знам, че на практика се използват версии 8.2 и 8.0, както и доста старата, но все още популярна 7.7, понякога дори се използва първата успешна версия 6.0. Но аз ще говоря изключително за версия 8.3, като най-новата към момента на писане. Много от нещата, които ще обсъдим, са еднакво подходящи за предишни версии. Но някои бяха добавени само в най-новите версии. Бих искал читателите да вземат предвид този факт.

Важно е да се разбере, че потребителите най-често не се нуждаят от пълния набор от възможности, които 1C предоставя. Това твърдение е особено актуално за малкия и среден бизнес. Но качеството и надеждността на работата са изключително важни за потребителите. И в това отношение, за съжаление, възникват доста проблеми със софтуерните продукти 1C.

Когато работят с 1C, програмистите използват специален език за програмиране, създаден от разработчиците на 1C за работа с платформата 1C. Днес той е наличен на руски и английски, но първоначално е бил написан на руски и следователно стандартните конфигурации също са написани традиционно на руски, въпреки че винаги е възможно да се използват английски версии на операторите на правилното място, ако е по-удобно за програмиста да работиш. Този език е смесица от BASIC и C+ с добавяне на SQL за писане на заявки. Освен това предоставя възможност за използване на различни конструктори и добавки.

Една от характеристиките на платформата 1C е липсата на модулност. Платформата е нещо цяло, невъзможно е ясно да се посочи кое парче код (модул) отговаря за какви възможности. Разбира се, по време на инсталацията можете да посочите кои компоненти да бъдат инсталирани и кои не. Но тази опция присъства само по време на инсталацията и всъщност предлага много малък брой опции.

Още една бележка, която се надяваме да помогне за избягване на пламъци и спорове:

Разбирам, че платформата 1C е мощен и много гъвкав инструмент. И ако вие, като опитен 1C програмист, решите да напишете нещо специално върху него, най-вероятно ще получите отличен софтуер. И за различни случаи тук можете да намерите решение именно благодарение на богатството от възможности на платформата. Но най-често срещам използването на стандартни конфигурации (счетоводство, управление на търговията, заплати и човешки ресурси, управление на производството), повечето потребители работят с тях, особено когато става въпрос за малки и средни предприятия. Затова ще пиша за избора на платформа и за някои проблеми, свързани с работата на 1C, главно от гледна точка на работа със стандартни конфигурации.

В същото време разбирам също, че с голямо желание и достатъчно ниво на познания на програмиста много проблеми могат да бъдат решени, но проблемите няма да бъдат от значение. Ето защо, ако използвате някои уникални разработки, проблемите и проблемите, които разкривам, може да не са ви интересни. За всички останали продължавам.

Опции за доставка на платформа

Когато избирате платформа, е много важно да обърнете внимание на опциите за доставка на решение. Първото нещо, което е важно за вас, е методът за организиране на работа с данни:

Файлово решение
Опция клиент-сървър

В решение, базирано на файлове, цялата работна информация ще се съхранява в един общ файл. Няма значение коя конфигурация инсталирате. Във всеки случай ще получите сервизен файл с разширение на CD (вътрешен формат 1C), в който ще се съхранява всичко: директории, документи, регистри и др. Ако броят на потребителите на вашата програма не надвишава 4 души, най-вероятно тази опция е доста подходяща за вас. Освен това настройката на файлова система е много по-лесна, тук дори можете да направите без помощта на специалист 1C. Проблемът със скоростта може да бъде частично решен с помощта на RPD (протокол за отдалечен работен плот), но само частично.

Но за използване на 1C в компании с доста активен документооборот и доста голям брой системни потребители (повече от 4 души), файловата система няма да работи задоволително. Потребителите ще имат достъп до един и същ файл почти едновременно, който постоянно ще се увеличава по обем. Освен това ще са необходими постоянни синхронизации, което още повече ще забави работата.

За да разреши този проблем, компанията 1C се опитва да опита кеширане на данни, но този метод досега носи повече повече проблеми. Ако някой се интересува от тази тема, просто набере търсачка„1C проблеми с кеша“, в търсенето ще има много форуми и дискусии за това с различни проблеми, които в крайна сметка се свеждат до факта, че кеширането не винаги работи правилно.

Организацията клиент-сървър на съхранението на данни е организацията на базите данни в таблици на сървъра. Това може да е MSSQL, Oracle или друга опция за организация на база данни.

Предимствата на тази опция са очевидни: без значение колко потребители имат достъп до базите данни, няма да възникнат проблеми със скоростта и достъпа. Това е опцията, която използват повечето средни фирми и аз обикновено я препоръчвам на клиентите.

В повечето случаи компаниите инсталират Windows сървър, на който се съхранява както самата програма, така и базата данни. Понякога приложенията и базите данни са разделени на различни сървъри, но тези случаи са сложни и доста редки и затова няма да се спирам на тях.

Версии на 1C за различни платформи

Днес можете да изберете различни версии софтуер 1C за работа на различни платформи. Тук също си струва да разберете какво си струва да купите в какъв случай.

И така, има версии на 1C:

за Windows,
за Linux.

Към момента на писане не е разработена версия за Mac OS.

Програмата 1C, която работи под Windows, е разработена от самото начало, това е мощен инструмент, познат на всички, който е достатъчно усъвършенстван, за да го използва без никакви проблеми. Версията на Linux днес се счита за все още нова и следователно доста „сурова“; все още има много грешки, както във всеки нов софтуерен продукт.

Предприемачите и всички представители на бизнеса са доста консервативни хора, най-важното за тях е стабилната, надеждна работа. Най-често бизнесът не се интересува толкова от висока скорост или огромен списък от възможности, колкото просто изисква стабилна работа. Освен това днес Linux не е много търсен в домашния бизнес. Следователно тази версия се среща много рядко.

Компонентна база 1C

Базата от компоненти на 1C е много обширна, съдържа огромен брой възможности, докато 1C непрекъснато се разделя и добавя функции. Тези. когато разработчиците на 1C трябва да създадат нещо ново, те почти винаги създават новият видобект. Например, когато бяха необходими уеб услуги, разработчиците не създадоха някакъв вид плъгин, а просто въведоха концепцията: уеб услуга. По същия начин за много бизнес процеси в 1C компания най-често се създава нов компонент, дори в случаите, когато съществуващият може просто да бъде модифициран.

Какво можем да кажем за компонентите на платформата 1C:

Някои компоненти работят отдавна, някои от създаването на софтуерния продукт. Те са стабилни и надеждни.
Някои компоненти са добавени наскоро, други се добавят в момента. Повечето от тях са много слабо тествани и затова трябва да работите с тях изключително внимателно.

Когато избирате компонент, с който да работите, винаги трябва да обръщате внимание кога е добавен. Професионалните 1C програмисти имат следното правило: когато разработчиците добавят нова функция, ако е възможно, избягвайте я, докато не изтече достатъчно време. Тези. те изчакват, докато компонентът бъде тестван на практика, основните „бъгове“ са идентифицирани и коригирани и едва тогава започват активна работа с него.

Един от компонентите на отрицателната репутация на 1C е практиката на компанията постоянно да добавя нови, непроверени решения. Въпреки факта, че често вече внедрените компоненти работят зле, грешките все още не са коригирани и разработчиците вече добавят нещо ново. Това може да са не само компоненти, но и нови функции за съществуващи съоръжения, нови методи и др. Всички програмисти, които работят с 1C, ще се сблъскат с този проблем - постоянното присъствие на „суров“ софтуер, постоянни „бъгове“ и техните постоянни корекции.

Потребителите също могат да се сблъскат с този проблем - грешки и нестабилна работа на софтуера при работа с платформата. Има определен набор от функции за поддръжка на 1C, които потребителят може да изпълнява. За тази цел има потребителски интерфейс на платформата. И тук си струва да се върнем към различните версии на потребителския интерфейс.

Платформата 1C се състои от много различни компоненти, които непрекъснато се добавят, разширявайки възможностите на този продукт. Освен документи, справочници, различни регистри има и различни компоненти за въвеждане/извеждане на информация, т.е. потребителски интерфейси.

Въз основа на тази функция можете да изберете:

Роден 1C клиент. Това е традиционен софтуерен интерфейс, когато 1C е достъпен от 1C.
Работете през браузър.
Работа чрез мобилно приложение.

Всяка от опциите има някои ограничения, можете да прочетете повече за тях на официалния уебсайт на 1C.

Роден клиент

Родният клиент също е разделен на поредица от подклиенти, което внася допълнителен хаос в процеса на избор на софтуер. Най-важното тук е да изберете опция за „дебел“ или „тънък“ клиент. На пръв поглед изборът тук не е критичен, особено за програмист. Всъщност, когато работите с конфигурацията през интерфейса, могат да възникнат проблеми поради грешки при избора.

Каква е разликата между тези подклиенти?

„Дебелият“ изисква широк (дебел) комуникационен канал, „тънкият“ се нуждае от минимум. По-голямата част от моите клиенти използват „дебел“ клиент, тъй като сега всеки има добри локални или интернет канали и няма проблеми с тяхната „широчина“. От друга страна, „тънкият“ клиент има определени ограничения в работата си, има неща, които не могат да се правят в него.

Уеб клиент (работа през браузър)

Уеб клиентът е работа с програмата 1C през браузър. Тези. използвате определена технология, която ви позволява да осъществявате достъп до базата данни през интернет, използвайки удобен за вас браузър. В този случай интерфейсът е напълно очертан директно в браузъра.

Тази опция налага определени ограничения, трябва постоянно да помните това. От друга страна, работата с уеб клиента е доста стабилна, добре дебъгвана и доведена до определен логичен завършек. Ето защо доста хора използват тази опция за интерфейс. Работата с 1C онлайн може да бъде много удобна и дори необходима.

мобилна версия

Тази версия на клиента от 1C се появи сравнително наскоро и все още не е в голямо търсене. Причини за това отношение:

Клиентът се оказа много труден. За да настроите тази програма, човек трябва да познава както 1C, така и мобилните технологии и доста дълбоко на ниво код. Ясно е, че намирането на такъв специалист е доста трудно, което не допринася за популярността на софтуерното решение.
Технологията все още е много „сурова“ и лошо отстранена. Аз лично се опитах да използвам това решение за моите клиенти, разговарях с колеги, които също се запознаха с тази технология, и в момента моето мнение и мнението на моите колеги съвпадат: по-лесно и по-удобно е да създадете някакво мобилно приложение, отколкото да използвате опцията от 1C.

Мобилната версия трябва да съчетава много неща, изисква работата на няколко специалиста, които да работят заедно и да си помагат:

Настройка на достъп до базата данни отвън;
Решаване на проблеми със сигурността;
Настройка на сървър за работа мобилни приложения;
Настройка на софтуерни продукти 1C;
Настройка на уеб приложения (ако е необходимо).

Всичко това е необходимо, за да се гарантира правилната работа на мобилното приложение 1C. Ясно е, че събирането на такъв екип от специалисти е трудно и скъпо и затова това решение не е популярно в малкия и среден бизнес.

Платформа 1C: резюме

Платформата 1C е много функционална, има огромен списък от различни възможности. И това количество естествено се превръща в сложност. В резултат на това бариерата за влизане в работата с 1C за програмист е много висока. Клиентите чуват за различни възможности на 1C и молят програмист да им помогне да ги внедрят. Това означава, че специалистът трябва постоянно да е наясно с актуализациите, да разбира и знае различни неща.

Много е трудно да се намери програмист, който да разбира всичко на програмно ниво наведнъж: работа с 1C, уеб програмиране, работа с мобилни приложения и т.н. Това е възможно на концептуално ниво, т.е. на този, в който сега споделям знанията си.

Но клиентите обикновено не разбират това и започват да изискват от програмиста 1C да внедри различни възможности.

От друга страна, платформата 1C непрекъснато се променя, има огромен брой опции, много различни решения и в резултат на това - огромен брой грешки и техните корекции.

Всичко това заедно води до проблем с позиционирането:

От една страна е компанията 1C, която казва на клиентите, че 1C е проста и удобна. Те не пишат никъде, че поддържането на 1C ще изисква специалист със специални познания, че за програмистите е трудно да работят с модерния 1C.
От друга страна, в действителност клиентът се сблъсква с всички тези проблеми. И е добре, ако получи помощ или от добре работещ екип, участващ в внедряването на 1C, или от бизнес консултант с моето ниво на познания, който може да намери правилните специалисти и да им възложи правилните задачи. В други случаи потребителят ще се сблъска с много проблеми по време на процеса на внедряване.

И така, накратко за платформата 1C: огромен брой възможности, висока степен на гъвкавост, много различни решения. И в същото време: ниско качество на изпълнение, постоянно нарастваща сложност на решението, огромен брой грешки във всяка версия.

На концептуално ниво мисля, че има достатъчно информация. И винаги можете да намерите технически нюанси на ресурсите на 1C, които препоръчах по-горе.

Конфигурации

1C конфигурациите са готови софтуерни решения, които се създават на базата на конкретна версия на платформата. Конфигурацията е това, с което потребителите директно работят, софтуерната среда, в която поддържат текущи записи, работят с документооборот, директории и т.н. Потребителите често може да не знаят каква платформа имат. Но те винаги знаят каква конкретна конфигурация се използва.

Има конфигурации:

Стандартен - написан от 1C компания. Всички те присъстват на уебсайта на 1C.
Нетипични – написани от партньорски компании.

На потребителско ниво двата типа се разграничават, както следва:

Стандартните конфигурации се създават и поддържат от 1C. В повечето случаи те са с по-високо качество, в тези конфигурации работата с код е по-добре организирана и се използват най-често оптимални решения, грешките се коригират своевременно. Разбира се, всеки постоянно чува за „вечни грешки“ в типичните конфигурации на 1C и те наистина присъстват постоянно там, но все пак си струва да се отдаде кредит на специалистите на компанията. Те коригират критични грешки много бързо.
Нетипичните конфигурации са написани от партньорски компании на 1C и е доста трудно да се каже нещо определено тук. Такива конфигурации са много различни. Най-често те се пишат по повод: специфични за индустрията (за конкретна индустрия) или написани за конкретен повод (конкретна компания). И тук е необходимо да се разбере, че партньорските компании на 1C в по-голямата си част имат доста голямо текучество на персонала. И следователно конфигурациите в тях са написани по доста неорганизиран начин. Един програмист започва да пише, друг продължава, а трети завършва. В същото време всеки от тях носи нещо свое, свои разбирания, решения, идеи. И прилага разработките на своя предшественик както му е удобно, а не както е замислено.

Може би си спомняте забавния анимационен филм „Трима от Простоквашино“? Там момчето чичо Фьодор написал писмо до родителите си, но не го довършил, разсеял се и приятелите му се редували да го довършват вместо него: котка и куче. И всеки от тях разказа за своите проблеми. В резултат на това родителите на момчето бяха изненадани да разберат, че „лапите го болят и опашката му пада“. Това е принципът, използван за писане на нестандартни конфигурации много често.
Липсата на приемственост в писането на нестандартни конфигурации, а често и липсата на достатъчно подробна документация, води до факта, че за всички въпроси по внедряване и модификации ще трябва да се свържете с фирмата, разработила тази конфигурация.

Нестандартните конфигурации също се предлагат в два типа:

Написани на базата на стандартни. Тези конфигурации се създават чрез добавяне на функционалност към някои стандартни. Например, има такъв продукт като 1C: Управление на търговията и CRM. Тук съчетахме стандартната конфигурация на Trade Management и CRM системата. Интересно е, че създателите на конфигурацията, компанията Rarus, наричат подсистемата за управление на търговията, въпреки че всъщност това е основата, на която е написана цялата конфигурация.
    професионалиститакива конфигурации - те са по-функционални в сравнение със стандартните, често към тях се добавят много необходими функции.
    минуси– разработчиците на тези конфигурации често нямат време да създадат своите актуализации навреме. По този начин може да се окаже, че компанията 1C вече е публикувала своите опции за актуализация и потребителят на нестандартно решение ще трябва да изчака известно време, докато разработчикът създаде подобна актуализация за конкретно решение. В допълнение, такива модификации също могат да бъдат доста „сурови“ и могат да съдържат много грешки.
Конфигурации, написани от нулата. При създаването им изобщо не се използват стандартни конфигурации, решенията се пишат за конкретни задачи.
професионалисти: конфигурацията е написана точно според нуждите на клиента, има всичко необходимо и почти нищо излишно.
минуси: Обикновено при писането на такива решения не се спазват стандартите за код, много е трудно да се променят такива софтуерни продукти; най-често само авторът може да направи това достатъчно бързо.

Ако дойда при клиенти и видя, че има нетипична конфигурация, написана от нулата, се опитвам или да не я докосвам изобщо, или напълно да я променя на удобно и универсално решение. Доста често такива решения всъщност не са необходими, особено в малкия и среден бизнес. В същото време стандартните продукти са по-лесни за поддръжка и съответно по-евтини, което винаги е важно за бизнеса.

Резюме

Важно е да се разбере, че предприемачите обикновено търсят конфигурация. Например, за да автоматизират работата на счетоводния отдел, те се нуждаят от 1C.Accounting, а за организиране на работа с клиенти - 1C. Управление на търговията. Именно тези продукти са разбираеми за тях и следователно интересни.

Затова е важно програмистът да знае с коя платформа ще трябва да работи. Потребителят се интересува от конфигурацията. В същото време, без помощта на 1C програмист, бизнесът в повечето случаи няма да може да настрои желаната конфигурация. Ето защо наричам специалистите на 1C неразделна част от екосистемата на 1C.

Позволете ми да ви напомня, че специалистите на 1C също са различни. Някои се занимават с разработването на платформата и стандартните конфигурации (служители на компанията 1C), други са нейни партньори и участват в внедряването и модификациите, докато трети частно помагат за решаването на определени проблеми, свързани с внедряването на 1C. Добави тагове

Категории

Избор на редакторите

Точка във времето и граница, предназначение, примери за употреба. Автоматично и контролирано блокиране

Разлики между 1C UPP и 1C Accounting

Начини за излизане от тази ситуация

И така, два метода за контролиране на баланси в 1C:Enterprise 8.3

Каква е разликата?

Относно бързата обработка на документи

Контрол на салда по нов метод - без блокиране

1. Инициализиране на мениджъра на временни таблици

2. Заявка за групиране на таблични данни

4. Записване на движенията в базата данни

5. Запитване за получаване на отрицателни салда

6. Определяне на момента във времето за контрол на остатъчните вещества

7. Ако заявката не е празна, това означава, че са формирани отрицателни салда

8. Ако има грешки, върнете се от манипулатора на събития

Изпълнение на отписване на разходи по партиди

I. Анализ на изместването на датата на документа напред

II. Подготовка на набори от записи за регистър „Стойност на стоките”.

III. Заявка, която получава партидни салда за отписване с помощта на FIFO

IV. Цикъл по документна номенклатура

V. Вземете сумата за отписване

VI. Партиден цикъл по FIFO

VII. Проверете за нулев баланс

VIII. Изчисляване на количеството и сумата за отписване

IX. Ще намалим сумата за отписване

Защо са необходими управлявани ключалки?

Кога трябва да се приложи блокирането?

Автоматично и контролирано блокиране

Контролирани ключалки в новата технология за контрол на остатъците

Стар метод за контрол на остатъците

Няколко думи за моя опит с 1C

Малко повече за 1C и защо пиша всичко това

1C като екосистема

Платформа

Опции за доставка на платформа

Версии на 1C за различни платформи

Компонентна база 1C

Роден клиент

Уеб клиент (работа през браузър)

мобилна версия

Платформа 1C: резюме

Конфигурации

Резюме

Търсене

Абонамент

Популярни публикации

Последните бележки