2023 Wave 2 – v23: Table ‘Invoice Post. Buffer’ is marked for removal – New Invoice Posting Implementation (English version)
2023 Wave 2 – v23: Table ‘Invoice Post. Buffer’ is marked for removal – New Invoice Posting Implementation
Tenemos que poner especial atención al siguiente este mensaje en nuestras extensiones.
La siguiente versión 2023 Wave 2 – v23 reemplaza la tabla «Invoice Post. Buffer», destaquemos dos puntos de la siguiente imagen, la nueva tabla «Invoice Posting Buffer» y la «implementación del nuevo registro de facturas»
Al revisar sus eventos también nos indican que será remplazado por la nueva tabla mencionada.
Nueva Tabla «Invoice Posting Buffer»
La tabla «Invoice Post. Buffer» se usa principalmente para agrupar las líneas de facturas por los campos especificados en la clave primaria de la tabla y luego contabilizar las línea agrupadas. A continuación muestro los campos que componente la clave primaria, en el cual un campo utilizado y que permitía agruparlo de manera personalizada era el de «Identificador de agrupación adicional». Más información Additional Grouping Identifier – Hougaard.com
Uno de los cambios importantes con esta nueva tabla «Invoice Posting Buffer» es la nueva clave primaria que es un campo de tipo Texto.
Existe una función denominada BuildPrimaryKey que es la que prepara la llave primaria con los campos que antes componían la clave primaria. Y un evento denominado OnAfterBuildPrimaryKey que nos permite extender y modificarlo.
Por lo que es importante modificar los desarrollos donde hemos usado esta tabla y modificarlos hacia la nueva. El nombre de los nuevos eventos no necesariamente son similares a los anteriores, hay que revisar con profundidad. En la siguiente imagen se implementa el evento OnAfterCopyToGenJnlLine con ambas tablas a modo de ejemplo.
Atención para probar estos cambios, es necesario activar en el Administrador de Características la funcionalidad de «Habilitar el uso de el nuevo motor extensible de registro de facturas», Ahora permitido solo para ambientes del tipo Sandbox.
Implementación del nuevo registro de facturas
En la versión 2021 wave 2 -v19 se entregó una nueva funcionalidad denominada Extend general ledger posting aggregations (Invoice Post. Buffer refactoring), se crearon unos campos en las tablas de configuración de Ventas, Compras y Servicios que permitiría una selección de una forma de Registro de Facturas.
Esta versión 23 deja de usar estos campos.
La habilitación en el administrador de características mencionada anteriormente activa por defecto en el caso de las ventas (es similar en compras y servicio) la versión de contabilización denominada «Invoice Posting (V.19)» la cual usa la CU 815 «Sales Post Invoice» que implementa la interface «Invoice Posting».
De esta manera se nos permite mediante el uso de interfaces ampliar y crear tu nuestra propia forma de contabilización, lo cual también es arriesgado si no se trabaja adecuadamente, pudiendo romper cosas que no se controla.
Este cambio ha traído también nuevas codeunits donde se exponen los eventos que hemos de usar para suscribirnos e integrarnos con las distintas codeunits de contabilización de ventas, compras y servicio.
Podemos ver a continuación el evento «RunGenJnlPostLine»:
- CU 80: Indicando que debemos dejar de usarlo para usar el de la CU 825
- CU 825: Será el lugar por el momento definitivo a donde deberemos suscribirnos para extender la funcionalidad.
- CU 815: La Codeunit que implementa la interface «Invoice Posting» usando también la CU 825.
Es importante atender y comprender estos cambios, realizarlos y probarlos mucho en los ambientes tipo sandbox, que ya la versión 23 se encuentra a la vuelta de la esquina.
2023 Wave 2 – v23: Table ‘Invoice Post. Buffer’ is marked for removal – New Invoice Posting Implementation
We have to pay special attention to the following message in our extensions.
The next version 2023 Wave 2 – v23 replaces the table «Invoice Post. Buffer», let’s highlight two points of the following image, the new table «Invoice Posting Buffer» and the «new Invoice Posting Implementation».
A review of its events also indicates that it will be replaced by the new table mentioned above.
New Table «Invoice Posting Buffer»
The «Invoice Post. Buffer» table is mainly used to group the invoice lines by the fields specified in the primary key of the table and then post the grouped lines. Below I show the fields that make up the primary key, in which one field used that allowed custom grouping was the «Additional Grouping Identifier». More information Additional Grouping Identifier – Hougaard.com
One of the important changes with this new «Invoice Posting Buffer» table is the new primary key which is a Text type field.
There is a function called BuildPrimaryKey that prepares the primary key with the fields that previously composed the primary key. And an event called OnAfterBuildPrimaryKey that allows us to extend and modify it.
So it is important to modify the developments where we have used this table and modify them to the new one. The name of the new events are not necessarily similar to the previous ones, it is necessary to review them in depth. In the following image the OnAfterCopyToGenJnlLine event is implemented with both tables as an example.
Attention to test these changes, it is necessary to activate in the Feature Manager the functionality of «Enable the use of the new extensible invoice posting engine», now allowed only for Sandbox environments.
New Invoice Posting Implementation
In version 2021 wave 2 -v19 a new functionality called Extend general ledger posting aggregations (Invoice Post. Buffer refactoring) was delivered, some fields were created in the configuration tables of Sales, Purchases and Services that would allow a selection of a type of Invoice Posting.
This version 23 no longer uses these fields.
The enablement in the feature manager mentioned above activates by default in the case of sales (it is similar in purchasing and service) the sales invoice posting version called «Invoice Posting (V.19)» which uses also the CU 815 «Sales Post Invoice» which implements the «Invoice Posting» interface.
In this way we are allowed by using interfaces to extend and create our own form of accounting, which is also risky if not worked properly, and can break things that we do not control.
This change has also brought new codeunits where the events that we have to use to subscribe and integrate with the different sales, purchase and service accounting codeunits are exposed.
We can see below the «RunGenJnlPostLine» event:
- CU 80: Indicating that we must stop using it to use the one of the CU 825.
- CU 825: It will be the place for the definitive moment where we will have to subscribe to extend the functionality.
- CU 815: The Codeunit that implements the «Invoice Posting» interface using CU 825.
It is important to pay attention to and understand these changes, make them and test them a lot in sandbox environments, as version 23 is just around the corner.
Más información / More information:
Gerardo Rentería Blog 
Deja un comentario