dkrimmer84 / l10n_co_point_of_sale Goto Github PK

I suggest refactoring to use this.sequence_number instead of establishing a parallel naming scheme. The reason is that sequence_number is already computed into a unique identifier which is exactly 12 digits long and can therefore be used for an EAN13 encoded barcode. The uniquity of this would not be altered as it also takes into account the session and the login number. But it would have encoded in the last part the available digits of the DIAN sequence.

Am I correct in deducing that instead of solving the problem of deleting pending orders, you simply require a synchronization after every single order?

initial.number_next_dian = this.pos.dian_resolutions.prefix + this.pos.dian_resolution_sequence.number_next++;

I couldn't see how this.pos.dian_resolution_sequence.number_next is stored back into the client... so looking at your pos.order backend override, number_next makes a round trip over the backend. Ugh..

Or did I miss something?

Using sequene_number instead, this mechanism is incorporated, however a pending order can be deleted and therefore should not effectively increment it.

Or should it and instead a complete parallel mechanism is needed? This seems like an interesting question, having a positive answer in the case that the unique name construct of a pending and afterwards deleted order can be of some relevance at some point... Maybe in gap detection? Or deletion detection??? Don't know, but don't think so. So reducing the next_number in case of deletion seems valid, BUT then we need to reassign also all other pending posterior orders, because of the no gap filosofy.

>>> partner = {}
>>> partner['doctype'] = None
>>> ('doctype' in partner)
True
>>> 

Are you sure about this condition?

This is a small one, but possibly useful:

Use .receipt_footer field starting with <!DOCTYPE QWEB> which will be stored onto .footer_xml in the client. This then is only printed onto the print invoice, but does not "disturb" the on-screen view of a possibly small screen (eg. tablet).

In the evaluation context of a .footer_xml you have order, this and widget objects (IIRC) so it's a powerful overloading mechanism. The establishment of the correct code is as easy as an onchange in pos.config and allows for further customization:

class PosConfig(models.Model):
    _inherit = ['pos.config']

    sequence_id = fields.Many2one(readonly=False)

    @api.onchange('sequence_id')
    def _onchange_sequence_id(self):
        if sequence_id and sequence_id.dian_resolution_id:
            resolution = sequence_id.dian_resolution_id
            drange = sequence_id.dian_range_id
            vals = {
                'resolution': resolution.number,
                'fecha': resolution.date,
                'desde': drange.range_start,
                'hasta': drange.range_end
            }
            self.receipt_footer = """
            <!DOCTYPE QWEB>
            Número Resolución DIAN {resolution} del {fecha} autoriza desde {desde} hasta {hasta}<br />
            <b>Factura de Venta No.: <t t-if="order.sequence"><t t-esc="order.sequence" /></t></b>
            """.format(vals)

This remains easily customizable and is light on the web client code. You can see we construct a order.sequence as oposed to order.name but both relay in some sort to an enhanced order.sequence_number as to my previous Issue.

@dkrimmer84 Dejame saber, si hay alguna area en que puedo colaborar... Estoy ensayando el modulo y donde se me ocurra algo, cuenta con mis PRs. Saludos!

We have discussed this, I think, but I'm not 100% affirmative on congruency of the issues, yet.

I have noticed, that a tax with counterparty used in the POS, while generating a wrong receipt (image 1 & 2), the synched order is correct (image 3), resulting in a payment difference (image 4)

Image 1

Image 2

Image 3

Image 4

@dkrimmer84 It seems that counterparty is not employed in POS. Can you confirm that it was this issue that you solved on master?
/cc @xyklex