REMARK: Featuring serialized photo scanning identification in concurrence or as alternative option to holographics, maybe optimum, for purpose to potentially easy transition from conventional to advanced, purpose of comparison (e.g. auto industry and/or auto maintenance and repair, or maquiladora), purpose of conventional references, or other. (IF applicable).


REMARK: Purpose to easy transition from conventional to advanced technology (e.g. repair and maintenance industry not in potential immediate synchronization with remote assist and dynamics 365 guides or holographics)


REMARK: Or potentially feature the cost effective evaluation tracking.


In the Edit Payment Batch window, it would be nice if we could redesign the window to allow widening of the data grids so we can see more columns and widen existing columns to view all the data properly.


Hi. We having the same requirements from Swedish customers, both in D365FO and AX2012 R3. 


This is such a fundamental requirement between the two systems, it's almost laughable it's not there, could you not connect a company in BC to a Business Unit in Sales?


I personally see this as a design defect and flaw and I cannot imagine how other customers handle this. The bank reconciliation is really a fundamental accounting principal but the process cannot be fully supported based on the current functionality that lays within the advance bank reconciliation in Dynamics. As noted and explained previously, the business will always have a discrepancy between the accounting records posted to GL vs the transactions executed on the banks side. The two sources will never be mirrored.

So what is the real purpose of having any matching rules configured with the “Action” set to “Mark new transactions” in this case. The functionality doesn´t support the base so why should we map any transaction codes to bank transaction types. This is very misleading from an accounting and audit perspective, and I highly doubt that this is accepted somehow from an internal accounting group perspective.

As noted, the voucher date when the records are posted to GL are indeed todays date or equal to the date when you imported posted the “New” transactions.

This is the issue that we are currently facing. The system should consider the value date in the statement lines and set that to the posting date on voucher level.


top suggestion. To be fair, every purchase order created should be subject to workflow approval.

I am thinking:

  • direct deliveries
  • PO from SO
  • PO from MRP
  • you name it


This is a good request! Most journals should be available through OpenExcel- it is already the case for some-, except the posting part of course


Another solution for that problem may be have two fields in Table "Item Units of Measure" in place of "quantity per unit of measure":

1) Qty in Unit of Measure

2) Qty in Base Unit of Measure (Initial Value of this field = 1)

Then function  GetQtyPerUnitOfMeasure(Item,UnitOfMeasureCode) in codeunit 5402 must return

"Qty in Unit of Measure'/"Qty in Base Unit of Measure"

Similar way is realised in "Currency Exchange Rate" table:

1) "Exchange rate Amount"

2) "Relational Exch. Rate Amount"


  • 1
  • 492
  • 493
  • 494
  • 495
  • 496
  • 497
  • 498
  • 499
  • 500