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

e-mail: Този имейл адрес е защитен от спам ботове. Трябва да имате пусната JavaScript поддръжка, за да го видите.

SelMatic ERP 2017.06

Драйвер за касови апарати DAISY DPrint

Реализиран е драйвер за осъществяване на комуникация на SelMatic ERP с касови апарати Daisy DPrint.

Нова възможност на изгледа на документите (грида) за обединение на групирани колони

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

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

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

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

Подобрения в Експорта към Eксел

Разширена е функционалността за Експорт на данни от справки към Ексел, като новият експорт дава възможност за последващ анализ върху данните в Microsoft Excel.

Приложените върху данните възможности на грида в системата се запазват в изходните XLSX документи - например:

  • Групиране на данни
  • Суми и групови обобщения
  • Правила за форматиране стила на Excel
  • Фиксирани колони

За използване на новата възможност в системата се изпълнява стандартния Експорт към Ексел, като опцията за формата при запис на екселския файл е "Ексел файлове за анализ (*.xlsx)".

Възможност за HTML редакция на Описания на Позиция

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

За да може да се направи това, за Описанията са реализирани допълнителни възможности за редакция на текст в HTML формат.

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

Нов вид Стойностен баланс

При двустъпков процес по получаване на стока (напр. Приемане на стока в склада и Фактура за доставка) е необходимо да има верни средни доставни цени (СДЦ) и себестойност на ниво фирма/обект, за да има коректно ценообразуване и справки за печалба, но и в същото време да може да се приема стока в склада, дори и без да има фактура за нея.

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

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

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

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

За да стане възможно създаването на документ за изравняване на стойностите, на основата на „Базовия скрипт за копиране на ФД от ТД“ е направен нов вид копиращ скрипт, в който са добавени следните параметри:

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

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

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

Разпознаване на Срок на годност от баркод, чрез маска

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

За покриването на този начин на работа е добавена възможност, в маските на баркодове, да може да се разпознава и попълва „Срока на годност“. Целта е при сканиране на баркод, съдържащ информация за „Срок на годност“, същият да се попълни в търговския документ, в таблица "Серийни/партидни номера".

Разпознаване на Дати в Маските на баркодове и Серийни/Партидни номера

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

Тъй като самият стандарт дефинира доста много опции са реализирани само тези, които до момента намират приложение:

  • Дата на пакетиране
  • Най-добър до
  • За продажба до
  • Срок на плащане
  • Дата на производство
  • Срок на годност

Изброените дати може да се разпознават от маските на баркодовете като всяка дата може да има собствена маска.

Попълването на тези полета става при: сканиране на баркод в ТД; ръчно писане в ТД; протокола за Атрибути на сериен/партиден номер.

Поле Баркод на контрагента в таблицата със Специфичните кодове на контрагенти към Позиции

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

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

Възможност за автоматичен Прием на стока в Митнически склад. Справка Наличност и стойност Митнически склад

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

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

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

При работа с Митнически склад е необходимо във всеки един момент да се знае какви са наличността и стойността в него.

За проследяването на тези данни е разработена подходящата справка, в която директно да се попълват количествата необходими за изнасяне от склада (съобразено е да не се допуска изнасяне на по-голямо от наличното количество). За редовете, за които е попълнено количество за изнасяне, лесно чрез бутон могат да се генерират документи за Изнасяне и ВСО в Митническия склад.

Печат на банкови сметки върху подложка за фактура – ново поле Подредба в "Каси и банкови сметки"

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

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

При работа с Хипермаркети възможност за задаване на Доставни единици на ниво Позиция и Специфична мерна единица на ниво Контрагент

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

За да се улесни обработването на клиентски заявки, когато има разлика между Доставните единици (ДЕ) на Клиента и Продажните единици (ПЕ) на Доставчика са създадени взаимовръзки на база коефициент при пресмятането на количества спрямо ДЕ и ПЕ. Това ще позволи стандартният EDI интерфейс да създава автоматично ТД Заявка от клиент, с попълнени коректни (от гледна точка на Продавача) Продажни единици, изчислени чрез умножение/деление на количеството от заявката по коефициента. Същевременно в подложките за печат също ще могат да се отпечатват както Продажните единици, така и Доставните единици.

В номенклатура Контрагенти е добавено поле за лого/снимка на Контрагента

В практиката е удобно при многофирмен режим на работа при създаване на подложки да има поле, в което да се съхраняват логотата на Контрагентите и при избор на конкретен Собственик например да се зарежда неговото лого. Удобно би било същото поле да се използва и за снимки на клиенти за клиентски карти, на служители за служебни карти и други.

За целта по подобие на мини изображенията на Позициите и за Контрагентите е добавено поле за Снимка/лого, в което може да се зарежда снимка от файл, да се копира, изтрива, да се записва под друго име.

Спиди интерфейс – възможност за изпращане на пратки от много обекти с един акаунт

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

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

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

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

 

Формата за Избор на серийни/партидни номера вече е съобразена с резервираното количество

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

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

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

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

В Ревизия: възможност за повторно броене на позициите, които имат разлики

Стандартно след като се направи Моментната снимка в Ревизия и всички възможни артикули са вече преброени, включително и в Окончателно броене (ако Ревизията е с две комисии), програмата изчислява автоматично кои артикули имат разлика между преброеното и наличното.

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

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

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

Скрипт за добавяне на връзка „Към фактура“ в Кредитно известие, относно Фактури, генерирани извън ERP системата

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

За целта е реализиран скрипт, който да се стартира от бутон в ТД за кредитно известие по продажба. След попълване на „Номер и Дата на фактура“ същите се записват в таблицата „КЪМ фактури“. Добавена е проверка скриптът да не може да се изпълнява в/у приключени и анулирани документи.

Възможност за замразяване на бандовете в динамични справки

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

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

Автоматично зареждане на Цена от посочена Ценова листа

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

За тази цел е създаден скрипт за зареждане на цена от произволна ценова листа с възможност за попълване на "Единична цена преди търговска отстъпка (без ДДС)" или "Единична цена след търговска отстъпка (без ДДС)". Цените се зареждат за всички редове с позиции, за които има цена в избраната ценова листа.

При запис на цената в "Ед. цена преди ТО" , ако има отстъпка тя се запазва, а се променя "Ед. цена след ТО". Като Ценова листа на ниво ред на документа се поставя тази, от която се изтегля новата цена.

При запис на цената в "Ед. цена след ТО" "Ед. цена преди ТО" не се променя, а се пресмята отстъпката на база заредената цена след отстъпката. В този случай Ценовата листа на реда в ТД не се променя. Ценовата листа, от която се изтегля цената се записва в едно от числовите потребителски полета на реда, посочено в съответния параметър в скрипта.

Автоматично превалутиране на търговски документ

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

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

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

Възможност на грида за обединение на групирани колони

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

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

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

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

Google+