На интернет страни еФактура објављена су следећа документа:

• СЕФ нова верзија 3.8
• Ажурирано интерно техничко упутство – верзија од 1. августа 2024.

У наставку је дат преглед свих функционалности и промена које су део нове верзије 3.8 СЕФ:

1. Измена назива типова докумената

На корисничком интерфејсу и спољном приказу електронске фактуре (ПДФ) преименовани су следећи називи типова докумената:

• „Авансни рачун“ је преименован у „Авансна фактура”
• „Књижно одобрење“ је преименовано у „Документ о смањењу”
• „Књижно задужење“ је преименовано у „Документ о повећању”

2. Измене у секцији „Датум обрачуна ПДВ-а“

На корисничком интерфејсу назив секције „Датум обрачуна ПДВ-а“ мења се у „Настанак ПДВ обавезе“.

Због измена у секцији „Датум обрачуна ПДВ-а” неопходна је измена Спецификације прилагођене примене стандарда EN 16931-1 за електронске фактуре у унутрашњем промету у Републици Србији, тако што ће за идентификатор термина BT-8 Шифра датума пореске обавезе кардиналност бити 0..1. Измена спецификације прилагођене примене стандарда EN 16931-1 је неопходна због увођења нове опције – „Не настаје обавеза обрачуна ПДВ”, за тип документа фактура, авансна фактура и документ и повећању.

Наведена измена приказана је на страници 144 Интерног техничког упутства.

Измене за тип документа – Фактура

На корисничком интерфејсу, у секцији „Настанак ПДВ обавезе“, у падајућем менију корисник има следеће опције за одабир:

• „Датум промета“ – Дан настанка ПДВ обавезе је датум промета
• „Члан 16. тачка 2а) ЗПДВ“ – Дан настанка ПДВ обавезе је датум издавања рачуна у складу са чланом 16. тачка 2а) ЗПДВ.
• „Члан 36а ЗПДВ“ – Дан настанка ПДВ обавезе је датум наплате, односно други датум у складу са чланом 36а ЗПДВ.
• „Не настаје обавеза обрачуна ПДВ” – За издаваоце фактуре не настаје обавеза обрачуна ПДВ (нпр.реч је о промету за који издавалац није порески дужник, промету за који је прописано пореско ослобођење и др.). Ова опција је нова.

Преко апликативног интерфејса, АПИ корисници уносе датуме настанка ПДВ обавезе на следећи начин:

• За „Датум промета” као идентификатор термина у основном семантичком моделу користи се BT-72 Actual delivery date, односно шифра датума пореске обавезе је 35.
• За „Члан 16. тачка 2а) ЗПДВ” као идентификатор термина у основном семантичком моделу користи се BT-2 Invoice issue date, односно шифра датума пореске обавезе је 3.
• За „Члан 36а ЗПДВ” као идентификатор термина у основном семантичком моделу користи се BT-9 Payment due date, односно шифра датума пореске обавезе је 432.
• За „Не настаје обавеза обрачуна ПДВ” не користи се ни један идентификатор термина за датум настанка ПДВ обавезе из основног семантичког модела, па самим тим предвиђени таг /cac:InvoicePeriod/cbc:DescriptionCode не треба проследити.

Измене за тип документа – Авансна фактура

На корисничком интерфејсу, у секцији „Настанак ПДВ обавезе”, у падајућем менију корисник има следеће опције за одабир:

• „Датум аванса” – Дан настанка ПДВ обавезе је датум наплате аванса. Ова опција одговара досадашњој опцији „ПДВ се обрачунава на дан плаћања”, тако да је само урађено преименовање на корисничком интерфејсу. „Не настаје обавеза обрачуна ПДВ” – За издаваоца авансне фактуре не настаје обавеза обрачуна ПДВ по основу наплате аванса (нпр. реч је о авансу за промет за који издавалац није порески дужник, авансу за промет за који је прописано пореско ослобођење и др.). Ова опција је нова.

Преко апликативног интерфејса, АПИ корисници уносе датуме настанка ПДВ обавезе на следећи начин:

• За „Датум аванса” као идентификатор термина у основном семантичком моделу користи се BT-9 Payment due date, односно шифра датума пореске обавезе је 432.
• За „Не настаје обавеза обрачуна ПДВ” не користи се ни један идентификатор термина за датум настанка ПДВ обавезе из основног семантичког модела, па самим тим предвиђени таг /cac:InvoicePeriod/cbc:DescriptionCode не треба проследити.

Измене за тип документа – Документ о повећању

На корисничком интерфејсу, у секцији „Настанак ПДВ обавезе“, у падајућем менију корисник има следеће опције за одабир:

• „Датум издавања – зарачунавање трошкова” – Дан настанка/повећања ПДВ обавезе је датум издавања документа о повећању којим се зарачунавају трошкови, а на основу којег долази до повећања основице за промет. Ова опција одговара садашњој опцији „Датум слања фактуре”, тако да је само урађено преименовање на корисничком интерфејсу. „Датум повећања – уговор” – Дан настанка/повећања ПДВ обавезе је датум када је у складу са уговором дошло до повећања основице за промет – нова опција.
• „Не настаје обавеза обрачуна ПДВ” – За издаваоца документа о повећању не настаје обавеза обрачуна ПДВ (нпр. реч је о документу о повећању за промет за који издавалац није порески дужник, документ о повећању за промет за који је прописано пореско ослобођење и др.) – нова опција.
• Одабиром опције „Датум повећања – уговор” потребно је да корисник у календару изабере конкретан датум. Уколико корисник одабере неку од друге две опције, календар за одабир датума повећања – уговор, неће бити доступан.

Преко апликативног интерфејса, АПИ корисници уносе датуме настанка ПДВ обавезе на следећи начин:

• За „Датум издавања – зарачунавање трошкова” као идентификатор термина у основном семантичком моделу користи се BT-2 Invoice issue date, односно шифра датума пореске обавезе је 3.
• За „Датум повећања – уговор” као идентификатор термина у основном семантичком моделу користи се BT-72 Actual delivery date, односно шифра датума пореске обавезе је 35.
• За „Не настаје обавеза обрачуна ПДВ” не користи се ни један идентификатор термина за датум настанка ПДВ обавезе из основног семантичког модела, па самим тим предвиђени таг /cac:InvoicePeriod/cbc:DescriptionCode не треба проследити.

Тип документа – Документ о смањењу не садржи секцију „Настанак ПДВ обавезе“ на корисничком интерфејсу.

Преко апликативног интерфејса, АПИ корисници имају две опције:

• не користити ни један идентификатор термина за датум настанка ПДВ обавезе из основног семантичког модела, па самим тим предвиђени таг /cac:InvoicePeriod/cbc:DescriptionCode не треба проследити
• у оквиру предвиђеног тага /cac:InvoicePeriod/cbc:DescriptionCode, као шифру датума пореске обавезе уносити „0“ (нула), као и до сада.

3. Генерисање проширеног спољног приказа електронске фактуре (ПДФ) на захтев корисника

Омогућено је преузимање проширеног спољног приказа електронске фактуре (ПДФ) на захтев корисника. Преузимање преко корисничког интерфејса омогућено је на детаљном приказу електронске фактуре. Преузимање преко јавних АПИ метода омогућено је преко следећих метода:

• publicApi/purchase-invoice/pdf
• publicApi/sales-invoice/pdf

Приликом преузимања проширеног спољног приказа електронске фактуре (ПДФ), систем електронских фактура (СЕФ) проверава да ли је документ већ генерисан. Уколико јесте, документ се одмах преузима и приказује кориснику. Уколико документ није генерисан, систем покреће поступак генерисања и враћа статус „202 – Accepted“ кориснику. Када документ буде успешно генерисан, систем га чува у систему датотека за преузимање.

Генерисање спољног приказа електронске фактуре (ПДФ) на корисничком интерфејсу

На корисничком интерфејсу, опција „Преузми ПДФ“ је преименована у „Преузми ПДФ сажетак“, за преузимање основног (сажетог) спољног приказа електонске фактуре (ПДФ).

За преузимање проширеног спољног приказа електронске фактуре (ПДФ) додата је опција „Преузми ПДФ“.

Уколико креирани документ на корисничком интерфејсу има прилоге, у оквиру опције „Преузми све” иницираће се преузимање ZIP датотеке, која садржи све прилоге и основни (сажети) спољни приказ електронске фактуре (ПДФ). Уколико је за електронску фактуру већ креиран проширени спољни приказ (ПДФ) и он ће бити део ZIP датотеке.

Генерисање спољног приказа електронске фактуре (ПДФ) преко јавних АПИ метода

За кориснике апликативног интерфејса спољни приказ електронске фактуре (ПДФ) ће се генерисати одложено, уколико већ није генерисан.

Уколико проширени спољни приказ електронске фактуре (ПДФ) није већ генерисан, покреће се генерисање спољног приказа електронске фактуре, а кориснику се враћа статус „202 – Accepted” уз следећу поруку:

{

„message“: „Extended PDF file creation has been initiated for invoice Id XXXXXX.“

}

Корисник мора поновити исти захтев, након чега ће добити генерисани документ.

Уколико је проширени спољни приказ електронске фактуре (ПДФ) већ генерисан, кориснику се одмах враћа спољни приказ електронске фактуре (ПДФ).

Преузимање постојећег или генерисање новог проширеног приказа спољног приказа излазног документа могуће је преко јавне АПИ методе /api/publicApi/sales-invoice/pdf.

Преузимање постојећег или генерисање новог проширеног приказа спољног приказа улазног документа могуће је преко јавне АПИ методе /api/publicApi/purchase-invoice/pdf.

Наведена измена приказана је на страницама 81, 135 и 155 Интерног техничког упутства.

4. Имплементиране су нове јединице мере на корисничком интерфејсу

У складу са утврђеним потребама крајњих корисника, имплементиране су следеће јединице мере на корисничком интерфејсу:

Нове јединице мере имплементиране су и у делу „Подешавања”

5. Имплементирана је могућност уноса броја отпремнице на корисничком интерфејсу

На страници „Продаја” имплементирана је могућност уноса броја отпремнице приликом креирања фактуре на корисничком интерфејсу, као и приказ броја отпремнице на корисничком интфејсу а који је унет и отпремљен путем XML датотеке.

Могућност уноса броја отпремнице на корисничком интерфејсу је имплементирана само за тип документа – фактура. На једној фактури омогућен је унос једног броја или више бројева отпремнице. Уколико је број отпремнице наведен, биће видљив и на спољном приказу фактуре (ПДФ).

Према спецификацији прилагођене примене стандарда EN 16931-1 за електронске фактуре у унутрашњем промету у Републици Србији, као идентификатор термина у основном семантичком моделу користи се BT-16 Despatch advice reference/референца отпремнице

Наведена измена приказана је на страници 141 Интерног техничког упутства.

6. Измена назива статуса „Одобрено“ у „Прихваћено“

На корисничком интерфејсу статус „Одобрено” је применован у „Прихваћено”. Измена је резултирала промену на свим местима где је видљив статус „Одобрено“:

– на табеларном приказу излазних и улазних докумената у колони „Статус”

– на табеларном приказу излазних и улазних докумената у делу филтера за опцију „Сви статуси”

– на детаљном приказу излазних и улазних докумената

– на детаљном приказу излазних и улазних докумената у кроз опцију „Историја” приликом прегледа свих системских измена на електронској фактури.

7. Приказивање информације да је електронска фактура „Аутоматски прихваћена”, „Аутоматски одбијена”, „Прималац прихватио” или „Прималац одбио”

На корисничком интерфејсу, на излазним документима на страници „Продаја”, као и на улазним документима на страницама „Набавке” и „Приказ фактура носиоца јавних набавки“ омогућен је приказ информација о начину прихватања, односно одбијања електронске фактуре.

У систему је имплементирана ознака која означава да је промена статуса резултат аутоматске обраде електонске фактуре, па ће тада бити приказане информације „Аутоматски прихваћена” или „Аутоматски одбијена”. У случају недостатка ознаке, промена статуса је резултат мануелне обраде, па ће тада бити приказане информације „Прималац прихватио” или „Прималац одбио”.

Приказ информације код аутоматски прихваћеног документа

Приказ информације код мануелно прихваћеног документа

Приказ информације код аутоматски одбијеног документа

Приказ информације код мануелно одбијеног документа

Информације о аутоматском или мануелном прихватању, односно аутоматском или мануелном одбијању електронске фактуре су омогућене и приликом преузимања промене статуса преко јавних АПИ метода, као и приликом пријема нотификација о улазним и излазним документима. Имплементирано поље IsAutoAssigned сигнализира да ли се десила аутоматска промена статуса. Ознака IsAutoAssigned је додата у SaleslnvoiceStatusChangeDto i PurchaselnvoiceStatusChangeDto.

{

„Eventld“: 390741,

„Date“: „2024-07-18T21:55:41.7097060Z“,

„NewInvoiceStatus“: „Rejected“,

„SalesInvoiceId“: 179995,

„Comment“: „Automatski odbijeno“,

„CirInvoiceId“: null,

„SubscriptionKey“: null,

„StornoNumber“: null,

„CirAssignmentChange“: null,

„IsSigned“: false,

„IsAutoAssigned“: true

}

{

„Eventld“: 390479,

„Date“: „2024-07-18T01:20:03.1366204Z“,

„NewInvoiceStatus“: „Approved“,

„SalesInvoiceId“: 177928,

„Comment“: „Automatski odobreno“,

„CirInvoiceId“: „7B9WC“,

„SubscriptionKey“: null,

„StornoNumber“: null,

„CirAssignmentChange“: null,

„IsSigned“: false,

„IsAutoAssigned“: true

}

Приказ информације „Прималац прихватио” ће бити видљив и уколико се електронска фактура аутоматски одбије, а затим је корисник ручно одобри.

8. Извршавање претраге филтрираног параметра на корисничком интерфејсу притиском на тастер „Ентер”

При филтрирању параметара за претрагу на корисничком интерфејсу, притиском на тастер „Ентер“ може се покренути извршење претраге. Ова могућност је имплементирана на страницама „Продаја”, „Набавке” и „Приказ фактура носиоца јавних набавки”.

9. Постављање количине на -1 приликом уноса авансне фактуре са пореском категоријом „N“

На корисничком интерфејсу, када се као тип документа унесе авансна фактура и одабере пореска категорија N, количина је аутоматски постављена на -1, без могућности измене.

Преко апликативног интерфејса, када се као тип документа унесе авансна фактура и одабере пореска категорија N, омогућено је слање XML датотеке са наведеном количином -1. У случају да се не наведе количина -1, вратиће се следећа грешка:

{

„Message“: „Quantity on invoice lines for N vat category of prepayment must be -1“,

„FieldName“: „InvoiceLine.InvoicedQuantity“,

„ErrorCode“: „UBLPrepaymentInvoiceLineQuantityNotValid“

}

10. Репозиционирање ТЕСТ логоа на демо окружењу

На демо окружењу ТЕСТ лого је премештен на позицију која не омета кориснике у раду и истовремено је довољно приметан.

11. Исправке

1) На корисничком интерфејсу, за све типове докумената исправљена је грешка која је омогућавала преклапање прозора при отварању коментара, прилога и историје. Сада се прозор аутоматски затвори када се отвори следећи.

2) На корисничком интерфејсу, исправљена је грешка која је омогућавала да падајући мени компаније остаје отворен након одабира опције „Детаљи исправки” из истог менија.

3) На корисничком интерфејсу, у делу за унос умањења на нивоу ставке, омогућен је унос износа основице за умањење који је већи од 0,00 РСД и мањи од 1,00 РСД.

4) На корисничком интерфејсу, у делу за унос умањења на нивоу ставке, исправљена је грешка која је омогућавала да се унесе и сачува само износ основице за умањење без попуњавања процента умањења.

5) На корисничком интерфејсу, у делу Подешавања-Детаљи компаније, омогућена је мануелна промена назива компаније.

6) На корисничком интерфејсу, у табеларном приказу Појединачних евиденција ПДВ, исправљена је грешка која је спречавала приказивање две децималне нуле у пољу „ПДВ”, када је унет заокружен износ без децимала у поље „Укупно обрачунати ПДВ” приликом креирања нове Појединачне евиденције ПДВ. Грешка је такође исправљена и када се појединачна евиденција ПДВ шаље преко апликативног интерфејса.

7) На корисничком интерфејсу, проширено је ограничење броја карактера за унос броја авансне фактуре при креирању коначне фактуре – могуће је унети до 50 карактера.

8) Исправљена је грешка која је онемогућавала приказ Појединачне евиденције ПДВ или Збирне евиденције ПДВ, на табеларном приказу за исти дан, уколико је Појединачна евиденција ПДВ или Збирна евиденција ПДВ унета након 22.00 часа. Грешка је исправљена било да је Појединачна евиденција ПДВ или Збирна евиденција ПДВ унета преко корисничког интерфејса, било преко апликативног интерфејса.

9) Приликом креирања електронске фактуре на корисничком интерфејсу, уколико се унесе па накнадно избрише датум промета, исправљена је порука грешке тако што сада гласи „Молимо попуните тражена поља”, уместо „Непозната грешка се десила. Молимо вас да покушате поново”.

10) Уколико документ који је креиран на корисничком интерфејсу има прилоге, у XML датотеци таквог документа за сваки прилог је додат атрибут имена датотеке у EmbddedDocumentBinaryObject елементу.