rooty/fab-manager
1
0
Fork 0
mirror of https://github.com/LaCasemate/fab-manager.git synced 2024-11-29 10:24:20 +01:00
Code Issues Releases Activity
50ed3c9ed2
fab-manager/test/fixtures/accounting_lines.yml

578 lines
13 KiB
YAML
Raw Normal View History

(feat) multiple accounting journals
2022-12-09 16:06:51 +01:00
accounting_line_43:
id: 43
(feat) rename client accounts to financial
2022-12-12 11:10:06 +01:00
line_type: payment
(feat) multiple accounting journals
2022-12-09 16:06:51 +01:00
journal_code: CB01
(feat) save the accounting data in DB Previously, the accounting data were built on demand, extracting the data from the invoices on-the-fly. This is intended to be used only once in a while, so there was no performance issue with that. Now, we want those data to be accessed from the OpenAPI, so building them on-the-fly would be very much intensive and resouces heavy. So we build them each nights using a scheduled worker and save them in the database
2022-11-18 16:42:11 +01:00
date: '2012-03-12 11:03:31.651441'
account_code: '5801'
(feat) rename client accounts to financial
2022-12-12 11:10:06 +01:00
account_label: Payment by card
(feat) improved chaining system
2023-03-23 17:39:06 +01:00
analytical_code:
(feat) save the accounting data in DB Previously, the accounting data were built on demand, extracting the data from the invoices on-the-fly. This is intended to be used only once in a while, so there was no performance issue with that. Now, we want those data to be accessed from the OpenAPI, so building them on-the-fly would be very much intensive and resouces heavy. So we build them each nights using a scheduled worker and save them in the database
2022-11-18 16:42:11 +01:00
invoice_id: 1
invoicing_profile_id: 3
debit: 10000
credit: 0
currency: EUR
summary: 1604001/VL, subscr.
(feat) multiple accounting journals
2022-12-09 16:06:51 +01:00
created_at: '2022-12-09 14:47:11.004319'
updated_at: '2022-12-09 14:47:11.004319'
accounting_line_44:
id: 44
(feat) save the accounting data in DB Previously, the accounting data were built on demand, extracting the data from the invoices on-the-fly. This is intended to be used only once in a while, so there was no performance issue with that. Now, we want those data to be accessed from the OpenAPI, so building them on-the-fly would be very much intensive and resouces heavy. So we build them each nights using a scheduled worker and save them in the database
2022-11-18 16:42:11 +01:00
line_type: item
journal_code: '530'
date: '2012-03-12 11:03:31.651441'
account_code: '7061'
account_label: Subscription
analytical_code:
invoice_id: 1
invoicing_profile_id: 3
debit: 0
credit: 10000
currency: EUR
summary: 1604001/VL, subscr.
(feat) multiple accounting journals
2022-12-09 16:06:51 +01:00
created_at: '2022-12-09 14:47:11.018100'
updated_at: '2022-12-09 14:47:11.018100'
accounting_line_45:
id: 45
(feat) rename client accounts to financial
2022-12-12 11:10:06 +01:00
line_type: payment
(feat) multiple accounting journals
2022-12-09 16:06:51 +01:00
journal_code: CA01
(feat) save the accounting data in DB Previously, the accounting data were built on demand, extracting the data from the invoices on-the-fly. This is intended to be used only once in a while, so there was no performance issue with that. Now, we want those data to be accessed from the OpenAPI, so building them on-the-fly would be very much intensive and resouces heavy. So we build them each nights using a scheduled worker and save them in the database
2022-11-18 16:42:11 +01:00
date: '2012-03-12 13:40:22.342717'
account_code: '5803'
(feat) rename client accounts to financial
2022-12-12 11:10:06 +01:00
account_label: Payment by other
(feat) improved chaining system
2023-03-23 17:39:06 +01:00
analytical_code:
(feat) save the accounting data in DB Previously, the accounting data were built on demand, extracting the data from the invoices on-the-fly. This is intended to be used only once in a while, so there was no performance issue with that. Now, we want those data to be accessed from the OpenAPI, so building them on-the-fly would be very much intensive and resouces heavy. So we build them each nights using a scheduled worker and save them in the database
2022-11-18 16:42:11 +01:00
invoice_id: 2
invoicing_profile_id: 4
debit: 2000
credit: 0
currency: EUR
summary: 1604002, subscr.
(feat) multiple accounting journals
2022-12-09 16:06:51 +01:00
created_at: '2022-12-09 14:47:11.026505'
updated_at: '2022-12-09 14:47:11.026505'
accounting_line_46:
id: 46
(feat) save the accounting data in DB Previously, the accounting data were built on demand, extracting the data from the invoices on-the-fly. This is intended to be used only once in a while, so there was no performance issue with that. Now, we want those data to be accessed from the OpenAPI, so building them on-the-fly would be very much intensive and resouces heavy. So we build them each nights using a scheduled worker and save them in the database
2022-11-18 16:42:11 +01:00
line_type: item
journal_code: '530'
date: '2012-03-12 13:40:22.342717'
account_code: '7061'
account_label: Subscription
analytical_code:
invoice_id: 2
invoicing_profile_id: 4
debit: 0
credit: 2000
currency: EUR
summary: 1604002, subscr.
(feat) multiple accounting journals
2022-12-09 16:06:51 +01:00
created_at: '2022-12-09 14:47:11.051484'
updated_at: '2022-12-09 14:47:11.051484'
accounting_line_47:
id: 47
(feat) rename client accounts to financial
2022-12-12 11:10:06 +01:00
line_type: payment
(feat) multiple accounting journals
2022-12-09 16:06:51 +01:00
journal_code: CA01
(feat) save the accounting data in DB Previously, the accounting data were built on demand, extracting the data from the invoices on-the-fly. This is intended to be used only once in a while, so there was no performance issue with that. Now, we want those data to be accessed from the OpenAPI, so building them on-the-fly would be very much intensive and resouces heavy. So we build them each nights using a scheduled worker and save them in the database
2022-11-18 16:42:11 +01:00
date: '2015-06-10 11:20:01.341130'
account_code: '5803'
(feat) rename client accounts to financial
2022-12-12 11:10:06 +01:00
account_label: Payment by other
(feat) improved chaining system
2023-03-23 17:39:06 +01:00
analytical_code:
(feat) save the accounting data in DB Previously, the accounting data were built on demand, extracting the data from the invoices on-the-fly. This is intended to be used only once in a while, so there was no performance issue with that. Now, we want those data to be accessed from the OpenAPI, so building them on-the-fly would be very much intensive and resouces heavy. So we build them each nights using a scheduled worker and save them in the database
2022-11-18 16:42:11 +01:00
invoice_id: 3
invoicing_profile_id: 7
debit: 3000
credit: 0
currency: EUR
summary: 1203001, subscr.
(feat) multiple accounting journals
2022-12-09 16:06:51 +01:00
created_at: '2022-12-09 14:47:11.059774'
updated_at: '2022-12-09 14:47:11.059774'
accounting_line_48:
id: 48
(feat) save the accounting data in DB Previously, the accounting data were built on demand, extracting the data from the invoices on-the-fly. This is intended to be used only once in a while, so there was no performance issue with that. Now, we want those data to be accessed from the OpenAPI, so building them on-the-fly would be very much intensive and resouces heavy. So we build them each nights using a scheduled worker and save them in the database
2022-11-18 16:42:11 +01:00
line_type: item
journal_code: '530'
date: '2015-06-10 11:20:01.341130'
account_code: '7061'
account_label: Subscription
analytical_code:
invoice_id: 3
invoicing_profile_id: 7
debit: 0
credit: 3000
currency: EUR
summary: 1203001, subscr.
(feat) multiple accounting journals
2022-12-09 16:06:51 +01:00
created_at: '2022-12-09 14:47:11.068258'
updated_at: '2022-12-09 14:47:11.068258'
accounting_line_49:
id: 49
(feat) rename client accounts to financial
2022-12-12 11:10:06 +01:00
line_type: payment
(feat) multiple accounting journals
2022-12-09 16:06:51 +01:00
journal_code: CA01
(feat) save the accounting data in DB Previously, the accounting data were built on demand, extracting the data from the invoices on-the-fly. This is intended to be used only once in a while, so there was no performance issue with that. Now, we want those data to be accessed from the OpenAPI, so building them on-the-fly would be very much intensive and resouces heavy. So we build them each nights using a scheduled worker and save them in the database
2022-11-18 16:42:11 +01:00
date: '2016-04-05 08:35:52.931187'
account_code: '5803'
(feat) rename client accounts to financial
2022-12-12 11:10:06 +01:00
account_label: Payment by other
(feat) improved chaining system
2023-03-23 17:39:06 +01:00
analytical_code:
(feat) save the accounting data in DB Previously, the accounting data were built on demand, extracting the data from the invoices on-the-fly. This is intended to be used only once in a while, so there was no performance issue with that. Now, we want those data to be accessed from the OpenAPI, so building them on-the-fly would be very much intensive and resouces heavy. So we build them each nights using a scheduled worker and save them in the database
2022-11-18 16:42:11 +01:00
invoice_id: 4
invoicing_profile_id: 7
debit: 0
credit: 0
currency: EUR
summary: 1203002, training reserv.
(feat) multiple accounting journals
2022-12-09 16:06:51 +01:00
created_at: '2022-12-09 14:47:11.076845'
updated_at: '2022-12-09 14:47:11.076845'
accounting_line_50:
id: 50
(feat) save the accounting data in DB Previously, the accounting data were built on demand, extracting the data from the invoices on-the-fly. This is intended to be used only once in a while, so there was no performance issue with that. Now, we want those data to be accessed from the OpenAPI, so building them on-the-fly would be very much intensive and resouces heavy. So we build them each nights using a scheduled worker and save them in the database
2022-11-18 16:42:11 +01:00
line_type: item
journal_code: '530'
date: '2016-04-05 08:35:52.931187'
account_code: '7062'
account_label: Training reservation
analytical_code:
invoice_id: 4
invoicing_profile_id: 7
debit: 0
credit: 0
currency: EUR
summary: 1203002, training reserv.
(feat) multiple accounting journals
2022-12-09 16:06:51 +01:00
created_at: '2022-12-09 14:47:11.085317'
updated_at: '2022-12-09 14:47:11.085317'
accounting_line_51:
id: 51
(feat) rename client accounts to financial
2022-12-12 11:10:06 +01:00
line_type: payment
(feat) multiple accounting journals
2022-12-09 16:06:51 +01:00
journal_code: CA01
(feat) save the accounting data in DB Previously, the accounting data were built on demand, extracting the data from the invoices on-the-fly. This is intended to be used only once in a while, so there was no performance issue with that. Now, we want those data to be accessed from the OpenAPI, so building them on-the-fly would be very much intensive and resouces heavy. So we build them each nights using a scheduled worker and save them in the database
2022-11-18 16:42:11 +01:00
date: '2016-04-05 08:36:46.853368'
account_code: '5803'
(feat) rename client accounts to financial
2022-12-12 11:10:06 +01:00
account_label: Payment by other
(feat) improved chaining system
2023-03-23 17:39:06 +01:00
analytical_code:
(feat) save the accounting data in DB Previously, the accounting data were built on demand, extracting the data from the invoices on-the-fly. This is intended to be used only once in a while, so there was no performance issue with that. Now, we want those data to be accessed from the OpenAPI, so building them on-the-fly would be very much intensive and resouces heavy. So we build them each nights using a scheduled worker and save them in the database
2022-11-18 16:42:11 +01:00
invoice_id: 5
invoicing_profile_id: 3
debit: 1500
credit: 0
currency: EUR
summary: 1506031, machine reserv.
(feat) multiple accounting journals
2022-12-09 16:06:51 +01:00
created_at: '2022-12-09 14:47:11.093737'
updated_at: '2022-12-09 14:47:11.093737'
accounting_line_52:
id: 52
(feat) save the accounting data in DB Previously, the accounting data were built on demand, extracting the data from the invoices on-the-fly. This is intended to be used only once in a while, so there was no performance issue with that. Now, we want those data to be accessed from the OpenAPI, so building them on-the-fly would be very much intensive and resouces heavy. So we build them each nights using a scheduled worker and save them in the database
2022-11-18 16:42:11 +01:00
line_type: item
journal_code: '530'
date: '2016-04-05 08:36:46.853368'
account_code: '7065'
account_label: Machine reservation
analytical_code:
invoice_id: 5
invoicing_profile_id: 3
debit: 0
credit: 1500
currency: EUR
summary: 1506031, machine reserv.
(feat) multiple accounting journals
2022-12-09 16:06:51 +01:00
created_at: '2022-12-09 14:47:11.102073'
updated_at: '2022-12-09 14:47:11.102073'
accounting_line_53:
id: 53
(feat) rename client accounts to financial
2022-12-12 11:10:06 +01:00
line_type: payment
(feat) multiple accounting journals
2022-12-09 16:06:51 +01:00
journal_code: CA01
(feat) save the accounting data in DB Previously, the accounting data were built on demand, extracting the data from the invoices on-the-fly. This is intended to be used only once in a while, so there was no performance issue with that. Now, we want those data to be accessed from the OpenAPI, so building them on-the-fly would be very much intensive and resouces heavy. So we build them each nights using a scheduled worker and save them in the database
2022-11-18 16:42:11 +01:00
date: '2021-01-04 14:51:21.616153'
account_code: '5803'
(feat) rename client accounts to financial
2022-12-12 11:10:06 +01:00
account_label: Payment by other
(feat) improved chaining system
2023-03-23 17:39:06 +01:00
analytical_code:
(feat) save the accounting data in DB Previously, the accounting data were built on demand, extracting the data from the invoices on-the-fly. This is intended to be used only once in a while, so there was no performance issue with that. Now, we want those data to be accessed from the OpenAPI, so building them on-the-fly would be very much intensive and resouces heavy. So we build them each nights using a scheduled worker and save them in the database
2022-11-18 16:42:11 +01:00
invoice_id: 6
invoicing_profile_id: 8
debit: 3000
credit: 0
currency: EUR
summary: 2101041, subscr.
(feat) multiple accounting journals
2022-12-09 16:06:51 +01:00
created_at: '2022-12-09 14:47:11.110627'
updated_at: '2022-12-09 14:47:11.110627'
accounting_line_54:
id: 54
(feat) save the accounting data in DB Previously, the accounting data were built on demand, extracting the data from the invoices on-the-fly. This is intended to be used only once in a while, so there was no performance issue with that. Now, we want those data to be accessed from the OpenAPI, so building them on-the-fly would be very much intensive and resouces heavy. So we build them each nights using a scheduled worker and save them in the database
2022-11-18 16:42:11 +01:00
line_type: item
journal_code: '530'
date: '2021-01-04 14:51:21.616153'
account_code: '7061'
account_label: Subscription
analytical_code:
invoice_id: 6
invoicing_profile_id: 8
debit: 0
credit: 3000
currency: EUR
summary: 2101041, subscr.
(feat) multiple accounting journals
2022-12-09 16:06:51 +01:00
created_at: '2022-12-09 14:47:11.118764'
updated_at: '2022-12-09 14:47:11.118764'
accounting_line_55:
id: 55
(feat) rename client accounts to financial
2022-12-12 11:10:06 +01:00
line_type: payment
(feat) multiple accounting journals
2022-12-09 16:06:51 +01:00
journal_code: CA01
(feat) save the accounting data in DB Previously, the accounting data were built on demand, extracting the data from the invoices on-the-fly. This is intended to be used only once in a while, so there was no performance issue with that. Now, we want those data to be accessed from the OpenAPI, so building them on-the-fly would be very much intensive and resouces heavy. So we build them each nights using a scheduled worker and save them in the database
2022-11-18 16:42:11 +01:00
date: '2022-09-20 15:14:22.873707'
account_code: '5803'
(feat) rename client accounts to financial
2022-12-12 11:10:06 +01:00
account_label: Payment by other
(feat) improved chaining system
2023-03-23 17:39:06 +01:00
analytical_code:
(feat) save the accounting data in DB Previously, the accounting data were built on demand, extracting the data from the invoices on-the-fly. This is intended to be used only once in a while, so there was no performance issue with that. Now, we want those data to be accessed from the OpenAPI, so building them on-the-fly would be very much intensive and resouces heavy. So we build them each nights using a scheduled worker and save them in the database
2022-11-18 16:42:11 +01:00
invoice_id: 5811
invoicing_profile_id: 3
debit: 4500
credit: 0
currency: EUR
summary: 2209002, shop order
(feat) multiple accounting journals
2022-12-09 16:06:51 +01:00
created_at: '2022-12-09 14:47:11.126381'
updated_at: '2022-12-09 14:47:11.126381'
accounting_line_56:
id: 56
(feat) save the accounting data in DB Previously, the accounting data were built on demand, extracting the data from the invoices on-the-fly. This is intended to be used only once in a while, so there was no performance issue with that. Now, we want those data to be accessed from the OpenAPI, so building them on-the-fly would be very much intensive and resouces heavy. So we build them each nights using a scheduled worker and save them in the database
2022-11-18 16:42:11 +01:00
line_type: item
journal_code: '530'
date: '2022-09-20 15:14:22.873707'
(feat) multiple accounting journals
2022-12-09 16:06:51 +01:00
account_code: '7071'
(feat) save the accounting data in DB Previously, the accounting data were built on demand, extracting the data from the invoices on-the-fly. This is intended to be used only once in a while, so there was no performance issue with that. Now, we want those data to be accessed from the OpenAPI, so building them on-the-fly would be very much intensive and resouces heavy. So we build them each nights using a scheduled worker and save them in the database
2022-11-18 16:42:11 +01:00
account_label: Shop order
analytical_code:
invoice_id: 5811
invoicing_profile_id: 3
debit: 0
credit: 4000
currency: EUR
summary: 2209002, shop order
(feat) multiple accounting journals
2022-12-09 16:06:51 +01:00
created_at: '2022-12-09 14:47:11.134781'
updated_at: '2022-12-09 14:47:11.134781'
accounting_line_57:
id: 57
(feat) save the accounting data in DB Previously, the accounting data were built on demand, extracting the data from the invoices on-the-fly. This is intended to be used only once in a while, so there was no performance issue with that. Now, we want those data to be accessed from the OpenAPI, so building them on-the-fly would be very much intensive and resouces heavy. So we build them each nights using a scheduled worker and save them in the database
2022-11-18 16:42:11 +01:00
line_type: item
journal_code: '530'
date: '2022-09-20 15:14:22.873707'
(feat) multiple accounting journals
2022-12-09 16:06:51 +01:00
account_code: '7071'
(feat) save the accounting data in DB Previously, the accounting data were built on demand, extracting the data from the invoices on-the-fly. This is intended to be used only once in a while, so there was no performance issue with that. Now, we want those data to be accessed from the OpenAPI, so building them on-the-fly would be very much intensive and resouces heavy. So we build them each nights using a scheduled worker and save them in the database
2022-11-18 16:42:11 +01:00
account_label: Shop order
analytical_code:
invoice_id: 5811
invoicing_profile_id: 3
debit: 0
credit: 500
currency: EUR
summary: 2209002, shop order
(feat) multiple accounting journals
2022-12-09 16:06:51 +01:00
created_at: '2022-12-09 14:47:11.144686'
updated_at: '2022-12-09 14:47:11.144686'
accounting_line_58:
id: 58
(feat) rename client accounts to financial
2022-12-12 11:10:06 +01:00
line_type: payment
(feat) multiple accounting journals
2022-12-09 16:06:51 +01:00
journal_code: CA01
(feat) save the accounting data in DB Previously, the accounting data were built on demand, extracting the data from the invoices on-the-fly. This is intended to be used only once in a while, so there was no performance issue with that. Now, we want those data to be accessed from the OpenAPI, so building them on-the-fly would be very much intensive and resouces heavy. So we build them each nights using a scheduled worker and save them in the database
2022-11-18 16:42:11 +01:00
date: '2022-09-20 15:14:48.345927'
account_code: '5803'
(feat) rename client accounts to financial
2022-12-12 11:10:06 +01:00
account_label: Payment by other
(feat) improved chaining system
2023-03-23 17:39:06 +01:00
analytical_code:
(feat) save the accounting data in DB Previously, the accounting data were built on demand, extracting the data from the invoices on-the-fly. This is intended to be used only once in a while, so there was no performance issue with that. Now, we want those data to be accessed from the OpenAPI, so building them on-the-fly would be very much intensive and resouces heavy. So we build them each nights using a scheduled worker and save them in the database
2022-11-18 16:42:11 +01:00
invoice_id: 5812
invoicing_profile_id: 7
debit: 6000
credit: 0
currency: EUR
summary: 2209004, shop order
(feat) multiple accounting journals
2022-12-09 16:06:51 +01:00
created_at: '2022-12-09 14:47:11.151435'
updated_at: '2022-12-09 14:47:11.151435'
accounting_line_59:
id: 59
(feat) save the accounting data in DB Previously, the accounting data were built on demand, extracting the data from the invoices on-the-fly. This is intended to be used only once in a while, so there was no performance issue with that. Now, we want those data to be accessed from the OpenAPI, so building them on-the-fly would be very much intensive and resouces heavy. So we build them each nights using a scheduled worker and save them in the database
2022-11-18 16:42:11 +01:00
line_type: item
journal_code: '530'
date: '2022-09-20 15:14:48.345927'
(feat) multiple accounting journals
2022-12-09 16:06:51 +01:00
account_code: '7071'
(feat) save the accounting data in DB Previously, the accounting data were built on demand, extracting the data from the invoices on-the-fly. This is intended to be used only once in a while, so there was no performance issue with that. Now, we want those data to be accessed from the OpenAPI, so building them on-the-fly would be very much intensive and resouces heavy. So we build them each nights using a scheduled worker and save them in the database
2022-11-18 16:42:11 +01:00
account_label: Shop order
analytical_code:
invoice_id: 5812
invoicing_profile_id: 7
debit: 0
credit: 6000
currency: EUR
summary: 2209004, shop order
(feat) multiple accounting journals
2022-12-09 16:06:51 +01:00
created_at: '2022-12-09 14:47:11.161817'
updated_at: '2022-12-09 14:47:11.161817'
accounting_line_60:
id: 60
(feat) rename client accounts to financial
2022-12-12 11:10:06 +01:00
line_type: payment
(feat) multiple accounting journals
2022-12-09 16:06:51 +01:00
journal_code: CB01
(feat) save the accounting data in DB Previously, the accounting data were built on demand, extracting the data from the invoices on-the-fly. This is intended to be used only once in a while, so there was no performance issue with that. Now, we want those data to be accessed from the OpenAPI, so building them on-the-fly would be very much intensive and resouces heavy. So we build them each nights using a scheduled worker and save them in the database
2022-11-18 16:42:11 +01:00
date: '2022-10-04 12:36:03.060832'
account_code: '5801'
(feat) rename client accounts to financial
2022-12-12 11:10:06 +01:00
account_label: Payment by card
(feat) improved chaining system
2023-03-23 17:39:06 +01:00
analytical_code:
(feat) save the accounting data in DB Previously, the accounting data were built on demand, extracting the data from the invoices on-the-fly. This is intended to be used only once in a while, so there was no performance issue with that. Now, we want those data to be accessed from the OpenAPI, so building them on-the-fly would be very much intensive and resouces heavy. So we build them each nights using a scheduled worker and save them in the database
2022-11-18 16:42:11 +01:00
invoice_id: 5816
invoicing_profile_id: 4
debit: 319
credit: 0
currency: EUR
summary: 2210002/VL, shop order
(feat) multiple accounting journals
2022-12-09 16:06:51 +01:00
created_at: '2022-12-09 14:47:11.186575'
updated_at: '2022-12-09 14:47:11.186575'
accounting_line_61:
id: 61
(feat) save the accounting data in DB Previously, the accounting data were built on demand, extracting the data from the invoices on-the-fly. This is intended to be used only once in a while, so there was no performance issue with that. Now, we want those data to be accessed from the OpenAPI, so building them on-the-fly would be very much intensive and resouces heavy. So we build them each nights using a scheduled worker and save them in the database
2022-11-18 16:42:11 +01:00
line_type: item
journal_code: '530'
date: '2022-10-04 12:36:03.060832'
(feat) multiple accounting journals
2022-12-09 16:06:51 +01:00
account_code: '7071'
(feat) save the accounting data in DB Previously, the accounting data were built on demand, extracting the data from the invoices on-the-fly. This is intended to be used only once in a while, so there was no performance issue with that. Now, we want those data to be accessed from the OpenAPI, so building them on-the-fly would be very much intensive and resouces heavy. So we build them each nights using a scheduled worker and save them in the database
2022-11-18 16:42:11 +01:00
account_label: Shop order
analytical_code:
invoice_id: 5816
invoicing_profile_id: 4
debit: 0
credit: 119
currency: EUR
summary: 2210002/VL, shop order
(feat) multiple accounting journals
2022-12-09 16:06:51 +01:00
created_at: '2022-12-09 14:47:11.203226'
updated_at: '2022-12-09 14:47:11.203226'
accounting_line_62:
id: 62
(feat) save the accounting data in DB Previously, the accounting data were built on demand, extracting the data from the invoices on-the-fly. This is intended to be used only once in a while, so there was no performance issue with that. Now, we want those data to be accessed from the OpenAPI, so building them on-the-fly would be very much intensive and resouces heavy. So we build them each nights using a scheduled worker and save them in the database
2022-11-18 16:42:11 +01:00
line_type: item
journal_code: '530'
date: '2022-10-04 12:36:03.060832'
(feat) multiple accounting journals
2022-12-09 16:06:51 +01:00
account_code: '7071'
(feat) save the accounting data in DB Previously, the accounting data were built on demand, extracting the data from the invoices on-the-fly. This is intended to be used only once in a while, so there was no performance issue with that. Now, we want those data to be accessed from the OpenAPI, so building them on-the-fly would be very much intensive and resouces heavy. So we build them each nights using a scheduled worker and save them in the database
2022-11-18 16:42:11 +01:00
account_label: Shop order
analytical_code:
invoice_id: 5816
invoicing_profile_id: 4
debit: 0
credit: 200
currency: EUR
summary: 2210002/VL, shop order
(feat) multiple accounting journals
2022-12-09 16:06:51 +01:00
created_at: '2022-12-09 14:47:11.219605'
updated_at: '2022-12-09 14:47:11.219605'
accounting_line_63:
id: 63
(feat) rename client accounts to financial
2022-12-12 11:10:06 +01:00
line_type: payment
(feat) multiple accounting journals
2022-12-09 16:06:51 +01:00
journal_code: CB01
(feat) save the accounting data in DB Previously, the accounting data were built on demand, extracting the data from the invoices on-the-fly. This is intended to be used only once in a while, so there was no performance issue with that. Now, we want those data to be accessed from the OpenAPI, so building them on-the-fly would be very much intensive and resouces heavy. So we build them each nights using a scheduled worker and save them in the database
2022-11-18 16:42:11 +01:00
date: '2022-10-04 13:54:42.975196'
account_code: '5801'
(feat) rename client accounts to financial
2022-12-12 11:10:06 +01:00
account_label: Payment by card
(feat) improved chaining system
2023-03-23 17:39:06 +01:00
analytical_code:
(feat) save the accounting data in DB Previously, the accounting data were built on demand, extracting the data from the invoices on-the-fly. This is intended to be used only once in a while, so there was no performance issue with that. Now, we want those data to be accessed from the OpenAPI, so building them on-the-fly would be very much intensive and resouces heavy. So we build them each nights using a scheduled worker and save them in the database
2022-11-18 16:42:11 +01:00
invoice_id: 5817
invoicing_profile_id: 4
debit: 1295
credit: 0
currency: EUR
summary: 2210004/VL, shop order
(feat) multiple accounting journals
2022-12-09 16:06:51 +01:00
created_at: '2022-12-09 14:47:11.234721'
updated_at: '2022-12-09 14:47:11.234721'
accounting_line_64:
id: 64
(feat) save the accounting data in DB Previously, the accounting data were built on demand, extracting the data from the invoices on-the-fly. This is intended to be used only once in a while, so there was no performance issue with that. Now, we want those data to be accessed from the OpenAPI, so building them on-the-fly would be very much intensive and resouces heavy. So we build them each nights using a scheduled worker and save them in the database
2022-11-18 16:42:11 +01:00
line_type: item
journal_code: '530'
date: '2022-10-04 13:54:42.975196'
(feat) multiple accounting journals
2022-12-09 16:06:51 +01:00
account_code: '7071'
(feat) save the accounting data in DB Previously, the accounting data were built on demand, extracting the data from the invoices on-the-fly. This is intended to be used only once in a while, so there was no performance issue with that. Now, we want those data to be accessed from the OpenAPI, so building them on-the-fly would be very much intensive and resouces heavy. So we build them each nights using a scheduled worker and save them in the database
2022-11-18 16:42:11 +01:00
account_label: Shop order
analytical_code:
invoice_id: 5817
invoicing_profile_id: 4
debit: 0
credit: 95
currency: EUR
summary: 2210004/VL, shop order
(feat) multiple accounting journals
2022-12-09 16:06:51 +01:00
created_at: '2022-12-09 14:47:11.243121'
updated_at: '2022-12-09 14:47:11.243121'
accounting_line_65:
id: 65
(feat) save the accounting data in DB Previously, the accounting data were built on demand, extracting the data from the invoices on-the-fly. This is intended to be used only once in a while, so there was no performance issue with that. Now, we want those data to be accessed from the OpenAPI, so building them on-the-fly would be very much intensive and resouces heavy. So we build them each nights using a scheduled worker and save them in the database
2022-11-18 16:42:11 +01:00
line_type: item
journal_code: '530'
date: '2022-10-04 13:54:42.975196'
(feat) multiple accounting journals
2022-12-09 16:06:51 +01:00
account_code: '7071'
(feat) save the accounting data in DB Previously, the accounting data were built on demand, extracting the data from the invoices on-the-fly. This is intended to be used only once in a while, so there was no performance issue with that. Now, we want those data to be accessed from the OpenAPI, so building them on-the-fly would be very much intensive and resouces heavy. So we build them each nights using a scheduled worker and save them in the database
2022-11-18 16:42:11 +01:00
account_label: Shop order
analytical_code:
invoice_id: 5817
invoicing_profile_id: 4
debit: 0
credit: 1200
currency: EUR
summary: 2210004/VL, shop order
(feat) multiple accounting journals
2022-12-09 16:06:51 +01:00
created_at: '2022-12-09 14:47:11.253093'
updated_at: '2022-12-09 14:47:11.253093'
accounting_line_66:
id: 66
(feat) rename client accounts to financial
2022-12-12 11:10:06 +01:00
line_type: payment
(feat) multiple accounting journals
2022-12-09 16:06:51 +01:00
journal_code: CB01
(feat) save the accounting data in DB Previously, the accounting data were built on demand, extracting the data from the invoices on-the-fly. This is intended to be used only once in a while, so there was no performance issue with that. Now, we want those data to be accessed from the OpenAPI, so building them on-the-fly would be very much intensive and resouces heavy. So we build them each nights using a scheduled worker and save them in the database
2022-11-18 16:42:11 +01:00
date: '2022-10-04 14:04:12.742685'
account_code: '5801'
(feat) rename client accounts to financial
2022-12-12 11:10:06 +01:00
account_label: Payment by card
(feat) improved chaining system
2023-03-23 17:39:06 +01:00
analytical_code:
(feat) save the accounting data in DB Previously, the accounting data were built on demand, extracting the data from the invoices on-the-fly. This is intended to be used only once in a while, so there was no performance issue with that. Now, we want those data to be accessed from the OpenAPI, so building them on-the-fly would be very much intensive and resouces heavy. So we build them each nights using a scheduled worker and save them in the database
2022-11-18 16:42:11 +01:00
invoice_id: 5818
invoicing_profile_id: 4
debit: 1000
credit: 0
currency: EUR
summary: 2210006/VL, shop order
(feat) multiple accounting journals
2022-12-09 16:06:51 +01:00
created_at: '2022-12-09 14:47:11.268142'
updated_at: '2022-12-09 14:47:11.268142'
accounting_line_67:
id: 67
(feat) save the accounting data in DB Previously, the accounting data were built on demand, extracting the data from the invoices on-the-fly. This is intended to be used only once in a while, so there was no performance issue with that. Now, we want those data to be accessed from the OpenAPI, so building them on-the-fly would be very much intensive and resouces heavy. So we build them each nights using a scheduled worker and save them in the database
2022-11-18 16:42:11 +01:00
line_type: item
journal_code: '530'
date: '2022-10-04 14:04:12.742685'
(feat) multiple accounting journals
2022-12-09 16:06:51 +01:00
account_code: '7071'
(feat) save the accounting data in DB Previously, the accounting data were built on demand, extracting the data from the invoices on-the-fly. This is intended to be used only once in a while, so there was no performance issue with that. Now, we want those data to be accessed from the OpenAPI, so building them on-the-fly would be very much intensive and resouces heavy. So we build them each nights using a scheduled worker and save them in the database
2022-11-18 16:42:11 +01:00
account_label: Shop order
analytical_code:
invoice_id: 5818
invoicing_profile_id: 4
debit: 0
credit: 1000
currency: EUR
summary: 2210006/VL, shop order
(feat) multiple accounting journals
2022-12-09 16:06:51 +01:00
created_at: '2022-12-09 14:47:11.278069'
updated_at: '2022-12-09 14:47:11.278069'
accounting_line_68:
id: 68
(feat) rename client accounts to financial
2022-12-12 11:10:06 +01:00
line_type: payment
(feat) multiple accounting journals
2022-12-09 16:06:51 +01:00
journal_code: CB01
(feat) save the accounting data in DB Previously, the accounting data were built on demand, extracting the data from the invoices on-the-fly. This is intended to be used only once in a while, so there was no performance issue with that. Now, we want those data to be accessed from the OpenAPI, so building them on-the-fly would be very much intensive and resouces heavy. So we build them each nights using a scheduled worker and save them in the database
2022-11-18 16:42:11 +01:00
date: '2022-10-04 14:17:52.854636'
account_code: '5801'
(feat) rename client accounts to financial
2022-12-12 11:10:06 +01:00
account_label: Payment by card
(feat) improved chaining system
2023-03-23 17:39:06 +01:00
analytical_code:
(feat) save the accounting data in DB Previously, the accounting data were built on demand, extracting the data from the invoices on-the-fly. This is intended to be used only once in a while, so there was no performance issue with that. Now, we want those data to be accessed from the OpenAPI, so building them on-the-fly would be very much intensive and resouces heavy. So we build them each nights using a scheduled worker and save them in the database
2022-11-18 16:42:11 +01:00
invoice_id: 5819
invoicing_profile_id: 4
debit: 4002
credit: 0
currency: EUR
summary: 2210008/VL, shop order
(feat) multiple accounting journals
2022-12-09 16:06:51 +01:00
created_at: '2022-12-09 14:47:11.294694'
updated_at: '2022-12-09 14:47:11.294694'
accounting_line_69:
id: 69
(feat) save the accounting data in DB Previously, the accounting data were built on demand, extracting the data from the invoices on-the-fly. This is intended to be used only once in a while, so there was no performance issue with that. Now, we want those data to be accessed from the OpenAPI, so building them on-the-fly would be very much intensive and resouces heavy. So we build them each nights using a scheduled worker and save them in the database
2022-11-18 16:42:11 +01:00
line_type: item
journal_code: '530'
date: '2022-10-04 14:17:52.854636'
(feat) multiple accounting journals
2022-12-09 16:06:51 +01:00
account_code: '7071'
(feat) save the accounting data in DB Previously, the accounting data were built on demand, extracting the data from the invoices on-the-fly. This is intended to be used only once in a while, so there was no performance issue with that. Now, we want those data to be accessed from the OpenAPI, so building them on-the-fly would be very much intensive and resouces heavy. So we build them each nights using a scheduled worker and save them in the database
2022-11-18 16:42:11 +01:00
account_label: Shop order
analytical_code:
invoice_id: 5819
invoicing_profile_id: 4
debit: 0
credit: 2
currency: EUR
summary: 2210008/VL, shop order
(feat) multiple accounting journals
2022-12-09 16:06:51 +01:00
created_at: '2022-12-09 14:47:11.311492'
updated_at: '2022-12-09 14:47:11.311492'
accounting_line_70:
id: 70
(feat) save the accounting data in DB Previously, the accounting data were built on demand, extracting the data from the invoices on-the-fly. This is intended to be used only once in a while, so there was no performance issue with that. Now, we want those data to be accessed from the OpenAPI, so building them on-the-fly would be very much intensive and resouces heavy. So we build them each nights using a scheduled worker and save them in the database
2022-11-18 16:42:11 +01:00
line_type: item
journal_code: '530'
date: '2022-10-04 14:17:52.854636'
(feat) multiple accounting journals
2022-12-09 16:06:51 +01:00
account_code: '7071'
(feat) save the accounting data in DB Previously, the accounting data were built on demand, extracting the data from the invoices on-the-fly. This is intended to be used only once in a while, so there was no performance issue with that. Now, we want those data to be accessed from the OpenAPI, so building them on-the-fly would be very much intensive and resouces heavy. So we build them each nights using a scheduled worker and save them in the database
2022-11-18 16:42:11 +01:00
account_label: Shop order
analytical_code:
invoice_id: 5819
invoicing_profile_id: 4
debit: 0
credit: 4000
currency: EUR
summary: 2210008/VL, shop order
(feat) multiple accounting journals
2022-12-09 16:06:51 +01:00
created_at: '2022-12-09 14:47:11.318065'
updated_at: '2022-12-09 14:47:11.318065'
accounting_line_71:
id: 71
(feat) rename client accounts to financial
2022-12-12 11:10:06 +01:00
line_type: payment
(feat) multiple accounting journals
2022-12-09 16:06:51 +01:00
journal_code: CA01
(feat) save the accounting data in DB Previously, the accounting data were built on demand, extracting the data from the invoices on-the-fly. This is intended to be used only once in a while, so there was no performance issue with that. Now, we want those data to be accessed from the OpenAPI, so building them on-the-fly would be very much intensive and resouces heavy. So we build them each nights using a scheduled worker and save them in the database
2022-11-18 16:42:11 +01:00
date: '2022-10-04 14:25:37.291945'
account_code: '5803'
(feat) rename client accounts to financial
2022-12-12 11:10:06 +01:00
account_label: Payment by other
(feat) improved chaining system
2023-03-23 17:39:06 +01:00
analytical_code:
(feat) save the accounting data in DB Previously, the accounting data were built on demand, extracting the data from the invoices on-the-fly. This is intended to be used only once in a while, so there was no performance issue with that. Now, we want those data to be accessed from the OpenAPI, so building them on-the-fly would be very much intensive and resouces heavy. So we build them each nights using a scheduled worker and save them in the database
2022-11-18 16:42:11 +01:00
invoice_id: 5820
invoicing_profile_id: 3
debit: 12000
credit: 0
currency: EUR
summary: 2210010, shop order
(feat) multiple accounting journals
2022-12-09 16:06:51 +01:00
created_at: '2022-12-09 14:47:11.326477'
updated_at: '2022-12-09 14:47:11.326477'
accounting_line_72:
id: 72
(feat) save the accounting data in DB Previously, the accounting data were built on demand, extracting the data from the invoices on-the-fly. This is intended to be used only once in a while, so there was no performance issue with that. Now, we want those data to be accessed from the OpenAPI, so building them on-the-fly would be very much intensive and resouces heavy. So we build them each nights using a scheduled worker and save them in the database
2022-11-18 16:42:11 +01:00
line_type: item
journal_code: '530'
date: '2022-10-04 14:25:37.291945'
(feat) multiple accounting journals
2022-12-09 16:06:51 +01:00
account_code: '7071'
(feat) save the accounting data in DB Previously, the accounting data were built on demand, extracting the data from the invoices on-the-fly. This is intended to be used only once in a while, so there was no performance issue with that. Now, we want those data to be accessed from the OpenAPI, so building them on-the-fly would be very much intensive and resouces heavy. So we build them each nights using a scheduled worker and save them in the database
2022-11-18 16:42:11 +01:00
account_label: Shop order
analytical_code:
invoice_id: 5820
invoicing_profile_id: 3
debit: 0
credit: 12000
currency: EUR
summary: 2210010, shop order
(feat) multiple accounting journals
2022-12-09 16:06:51 +01:00
created_at: '2022-12-09 14:47:11.336473'
updated_at: '2022-12-09 14:47:11.336473'
accounting_line_73:
id: 73
(feat) rename client accounts to financial
2022-12-12 11:10:06 +01:00
line_type: payment
(feat) multiple accounting journals
2022-12-09 16:06:51 +01:00
journal_code: CA01
(feat) save the accounting data in DB Previously, the accounting data were built on demand, extracting the data from the invoices on-the-fly. This is intended to be used only once in a while, so there was no performance issue with that. Now, we want those data to be accessed from the OpenAPI, so building them on-the-fly would be very much intensive and resouces heavy. So we build them each nights using a scheduled worker and save them in the database
2022-11-18 16:42:11 +01:00
date: '2022-10-04 14:32:28.204985'
account_code: '5803'
(feat) rename client accounts to financial
2022-12-12 11:10:06 +01:00
account_label: Payment by other
(feat) improved chaining system
2023-03-23 17:39:06 +01:00
analytical_code:
(feat) save the accounting data in DB Previously, the accounting data were built on demand, extracting the data from the invoices on-the-fly. This is intended to be used only once in a while, so there was no performance issue with that. Now, we want those data to be accessed from the OpenAPI, so building them on-the-fly would be very much intensive and resouces heavy. So we build them each nights using a scheduled worker and save them in the database
2022-11-18 16:42:11 +01:00
invoice_id: 5821
invoicing_profile_id: 2
debit: 12000
credit: 0
currency: EUR
summary: 2210012, shop order
(feat) multiple accounting journals
2022-12-09 16:06:51 +01:00
created_at: '2022-12-09 14:47:11.353361'
updated_at: '2022-12-09 14:47:11.353361'
accounting_line_74:
id: 74
(feat) save the accounting data in DB Previously, the accounting data were built on demand, extracting the data from the invoices on-the-fly. This is intended to be used only once in a while, so there was no performance issue with that. Now, we want those data to be accessed from the OpenAPI, so building them on-the-fly would be very much intensive and resouces heavy. So we build them each nights using a scheduled worker and save them in the database
2022-11-18 16:42:11 +01:00
line_type: item
journal_code: '530'
date: '2022-10-04 14:32:28.204985'
(feat) multiple accounting journals
2022-12-09 16:06:51 +01:00
account_code: '7071'
(feat) save the accounting data in DB Previously, the accounting data were built on demand, extracting the data from the invoices on-the-fly. This is intended to be used only once in a while, so there was no performance issue with that. Now, we want those data to be accessed from the OpenAPI, so building them on-the-fly would be very much intensive and resouces heavy. So we build them each nights using a scheduled worker and save them in the database
2022-11-18 16:42:11 +01:00
account_label: Shop order
analytical_code:
invoice_id: 5821
invoicing_profile_id: 2
debit: 0
credit: 12000
currency: EUR
summary: 2210012, shop order
(feat) multiple accounting journals
2022-12-09 16:06:51 +01:00
created_at: '2022-12-09 14:47:11.368203'
updated_at: '2022-12-09 14:47:11.368203'
accounting_line_75:
id: 75
(feat) rename client accounts to financial
2022-12-12 11:10:06 +01:00
line_type: payment
(feat) multiple accounting journals
2022-12-09 16:06:51 +01:00
journal_code: CA01
(feat) save the accounting data in DB Previously, the accounting data were built on demand, extracting the data from the invoices on-the-fly. This is intended to be used only once in a while, so there was no performance issue with that. Now, we want those data to be accessed from the OpenAPI, so building them on-the-fly would be very much intensive and resouces heavy. So we build them each nights using a scheduled worker and save them in the database
2022-11-18 16:42:11 +01:00
date: '2022-10-04 14:35:40.584472'
account_code: '5803'
(feat) rename client accounts to financial
2022-12-12 11:10:06 +01:00
account_label: Payment by other
(feat) improved chaining system
2023-03-23 17:39:06 +01:00
analytical_code:
(feat) save the accounting data in DB Previously, the accounting data were built on demand, extracting the data from the invoices on-the-fly. This is intended to be used only once in a while, so there was no performance issue with that. Now, we want those data to be accessed from the OpenAPI, so building them on-the-fly would be very much intensive and resouces heavy. So we build them each nights using a scheduled worker and save them in the database
2022-11-18 16:42:11 +01:00
invoice_id: 5822
invoicing_profile_id: 2
debit: 3000
credit: 0
currency: EUR
summary: 2210014, shop order
(feat) multiple accounting journals
2022-12-09 16:06:51 +01:00
created_at: '2022-12-09 14:47:11.378107'
updated_at: '2022-12-09 14:47:11.378107'
accounting_line_76:
id: 76
(feat) save the accounting data in DB Previously, the accounting data were built on demand, extracting the data from the invoices on-the-fly. This is intended to be used only once in a while, so there was no performance issue with that. Now, we want those data to be accessed from the OpenAPI, so building them on-the-fly would be very much intensive and resouces heavy. So we build them each nights using a scheduled worker and save them in the database
2022-11-18 16:42:11 +01:00
line_type: item
journal_code: '530'
date: '2022-10-04 14:35:40.584472'
(feat) multiple accounting journals
2022-12-09 16:06:51 +01:00
account_code: '7071'
(feat) save the accounting data in DB Previously, the accounting data were built on demand, extracting the data from the invoices on-the-fly. This is intended to be used only once in a while, so there was no performance issue with that. Now, we want those data to be accessed from the OpenAPI, so building them on-the-fly would be very much intensive and resouces heavy. So we build them each nights using a scheduled worker and save them in the database
2022-11-18 16:42:11 +01:00
account_label: Shop order
analytical_code:
invoice_id: 5822
invoicing_profile_id: 2
debit: 0
credit: 3000
currency: EUR
summary: 2210014, shop order
(feat) multiple accounting journals
2022-12-09 16:06:51 +01:00
created_at: '2022-12-09 14:47:11.394849'
updated_at: '2022-12-09 14:47:11.394849'
Reference in New Issue Copy Permalink